测试用例

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

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

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

测试用例通过将缺陷与测试用例ID链接起来，帮助测试人员进行缺陷报告。详细的测试用例文档可以作为测试团队的全面证明，因为如果开发人员错过了某些东西，则可以在执行这些完全验证的测试用例时将其捕获。

要编写测试用例，我们必须具有导出输入的要求，并且必须编写测试方案，以便我们不会错过任何要测试的功能。然后，我们应该拥有测试用例模板以保持一致性，否则每个测试工程师都将采用相同的方法来准备测试文档。

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

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

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

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

注意：编写测试用例时，切勿写出实际结果，因为产品仍在开发过程中。这就是为什么仅在执行测试用例之后才写入实际结果的原因。

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

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

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

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

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

它取决于过程，而不取决于人员：测试工程师已经在第一个版本，第二个版本中测试了一个应用程序，并在第三个版本时离开了公司。当测试工程师理解模块并通过推导许多值来彻底测试应用程序时。如果此人不在第三版本中，那么新人将很难。因此，所有派生的值都被记录在案，以便将来使用。

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

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

测试案例模板

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

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

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

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

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

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

步骤编号

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

测试用例类型

它可以是功能，集成或系统测试用例，也可以是肯定或否定或肯定和否定测试用例。

发布

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

前提

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

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

测试数据

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

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

可以为测试负责人提供诸如用户名或密码之类的测试数据以测试应用程序，或者测试工程师可以自己生成用户名和密码。

严重程度

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

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

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

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

简要描述;简介

测试工程师已经为特定功能编写了一个测试用例。如果他/她暂时来并阅读了测试用例，他/她将不知道写了什么功能。因此，简短的描述将帮助他们编写功能测试用例。

测试案例模板的示例

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

测试用例的类型

我们有另一种测试用例，如下：

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

功能测试案例

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

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

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

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

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

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

集成测试用例

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

编写集成测试用例的规则

• 首先，了解产品
• 确定可能的情况
• 根据优先级编写测试用例

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

如果测试用例详细：

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

注意：当我们涉及的步骤数量减少或覆盖范围更多时，它应该是最好的测试用例，并且将这些测试用例提供给任何人时，他们将很容易理解。

系统测试用例

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

编写测试用例的过程

编写测试用例的方法可以完成以下步骤，如下所示：

系统研究

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

确定所有方案：

• 产品发布时，最终用户可以使用哪些方式来识别所有可能的方式。
• 我已经在文档中记录了所有可能的场景，称为测试设计/高级设计。
• 测试设计是具有所有可能方案的记录。

编写测试用例

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

查看测试用例

通过将测试用例提供给团队负责人来进行审核，然后修复由审核者提供的审核反馈。

测试用例批准

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

存储在测试用例存储库中

在批准特定的测试用例之后，将其存储在熟悉的地方，即测试用例存储库。

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

https://www.javatpoint.com/test-case-review-process