测试用例被定义为一组条件，测试人员在该条件下确定软件应用程序是否按照客户的要求工作。测试用例设计包括前提条件、用例名称、输入条件和预期结果。测试用例是第一级操作，派生自测试方案。

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

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

测试用例通过将缺陷与测试用例 ID 链接来帮助测试人员进行缺陷报告。 详细的测试用例文档可以作为测试团队的完整证明保护，因为如果开发人员错过了某些内容，那么在执行这些完全证明的测试用例时可能会被捕获。

要编写测试用例，我们必须具备派生输入的要求，并且必须编写测试场景，以免错过任何测试功能。然后我们应该有测试用例模板来保持一致性，或者每个测试工程师都遵循相同的方法来准备测试文档。

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

1. 我们什么时候编写测试用例？

当我们得到以下内容时，我们将编写测试用例：

• 当客户提出业务需求时，开发人员开始开发并说他们需要 3.5 个月来构建此产品。
• 与此同时，测试团队将开始编写测试用例。
• 完成后，它会将其发送给测试主管进行审查过程。
• 当开发人员完成产品开发后，它被移交给测试团队。
• 测试工程师在测试产品文档时从不查看需求，因为测试是恒定的，不依赖于人的情绪而不是测试工程师的素质。

2. 我们为什么要编写测试用例？

我们将编写测试，原因如下：

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

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

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

这取决于过程而不是一个人：测试工程师在第一个版本、第二个版本期间测试了应用程序，并在第三个版本发布时离开了公司。当测试工程师理解模块并通过推导许多值来彻底测试应用程序时。如果这个人不在第三次发布，那么新人就会变得困难。因此，所有派生值都被记录下来，以便将来可以使用。

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

3. 测试用例模板

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

众所周知，实际结果是在测试用例执行之后编写的，大多数情况下，它将与预期结果相同。但如果测试步骤失败，情况会有所不同。因此，可以跳过实际的结果字段，在“注释”部分中，我们可以写下有关错误的信息。

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

我们上面讨论的上述模板不是标准模板，因为它可能因公司而异，也可能因每个应用程序而异，这取决于测试工程师和测试负责人。但是，为了测试一个应用程序，所有测试工程师都应该遵循一个通常的模板，该模板是制定的。

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

在上面的示例模板中，标头包含以下内容：

3.1 步骤编号

这也是必不可少的，因为如果步骤 20 失败，我们可以记录错误报告，从而确定工作的优先级，并决定它是否是一个严重的错误。

3.2 测试用例类型

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

3.3 释放

一个版本可以包含该版本的多个版本。

3.4 前提条件

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

例如：在应用程序中，我们正在编写测试用例来添加用户、编辑用户和删除用户。如果在编辑和删除用户 A 之前添加了用户 A，则会看到每个条件。

3.5 测试数据

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

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

测试负责人可以获得测试数据如用户名或密码来测试应用程序， 或者测试工程师可以自己生 用户名和密码。

3.6 严重性

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

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

例如，我们将采用Gmail应用程序，让我们根据模块查看严重性：

3.7 简要说明

测试工程师为特定功能编写了测试用例。如果他/她暂时来阅读测试用例，他/她将不知道它是为了什么功能编写的。因此，简要说明将帮助他们编写哪个功能测试用例。

4. 测试用例模板示例

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

5. 测试用例的类型

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

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

5.1 功能测试用例

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

在功能测试中，或者如果应用程序是数据驱动的，我们需要输入列;这有点耗时。

编写功能测试用例的规则：

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

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

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

5.2 集成测试用例

在这种情况下，我们不应该写一些我们已经在功能测试用例中涵盖过的东西，我们在集成测试用例中写的东西也不应该再写在系统测试用例中。

编写集成测试用例的规则

• 了解产品
• 确定可能的方案
• 根据优先级编写测试用例

测试工程师在编写测试用例时，可能需要考虑以下几个方面：

如果测试用例是详细的：

• 他们将尝试实现最大的测试覆盖率。
• 正确描述了所有测试用例值或方案。
• 他们会尝试思考执行的观点。
• 用于编写测试用例的模板必须是唯一的。

5.3 系统测试用例

我们将为端到端业务流程编写系统测试用例。我们已经准备好了整个模块来编写系统测试用例。

6. 编写测试用例的过程

编写测试用例的方法可以分为以下步骤完成，具体如下：

6.1 系统研究

在这种情况下，我们将通过查看客户给出的要求或SRS来了解应用。

6.2 确定所有方案

• 当产品推出时，最终用户可以使用该软件来识别所有可能的方式是什么。
• 我已经在一个文档中记录了所有可能的情况，这称为测试设计/高级设计。
• 测试设计是具有所有可能场景的记录。

6.3 编写测试用例

将所有已识别的方案转换为测试声明，并对与其功能相关的方案进行分组，确定模块的优先级，并通过应用测试用例设计技术编写测试用例并使用标准测试用例模板，这意味着为项目决定的模板。

6.4 查看测试用例

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

6.5 测试用例批准

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

6.6 存储在测试用例存储库中

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