定义测试用例和优先级

通过集合保持井井有条 根据您的偏好保存内容并进行分类。

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

在上一篇帖子中，您了解了测试策略、测试应用程序所需的测试数量，以及如何找到最适合的方案，以便在考虑到您的资源的同时，对结果获得最大的信心。但是，这只让我们了解了要测试多少内容。您仍然需要确定要测试的具体内容。以下三个标准可以帮助您了解测试的预期内容，并了解哪种测试类型和详细程度可能最适合

1. 关注您的顺畅路径。这是您应用程序最通用或最主要的用户故事，您的用户将很快注意到错误。
2. 仔细决定详细程度。如果您的用例容易受到攻击，或者错误会造成重大损害，则需要更详细地了解。
3. 尽可能优先考虑较低级别的测试，例如单元测试和集成测试，而不是较高级别的端到端测试。

本文的其余部分探讨了这些标准，以及当您定义测试用例时，它们如何应用。

什么是测试用例？

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

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

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

假设程序未能交付预期的结果。在这种情况下，测试用例将充当信使—从而报告不成功的结果，开发人员或测试人员将需要调查问题并找到解决方案。将检查和操作视为计算机遵循的路径，而与测试类型无关。用于检查的输入数据或条件的组称为“等价类”。它们应该从被测系统中获得相似的行为或结果。测试内部执行的特定路径可能会有所不同，但应与测试中完成的活动和断言相匹配。

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

在软件开发中，测试用例是代码执行场景，从中可以预期和测试某种行为。通常，有三种场景可以从中形成测试用例。

第一个是最广为人知的，您可能已经在使用了。它是顺畅路径，也称为“愉快日场景”或“黄金路径”。它定义了您的特性、应用程序或更改最常见的用例—客户应该如何使用它。

在您的测试用例中要涵盖的第二个最重要的测试路径通常被忽略，因为它令人不舒服—正如其名称可能暗示的那样。它是“可怕路径”，或者换句话说，是负面测试。此路径针对导致代码行为不当或进入错误状态的场景。如果您有高度脆弱的用例，会对利益相关者或用户造成高风险，那么测试这些场景尤其重要。

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

测试路径	说明
愤怒路径	这会导致错误，但这是一个预期的错误；例如，如果您想确保错误处理工作正常。
违规路径	此路径处理您的应用程序需要满足的任何安全相关场景。
荒凉路径	测试应用程序中场景的路径没有获得足够的数据来运行，例如，测试空值。
健忘路径	使用资源不足的情况下测试应用程序的行为，例如，触发数据丢失。
犹豫不决路径	测试用户尝试在您的应用程序中执行操作或遵循用户故事，但尚未完成这些工作流程的情况。例如，当用户中断其工作流程时，可能会出现这种情况。
贪婪路径	尝试使用大量输入或数据进行测试。
压力路径	尝试通过任何必要的方式对您的应用程序施加负载，直到它不再运行（类似于负载测试）。

有几种方法可以对这些路径进行分类。两种常见的方法是

• 等价划分。一种测试方法，将测试用例分类为组或分区，从而帮助创建等价类。这基于这样的想法，即如果分区中的一个测试用例发现了一个缺陷，则同一分区中的其他测试用例也可能揭示类似的缺陷。由于特定等价类中的所有输入都应表现出相同的行为，因此您可以减少测试用例的数量。了解有关等价划分的更多信息。
• 限制分析。一种测试方法，也称为边界值分析，它检查输入值的限制或极端值，以查找可能在系统功能或约束限制处出现的任何潜在问题或错误。

最佳实践：编写测试用例

测试人员编写的经典测试用例将包含特定数据，以帮助您掌握要进行的测试的内容，当然，还要执行测试。典型的测试人员会将他们的测试工作记录在表格中。在此阶段，我们可以使用两种模式，帮助我们构建测试用例，以及稍后构建我们自己的测试

• Arrange, act, assert 模式。“arrange, act, assert”（也称为“AAA”或“Triple A”）测试模式是一种将测试组织成三个不同步骤的方式：安排测试，然后执行测试，最后但并非最不重要，得出结论。
• Given, when, then 模式。此模式与 AAA 模式类似，但在 行为驱动开发中具有一些根源。

未来的文章将更详细地介绍这些模式，一旦我们介绍了测试本身的结构。如果您想在此阶段更深入地了解这些模式，请查看以下两篇文章：Arrange-Act-Assert：编写优秀测试的模式和 Given-When-Then。

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

信息	说明
先决条件	在编写测试之前需要完成的所有操作。
被测对象	需要验证什么？
输入数据	变量及其值。
要执行的步骤	您将为使测试栩栩如生而做的所有事情：您在测试中执行的所有操作或交互。
预期结果	应该发生什么以及要满足哪些期望。
实际结果	实际发生的事情。

在自动化测试中，您不需要像测试人员那样记录所有这些测试用例，即使这样做无疑是有帮助的。如果您注意，您可以在测试中找到所有这些信息。因此，让我们将这个经典测试用例转换为自动化测试。

信息	转换为自动化测试
先决条件	您需要的所有东西，安排测试，并考虑为了使测试场景发生而给定的内容。
被测对象	这个“对象”可以是各种东西：应用程序、流程、单元或被测组件。
输入数据	参数值。
要执行的步骤	在测试内部执行的所有操作和命令，您所作用的事物，以及找出当您执行某些操作时会发生什么。
预期结果	您用于验证应用程序的断言，您在应用程序中断言的事物。
实际结果	自动化测试的结果。