测试用例

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

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

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

测试用例通过将缺陷与测试用例 ID 联系起来，帮助测试人员报告缺陷。详细的测试用例文档为测试团队提供了全面的证据保护，因为如果开发人员遗漏了某些内容，那么在执行这些全面的测试用例时可以发现它。

要编写测试用例，我们必须有导出输入的要求，并且必须编写测试场景，以便我们不会错过任何测试功能。那么我们应该有测试用例模板来保持一致性，或者每个测试工程师都按照相同的方法来准备测试文档。

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

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

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

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

注意：在编写测试用例时，不应编写实际结果，因为产品仍处于开发过程中。这就是为什么应该在测试用例执行后才写入实际结果。

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

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

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

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

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

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

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

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

测试用例模板

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

我们知道，实际结果是在测试用例执行后写入的，大多数情况下，它会与预期结果相同。但是如果测试步骤会失败，那就不同了。所以，可以跳过实际结果字段，在评论部分，我们可以写下错误。

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

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

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

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

步数

这也很重要，因为如果第 20 步失败，我们可以记录错误报告，从而确定工作的优先级，并确定它是否是严重错误。

测试用例类型

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

释放

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

前提

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

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

测试数据

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

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

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

严重性

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

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

例如，我们将使用 Gmail 应用程序，让我们查看基于模块的严重性：

模块	严重性
登录	危急
帮助	次要的
撰写邮件	危急
环境	次要的
收件箱	危急
发送的邮件	主要的
登出	危急

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

模块	严重性
转账金额	危急
反馈	次要的

简要描述;简介

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

测试用例模板示例

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

测试用例类型

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

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

功能测试用例

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

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

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

• 在预期结果栏中，尝试使用should be或must be。
• 突出显示对象名称。
• 我们只需要描述我们最需要的那些步骤；否则，我们不需要定义所有步骤。
• 为了减少多余的执行时间，我们将正确编写步骤。
• 编写通用测试用例；不要尝试对其进行硬编码。

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

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

集成测试用例

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

编写集成测试用例的规则

• 一、了解产品
• 确定可能的场景
• 根据优先级编写测试用例

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

如果测试用例很详细：

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

注意：当我们涉及的步骤数较少或覆盖率较高时，它应该是最好的测试用例，当这些测试用例提供给任何人时，他们都会很容易理解。

系统测试用例

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

编写测试用例的过程

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

系统研究

在此，我们将通过查看客户提供的要求或 SRS 来了解应用程序。

识别所有场景：

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

编写测试用例

将所有识别的场景转换为测试声明，并将与其特性相关的场景分组，对模块进行优先级排序，并通过应用测试用例设计技术和使用标准测试用例模板编写测试用例，这意味着为项目决定的.

查看测试用例

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

测试用例批准

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

存储在测试用例存储库中

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