新测试人员经常听到这两个术语，就好像它们的意思是相同的一样。他们没有。 测试用例与测试场景之间的区别主要在于细节程度，理解它可以帮助您在开始测试之前决定要写多少内容。

本指南对每一项进行了解释，然后通过单个密码重置功能，从要求到场景再到完整的测试用例。该特征及其规则是一个发明的例子。团队和工具之间的术语也略有不同，因此请就这些词在您自己的团队中的含义达成一致。

简短的回答

测试场景描述了要检查的情况，例如“验证用户是否可以重置忘记的密码”。它通常是一行，将细节留给测试人员。

测试用例准确地说明了如何检查该情况下的一个条件：先决条件、步骤、测试数据和预期结果。跟随它的两个测试人员应该得出相同的结论。

考虑计划一次旅行。该场景是“从浦那到德里的旅行”。测试用例是完整的行程，包括航班号、出发时间以及每个阶段要做什么。

测试用例与测试场景并排

什么是测试场景？

测试场景是对用户可能执行的操作或系统必须处理的情况的简要描述。它关注的是外部重要的事情，通常直接来自需求或用户故事。

场景很有价值，因为它们很快。您可以在编写三个详细案例所需的时间内列出三十个案例，这使得它们成为与产品负责人一起审查覆盖范围的好方法：“我们考虑到了所有事情吗？”非技术读者可以毫无困难地遵循一系列场景。

什么是测试用例？

测试用例是一组特定的条件和步骤，用于确定某件事是否有效。一个典型的测试用例包含：

• 唯一的 ID 和清晰的 标题
• 先决条件，意味着开始之前必须满足的条件
• 编号为的步骤
• 具体测试数据
• 预期结果
• 实际结果和状态，运行时填写

当一致性很重要时，测试用例就会大放异彩。新的团队成员可以运行它们，可以在版本之间比较结果，并且您可以记录已验证的内容。我们将在指南中更深入地介绍如何编写测试用例。

一个功能，从头到尾

第一步：需求

忘记密码的用户可以通过电子邮件请求重置链接。该链接有效一次，30 分钟后失效。新密码的长度必须至少为 8 个字符。

第 2 步：测试场景

看看 TS-02。该要求从未说明未知电子邮件会发生什么，而编写场景暴露了这一差距。页面是否应该显示该地址未注册？为了安全起见，通常不应该这样做，因为这会让攻击者发现有效的帐户。尽早发现这些问题是编写场景的最大好处之一。

第 3 步：测试用例

现在我们仅将 TS-05 扩展到测试用例中。一种场景变成多种场景：

这些值不是随机的。 TC-051 和 TC-052 位于极限的两侧，使用边界值分析，其他来自等价划分。

测试用例模板

这是 TC-052 的全文。如果您的团队还没有标准，请复制此布局：

ID:            TC-052
Title:         Reset rejects a password of 7 characters
Scenario:      TS-05 New password rules are enforced
Priority:      High
Preconditions: Account asha@example.com exists
               A valid, unused reset link has been requested
Test data:     New password: abcd123

Steps:
  1. Open the reset link from the email
  2. Enter abcd123 in New password
  3. Enter abcd123 in Confirm password
  4. Click Reset password

Expected:      Error "Password must be at least 8 characters"
               Password is unchanged, and the link stays valid
Actual:        (filled in during the run)
Status:        (Pass / Fail / Blocked)

请注意，预期结果检查的内容不只是错误消息。它还确认旧密码仍然有效并且链接仍然可用。弱测试用例通常会停留在屏幕上可见的内容上。

它们在更大的图景中的位置

传统上，场景和案例是在软件测试生命周期的测试设计阶段编写的。

何时使用每个

在以下情况下，场景通常就足够了：

• 团队规模较小，经验丰富，并且非常了解产品。
• 时间很短，或者需求经常变化。
• 特点是风险低。
• 您希望与利益相关者一起快速审查覆盖范围。
• 您正在指导探索性测试。

在以下情况下，详细的测试用例值得付出努力：

• 失败的代价将是高昂的，就像支付、安全或健康数据一样。
• 监管机构或审计人员需要测试内容的证据。
• 新的或外包的测试人员必须运行测试。
• 结果必须准确重复，就像在回归套件中一样。
• 这些步骤将成为自动化测试。

大多数成熟的团队都会使用两者。他们列出了所有情况的情况，并只针对最高风险编写完整的案例。无需像银行转账一样记录低风险设置页面的每一步。

场景、案例和自动化

编写良好的测试用例几乎直接映射到自动化测试。前提条件成为设置，步骤成为行动，预期结果成为断言。行为驱动的开发框架甚至使用“场景”一词来表示其可执行规范：

Scenario: Reset rejects a short password
  Given I have opened a valid reset link
  When I submit the new password "abcd123"
  Then I see "Password must be at least 8 characters"
  And my password is unchanged

令人困惑的是，BDD 所谓的场景更接近于测试用例，因为它具有特定的数据和结果。这是就条款达成一致的一个很好的提醒。要自动执行这些检查，请参阅我们的 Playwright 教程 或 pytest 教程。

是什么让他们优秀

常见错误

• 只写快乐的路径。 大多数错误都存在于错误条件下，因此请包括应该失败的内容。
• 使用模糊的预期结果。“它应该正常工作”让任何测试人员都可以决定任何事情。
• 完整记录所有内容。 数千个无人维护的案例比一组有用的案例更糟糕。
• 跳过场景。直接跳到案例可能会忘记整个区域。
• 让案例变得陈旧。当产品发生变化时，旧案例会误导人们。定期查看它们。
• 将步骤与脆弱的细节联系起来。“单击顶部的蓝色按钮”会破坏任何重新设计。

最后的话

场景为您提供广度，测试用例为您提供深度。从下一个功能的场景开始，并与开发人员和产品所有者一起审查它们。然后仅将有风险的案例扩展为完整案例。你会更早地发现空白，并将写作时间花在重要的地方。

常见问题

继续学习