测试用例

测试用例被定义为一组条件，测试人员根据这些条件确定软件应用程序是否按客户的要求运行。测试用例设计包括前置条件、用例名称、输入条件和预期结果。测试用例是第一级的操作，派生自测试场景。

这是一个详细的文档，包含所有可能的输入（正面和负面）以及用于测试执行过程的导航步骤。编写测试用例是一次性尝试，可以在将来的回归测试时使用。

测试用例提供有关测试策略、测试过程、前置条件和预期输出的详细信息。这些在测试过程中执行，以检查软件应用程序是否执行了为其开发的任务。

测试用例通过将缺陷与测试用例ID链接来帮助测试人员报告缺陷。详细的测试用例文档是测试团队的完整证据，因为如果开发人员遗漏了什么，那么在这些完整证据测试用例的执行过程中就可以发现。

要编写测试用例，我们必须具备派生输入的先决条件，并且必须编写测试场景，以免遗漏任何需要测试的功能。然后，我们应该有一个测试用例模板来保持统一性，或者每个测试工程师都遵循相同的流程来准备测试文档。

通常，我们会在开发人员忙于编写代码时编写测试用例。

何时编写测试用例？

当收到以下信息时，我们将编写测试用例

• 当客户提出业务需求时，开发人员开始开发，并说他们需要 3.5 个月来构建这个产品。
• 在此期间，测试团队将开始编写测试用例。
• 完成后，将发送给测试主管进行审查。
• 当开发人员完成产品开发时，它将被移交给测试团队。
• 测试工程师在测试产品文档时从不看需求，因为测试是持续的，不取决于人的心情，而取决于测试工程师的质量。

注意：在编写测试用例时，实际结果永远不应写，因为产品仍在开发过程中。因此，实际结果应仅在测试用例执行后编写。

为什么写测试用例？

我们将出于以下原因编写测试：

• 要求测试用例执行的一致性
• 确保更好的测试覆盖率
• 它取决于流程而不是人
• 避免为每个新测试工程师提供产品培训

要求测试用例执行的一致性：我们将查看测试用例并开始测试应用程序。

确保更好的测试覆盖率：为此，我们应该覆盖所有可能的场景并记录下来，这样我们就需要反复记住所有场景。

它取决于流程而不是人：一位测试工程师在第一个版本、第二个版本中测试了应用程序，并在第三个版本时离开了公司。由于测试工程师理解了一个模块并彻底测试了应用程序，派生了许多值。如果在第三个版本中该人员不在，那么新的人就会遇到困难。因此，所有派生的值都已记录下来，以便将来使用。

避免为每个新测试工程师提供产品培训：当测试工程师离开时，他/她会带走很多知识和场景。这些场景应该被记录下来，以便新测试工程师可以使用给定的场景进行测试，也可以编写新的场景。

注意：当开发人员为第一个版本开发第一个产品时，测试工程师会编写测试用例。在第二个版本中，当添加新功能时，测试工程师也会为这些功能编写测试用例，在下一个版本中，当元素被修改时，测试工程师将更改测试用例或编写新的测试用例。

测试用例模板

编写测试用例的主要目的是提高应用程序的效率。

众所周知，实际结果是在测试用例执行后编写的，而且大多数情况下，它会与预期结果相同。但如果测试步骤失败，它就会不同。因此，可以跳过实际结果字段，在注释部分，我们可以写关于 bug 的内容。

另外，可以删除输入字段，并将此信息添加到描述字段。

上面讨论的模板不是标准的，因为每个公司以及每个应用程序都可能不同，这取决于测试工程师和测试主管。但是，为了测试一个应用程序，所有测试工程师都应该遵循一个通常的模板，即制定的模板。

测试用例应以简单的语言编写，以便新测试工程师也能理解和执行。

在上面的样本模板中，标题包含以下内容：

步骤编号

这也很重要，因为如果第 20 步失败，我们可以记录 bug 报告，从而确定工作优先级，并决定它是否是一个关键 bug。

测试用例类型

它可以是功能、集成或系统测试用例，也可以是正面或负面，或正面和负面测试用例。

Release

一个版本可以包含许多发布版本。

前置条件

这些是每个测试工程师在开始测试执行过程之前需要满足的必要条件。或者它是为测试需要创建的数据配置或数据设置。

例如：在一个应用程序中，我们正在编写添加用户、编辑用户和删除用户的测试用例。在编辑和删除用户 A 之前，会看到用户 A 已添加的前置条件。

测试数据

这些是我们根据前置条件需要创建的值或输入。

例如，用户的用户名、密码和账号。

测试主管可能会提供用户名或密码等测试数据来测试应用程序，或者测试工程师自己生成用户名和密码。

严重程度

严重程度可以是主要、次要和严重，测试用例中的严重程度谈论的是特定测试用例的重要性。所有文本执行过程始终取决于测试用例的严重程度。

我们可以根据模块选择严重程度。一个模块中包含许多功能，即使一个元素是关键的，我们也认为该测试用例是关键的。这取决于我们为其编写测试用例的功能。

例如，我们将以 Gmail 应用程序为例，根据模块查看严重程度：

对于银行应用程序，严重程度可能如下：

简要描述

测试工程师为特定功能编写了测试用例。如果他/她看到并读取了当前测试用例，他/她将不知道它是为哪个功能编写的。因此，简短的描述将帮助他们了解测试用例是为哪个功能编写的。

测试用例模板示例

这里，我们为ICICI 应用程序的登录模块编写了一个测试用例。

测试用例类型

我们有不同类型的测试用例，如下所示：

• 功能测试用例
• 集成测试用例
• 系统测试用例

功能测试用例

首先，我们检查将为哪个字段编写测试用例，然后相应地描述。

在功能测试中，或者如果应用程序是数据驱动的，我们需要输入列，否则会比较耗时。

编写功能测试用例的规则

• 在预期结果列中，尽量使用应该是或必须是。
• 突出对象名称。
• 我们只需要描述最需要的步骤；否则，我们不需要定义所有步骤。
• 为了减少过多的执行时间，我们将正确地编写步骤。
• 编写通用测试用例；不要尝试硬编码。

假设它是金额转账模块，因此我们正在为其编写功能测试用例，然后还指定它不是登录功能。

金额转账模块的功能测试用例在下面的 Excel 文件中。

集成测试用例

在这种情况下，我们不应该写已经在功能测试用例中涵盖的内容，并且在集成测试用例中写的内容不应该再次写在系统测试用例中。

编写集成测试用例的规则

• 首先，理解产品
• 识别可能的情况
• 根据优先级编写测试用例

当测试工程师编写测试用例时，他们可能需要考虑以下方面：

测试用例是否详细

• 他们将努力实现最大的测试覆盖率。
• 所有测试用例值或场景均已正确描述。
• 他们将从执行的角度进行思考。
• 用于编写测试用例的模板必须是唯一的。

注意：当涉及的步骤较少或覆盖率较高时，它应该是最好的测试用例，并且当将这些测试用例交给任何人时，他们都能轻松理解。

系统测试用例

我们将为端到端业务流程编写系统测试用例。并且我们已经准备好所有模块来编写系统测试用例。

编写测试用例的过程

编写测试用例的方法可以分为以下几个步骤，如下所示：

系统研究

在这种情况下，我们将通过查看客户提供的需求或 SRS 来理解应用程序。

识别所有场景

• 当产品发布时，最终用户可能使用该软件的所有可能方式，以识别所有可能的方式。
• 我在一个名为测试设计/高级设计的文件中记录了所有可能的情况。
• 测试设计是一个记录，包含所有可能的情况。

编写测试用例

将所有已识别的场景转换为测试声明，并按功能对场景进行分组，确定模块的优先级，并通过应用测试用例设计技术编写测试用例，并使用标准的测试用例模板，即项目确定的模板。

审查测试用例

通过将其交给团队负责人来审查测试用例，然后修复审阅者给出的审阅反馈。

测试用例审批

根据反馈修复测试用例后，再次发送以供批准。

存储在测试用例存储库中

在特定测试用例获得批准后，将其存储在称为测试用例存储库的熟悉位置。

要获取有关测试用例审查过程的完整信息，请参阅以下链接：

test-case-review-process