定义测试用例和优先级

确定要测试的内容、定义测试用例并确定优先级。

Ramona Schwering

在上篇文章中，您了解了测试策略、测试应用所需的测试数量，以及如何在考虑资源的情况下，找到最合适的测试策略，以对结果有足够的信心。不过，这只能让我们大致了解需要测试多少次。您仍需确定要测试的确切内容。 以下三个标准有助于您了解测试中可能出现的情况，以及哪种测试类型和详细程度最合适：

1. 照顾好您的幸福之路。这是应用最常见或主要的用户故事，用户会非常快地注意到错误。
2. 仔细确定详细程度。如果您的用例容易受到攻击，或者错误会造成严重损害，请详细说明。
3. 尽可能优先执行低级别测试（例如单元测试和集成测试），而不是高级别端到端测试。

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

什么是测试用例？

在软件开发中，测试用例是指为确认软件程序或应用的有效性而设计的一组操作或环境。 测试用例旨在确保软件按计划运行，并且其所有功能都能正常运行。软件测试人员或开发者通常会创建这些测试用例，以确保软件符合指定的要求和规范。

运行测试用例时，软件会执行一系列检查，以确保其生成预期结果。在此过程中，测试会执行以下任务：

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

假设该程序未能达到预期结果。在这种情况下，测试用例将充当信使，因此会报告失败结果，而开发者或测试人员需要调查问题并找出解决方案。无论测试类型如何，请将检查和操作视为计算机遵循的路径。用于检查的一组输入数据或条件称为“等效类”。他们应该会从被测系统获得类似的行为或结果。测试中执行的具体路径可能会有所不同，但应与测试中执行的活动和断言一致。

测试路径：典型测试用例

在软件开发中，测试用例是指预期会出现某种行为并对其进行测试的代码执行场景。通常，有三种场景可用于构成测试用例。

第一种是最为人熟知的，您可能已经在使用了。它是理想路径，也称为“理想场景”或“理想路径”。它定义了功能、应用或更改的最常见用例，即客户应如何使用这些功能、应用或更改。

在测试用例中要涵盖的第二个最重要的测试路径通常会被忽略，因为它不舒服，这可能与其名称有关。这条路径被称为“可怕的路径”，换句话说，就是负面测试。此路径定位到导致代码行为异常或进入错误状态的场景。如果您有极易受到攻击的用例，会给利益相关方或用户带来较高的风险，那么测试这些场景尤为重要。

您可能还需要了解并考虑使用一些其他路径，但这些路径通常不太常用。下表总结了这些变化：

您可以通过多种方法对这些路径进行分类。两种常见方法如下：

• 等效分区。一种测试方法，用于将测试用例分类为组或分区，从而有助于创建等效类。这一方法基于以下假设：如果分区中的某个测试用例发现了缺陷，则同一分区中的其他测试用例也可能会发现类似的缺陷。由于特定等价类中的所有输入都应具有相同的行为，因此您可以减少测试用例的数量。详细了解等价分区。
• 限制分析。一种测试方法，也称为边界值分析，用于检查输入值的极限或极端值，以发现系统功能或约束条件限制范围内可能出现的任何潜在问题或错误。

最佳实践：编写测试用例

测试人员编写的传统测试用例将包含特定数据，可帮助您了解要进行的测试的内容，当然也能执行测试。典型的测试人员会在表格中记录其测试工作。在此阶段，我们可以使用两种模式来帮助我们构建测试用例，并在后续构建测试本身：

• 准备、操作、断言模式。“准备、执行、断言”（也称为“AAA”或“三重 A”）测试模式是一种将测试分为三个不同的步骤的方法：准备测试、执行测试，以及最后总结。
• Given-When-Then 模式。此模式与 AAA 模式类似，但源自行为驱动型开发。

在介绍测试本身的结构后，我们将在后续文章中详细介绍这些模式。如果您想在此阶段深入了解这些模式，请参阅以下两篇文章：准备-操作-断言：编写优质测试的模式和 Given-When-Then。

根据本文中的所有学习内容，下表总结了一个经典示例：

在自动化测试中，您无需像测试人员那样记录所有这些测试用例，尽管这样做无疑很有帮助。只要您留意，就可以在测试中找到所有这些信息。现在，我们将这个传统的测试用例转换为自动化测试。