技术文章

测试用例是您的团队应执行的一组记录的操作，以验证软件应用程序的特定特性、功能或要求是否按预期工作。 

测试用例定义了在实际开始测试之前要测试的内容。 

如何编写有效的测试用例

编写良好的测试用例对于彻底和优化的软件测试过程至关重要。测试团队使用测试用例来： 

• 在开始测试之前计划需要测试什么以及如何测试

• 通过提供重要的详细信息（例如开始测试之前需要满足的前提条件以及测试期间要使用的示例数据）来提高测试效率

• 测量和跟踪测试覆盖率

• 将预期结果与实际测试结果进行比较，以确定软件是否按预期运行

• 记录您的团队过去如何测试您的产品以发现任何回归/缺陷或确认新软件更新没有引入任何意外问题。

以下是编写测试用例时需要考虑的四个常见要素：

1. 确定要测试的功能

您的软件的哪些功能需要测试？例如，如果您想测试网站的搜索功能，则需要将其搜索功能标记为测试。

2. 确定测试场景

可以测试哪些场景来验证功能的各个方面？用于测试网站登录功能的潜在测试场景示例包括：

• 使用有效或无效的凭据进行测试

• 使用锁定帐户进行测试

• 使用过期的凭据进行测试

确定正面和负面测试场景的预期结果非常重要。例如，对于具有有效凭据的登录测试场景，预期结果将是成功登录并重定向到用户的帐户页面。具有无效凭据的测试场景的预期结果将是一条错误消息并阻止访问帐户页面。

3. 识别测试数据

您将使用哪些数据来执行和评估每个测试场景的测试？例如，在使用无效凭据进行测试的登录测试场景中，测试数据可能包括不正确的用户名和密码组合。

4. 确定测试方法

一旦确定了测试用例的测试功能、场景和数据，您将更好地了解如何进行测试以获得最有效的结果。 

以下是此步骤的一些重要注意事项：

• 如果您是第一次测试新功能并需要确认特定功能，您可能需要编写更详细的测试步骤。例如，假设您正在测试电子商务网站的新结账流程。在这种情况下，您可能会包含详细步骤，例如将商品添加到购物车、输入运输和账单信息以及确认订单。

• 如果您的测试用例设计是探索性的或以用户接受为重点，您可以简单地编写您希望在测试期间完成的测试章程或任务。例如，如果您正在对移动应用程序上的新功能进行用户验收测试，您的任务可能是确保该功能的登录过程易于使用并满足用户的需求。

测试用例中应包含哪些内容 

在敏捷软件开发中，测试用例更像是大纲，而不是单个测试的分步说明列表。测试用例可以包括有关所需条件、依赖性、过程、工具和预期输出的详细信息。 

测试用例的七个常见元素包括：

1. 标题：  测试用例的标题指向正在测试的软件功能。

2. 描述（包括测试场景）：描述总结了测试中正在验证的内容。

3. 测试脚本（如果自动化）：在自动化测试中，测试脚本提供每个功能测试所需的数据和操作的详细描述。

4. 测试ID：每个测试用例都应该有一个唯一的ID，作为测试用例的标识符。为了清楚起见，测试用例 ID 应遵循标准命名约定。

5. 测试环境的详细信息：测试环境是测试软件或系统的受控设置或基础设施。

6. 注意：此部分包括有关测试用例的任何相关注释或详细信息，这些注释或详细信息不适合测试用例模板的任何其他部分。

测试用例模板

测试用例模板提供了一种结构化且有效的方法来记录、管理和执行测试用例，确保测试工作一致、记录良好并符合您的业务标准和要求。

在 TestRail 中，您可以在不同的项目和测试套件中重用测试用例模板，并自定义它们以符合特定的测试方法和项目要求。这些功能使其成为强大且适应性强的测试工具，可在测试过程中保持一致性、效率和组织。

在 TestRail 中编写测试用例时，您可以自定义四个默认模板：

1. 测试用例（文本）： 

图片：这个灵活的模板允许用户描述测试人员应该采取的步骤，以便更流畅地测试给定的案例。 

2. 测试用例（步骤）

图片：此模板允许您向测试的每个步骤添加单独的结果状态，以及每个步骤的缺陷、需求或其他外部实体的链接。这种区别为您提供了更好的可见性、结构和可追溯性。

3. 探索性会议

图片： TestRail 的探索性会话模板使用文本字段，您可以在其中定义您的使命和目标，这将指导您完成探索性测试会话。

4. 行为驱动开发

图片：此模板允许您直接在 TestRail 中设计和执行 BDD 场景。用户还可以将测试定义为场景。BDD 中的场景通常遵循Give-When-Then (GWT) 格式。

测试用例模板通过提供标准化格式来增强一致性，使创建、执行和分析测试用例变得更加容易，并通过捕获有关测试场景和过程的重要信息来确保文档记录。 

测试用例编写最佳实践 

开发有效的测试用例对于确保高质量的软件至关重要。以下是编写优化测试用例的一些最佳实践： 

1. 根据优先级编写测试用例

根据测试用例的重要性和对软件的潜在影响确定测试用例的优先级。您可以使用优先级系统来帮助确定应首先编写和执行哪些测试用例。 

您可以使用这些测试用例优先级测试技术来确定优先级并识别更高优先级的测试用例：

• 基于风险的优先级

• 基于历史的优先级

• 基于覆盖范围的优先级

• 基于版本的优先级

• 基于成本的优先级

例如，假设您正在测试电子商务应用程序并使用基于风险的优先级来编写测试用例。在这种情况下，验证销售税正确计算的测试用例可能比验证按钮颜色的测试用例具有更高的优先级和风险级别。

2. 让您的测试用例清晰易懂

您的测试用例应该清晰且易于理解，以便测试团队中的任何人都能准确地知道测试的目的。 

附件、屏幕截图或录音有助于说明步骤。例如，假设您正在测试登录功能。在这种情况下，您的测试用例应清楚地说明登录步骤、要使用的登录凭据以及预期结果，例如成功显示用户仪表板。

确保测试用例名称易于理解和引用。标题应该表明测试用例属于哪个项目，以及它的用途。在处理数千个测试用例时，易于遵循的命名约定尤其重要。 

在命名与可重用对象相关的测试用例时，请考虑在标题中包含该信息。有关先决条件、附件和测试环境数据的信息应记录在测试用例描述中。

3. 指定预期结果

预期结果可以帮助您确保正确执行测试并且软件按预期运行。指定测试用例的预期结果可为您提供与实际结果进行比较的参考点。

例如，如果您正在测试购物车功能的工作情况，则此测试用例的预期结果将指定所选商品已成功添加到购物车并且购物车显示正确的价格。 

4. 为快乐和不快乐的路径编写测试用例

为了最大程度地覆盖软件需求，您必须编写覆盖尽可能多场景的测试用例。 

快乐路径是指用户与软件交互时通常采用的常见路径。不愉快的路径表示用户行为异常的场景。覆盖这些不愉快的路径非常重要，以确保显示正确的错误消息，帮助用户导航，这样他们就不会意外地破坏您的软件。

例如，如果您正在电子商务网站上测试搜索功能，则快乐路径测试用例可能会搜索特定产品并成功找到它。不幸路径测试用例可能是搜索不存在的产品并验证是否显示适当的错误消息。

5. 检查您的测试用例 

与团队合作定期审查和完善测试用例。随着产品的发展，测试用例可能需要更新以反映需求或功能的变化。这种审查对于经历重大变化的产品尤其重要，例如添加新功能、增强功能或要求修改。

同行评审还有助于识别测试用例中的任何差距、不一致、歧义、误导性步骤或错误，并确保它们满足所需的标准。 

例如，假设电子商务网站更改了其支付网关提供商。在这种情况下，有必要审查现有的测试用例，以确保它们仍然涵盖所有必要的测试场景和要求，即使支付网关提供商发生变化也是如此。 

最重要的是，有效编写和管理测试用例是软件测试不可或缺的一部分，需要仔细规划、关注细节和清晰的沟通。通过实施测试用例编写最佳实践并使用 TestRail 等专用测试用例管理工具，您可以达到所需的组织和细节级别。 

图片： TestRail 直观的界面使您可以轻松地编写和组织测试用例，只需输入测试用例的前提条件、测试说明、预期结果、优先级和工作量估计即可。 

TestRail 的可定制和可重用的测试用例模板还提供了用于记录测试用例的预定义格式，使创建、执行和分析测试变得更加容易。 

这种测试流程的灵活性和可见性使 TestRail 能够轻松融入任何组织的测试计划 —免费试用 TestRail，看看它如何帮助您制定测试计划。