定义测试用例和优先级

确定要测试的内容，定义测试用例并确定优先事项。

Ramona Schwering

在上一篇博文中，您了解了测试策略、测试应用所需的测试数量，以及如何找到最佳方案来获得最大的可信度，同时牢记资源要求。不过，这只是让我们了解要测试多少内容。您仍然需要准确确定要测试的内容。 以下三个标准有助于您了解测试的内容，并了解最适合的测试类型和详细程度：

  1. 照顾好您的幸福之路。这是您的应用最普遍或最主要的用户案例，您的用户很快就会发现错误。
  2. 仔细决定详细程度。如果您的用例存在漏洞，或者错误会造成严重损害，请详细说明。
  3. 尽可能优先测试较低级别的测试（例如单元测试和集成测试），而非较高级别的端到端测试。

本文的其余部分将探讨这些标准，以及在定义测试用例时如何应用这些标准。

什么是测试用例？

在软件开发中，测试用例是为确认软件程序或应用的有效性而设计的一系列操作或情况。 测试用例旨在确保软件按预期运行，并确保软件的所有特性和功能正常运行。软件测试人员或开发者通常会创建这些测试用例，以确保软件满足指定的要求和规范。

测试用例正在验证。

在运行测试用例时，该软件会执行一系列检查，以确保能够产生所需的结果。在此过程中，测试会执行以下任务：

  • 验证。对软件进行全面检查以确保其正常运行的过程。确定创建的产品是否满足所有必要的非功能要求以及成功实现其预期用途至关重要。它解答的问题是：“我们打造的产品是否正确？”
  • 验证。确保软件产品符合必要标准或高级要求的过程。这涉及检查实际商品是否与预期商品一致。从本质上讲，我们要回答的问题是：“我们是否构建了符合用户要求的产品？”

假设程序未能提供预期结果。在这种情况下，测试用例会是 Messenger，因此会报告失败结果，开发者或测试人员需要调查问题并寻找解决方案。 无论测试类型如何，请将检查和操作视为计算机会遵循的路径。用于检查的输入数据组或条件称为“等价类”。它们应该从被测系统中获得类似的行为或结果。在测试内执行的特定路径可能会有所不同，但应与测试中完成的 activity 和断言一致。

测试路径：测试用例的典型类型

在软件开发中，测试用例是一种代码执行场景，在此场景中，系统会预期并测试特定行为。通常，有三种场景可以用来构建测试用例。

幸福之路。

第一种是最广为人知的方法，您可能已经在用。这就是“幸福路径”，也称为“幸福日场景”或“黄金之路”。它定义了功能、应用或变更的最常见用例，即为客户带来理想成效的方式。

恐怖之路。

测试用例中要涵盖的第二关键的测试路径往往会被遗漏，因为其不太适合（顾名思义）。这就是“恐怖之路”，换句话说，这就是消极测试。此路径针对会导致代码运行异常或进入错误状态的场景。当您遇到容易给利益相关者或用户带来高风险的易受攻击用例时，测试这些场景尤为重要。

您可能想了解并考虑使用其他一些路径，但通常不太常用。下表对其进行了总结：

测试路径 说明
愤怒的路径 这会导致错误，但这属于正常现象；例如，当您想要确保错误处理能够正常运行时。
欠款路径 此路径适用于您的应用需要实现的任何安全相关场景。
荒野之路 在您的应用中测试场景的路径没有获得足够的数据来发挥作用，例如，测试 null 值。
令人难忘的道路 在资源不足的情况下测试应用的行为，例如触发数据丢失。
犹豫不决的路径 让尝试在您的应用中执行操作或关注用户案例但尚未完成这些工作流的用户进行测试。例如，当用户中断工作流程时。
贪心路径 尝试使用大量输入或数据进行测试。
充满压力的路径 尝试以任何必要方式对应用进行负载，直至应用无法正常工作（类似于负载测试）。

您可以使用多种方法来对这些路径进行分类。两种常见的方法是：

  • 等效分区。一种将测试用例划分为多个组或分区的测试方法，因此有助于创建等效类。基于以下理念：如果分区中的一个测试用例发现缺陷，则同一分区中的其他测试用例也有可能显示类似的缺陷。由于特定等价类中的所有输入应表现出相同的行为，因此您可以减少测试用例的数量。详细了解等效分区。
  • 限制分析。测试方法也称为“边界值分析”，它会检查输入值的限制或极端，找出可能因系统功能限制或限制而可能出现的任何问题或错误。

最佳实践：编写测试用例

由测试人员编写的经典测试用例将包含特定数据，以帮助您了解要执行的测试的内容，当然，还要执行测试。典型的测试人员会在表格中记录他们的测试工作。在这个阶段，我们可以使用两种模式，帮助我们构建测试用例，之后构建测试本身：

  • Arrange, act, assert（排列、操作、断言）模式。“排列、执行、断言”（也称为“AAA”或“三重 A”）测试模式是一种将测试组织成三个不同步骤的方式：安排测试，执行测试，最后但同样重要的是得出结论。
  • Given, when, then 模式。这种模式与 AAA 模式类似，但具有某些行为驱动型开发的根基。

我们在介绍测试本身的结构后，会在以后的文章中详细介绍这些模式。如果您想在此阶段更深入地了解这些模式，请查看以下两篇文章：Arrange-Act-Assert: A pattern for write good testing 和 Given-When-Then。

根据本文的所有经验，下表总结了一个典型示例：

信息 说明
前提条件 在编写测试之前需要完成的一切。
要测试的对象 需要验证的内容
输入数据 变量及其值。
要执行的步骤 为实现测试而需要执行的所有操作：在测试中执行的所有操作或互动。
预期结果 应发生的情况以及要满足的预期。
实际结果 实际情况。

在自动化测试中，您不需要按照测试人员需要的方式记录所有这些测试用例，尽管这样做毫无疑问有帮助。请注意，您可以在测试中找到所有这些信息。接下来，我们就将这个经典测试用例转换为自动化测试。

信息 转换为测试自动化
前提条件 您需要的所有内容、安排测试，以及考虑提供哪些元素来实现测试场景。
要测试的对象 这个“对象”可以是各种内容：应用、流程、单元或被测组件。
输入数据 参数值。
要执行的步骤 在测试中执行的所有操作和命令、操作的内容，以及了解执行特定操作时会发生什么情况。
预期结果 您用来验证应用的断言，即您在应用中所断言的内容。
实际结果 自动化测试的结果。