如何编写测试用例（附示例）
托马斯·汉密尔顿
什么是测试用例？
A 测试用例 是一套 行动、投入和预期结果 它帮助测试人员验证软件中的特定特性或功能是否按预期工作。它起到以下作用： 一步一步的指导 它定义了要测试什么、如何测试以及预期结果是什么。
把测试用例想象成…… 验证方法 它会告诉你确切的配料（测试数据）、制作过程（执行步骤）以及一道完美的菜肴（预期结果）应该是什么样子。
编写良好的测试用例有助于确保：
- 该软件符合 业务和用户需求。
- 程序错误或意外行为 发现得早。
- 测试可以是 反复审查 任何质量保证专业人员均可胜任。
- 团队可以 追踪 每个测试验证的是哪项要求？
👉 免费注册实时软件测试项目
手动测试中创建测试用例的步骤
让我们为该场景创建一个测试用例：检查登录功能
步骤1） 一个简单的测试用例来解释这个场景
| 测试用例 ＃ | 测试用例 Description |
|---|---|
| 1 | 输入有效的电子邮件和密码后检查响应 |
步骤2） 测试数据。
为了执行测试用例，你需要 测试数据. 在下面添加
| 测试用例 ＃ | 测试用例 Description | 测试数据 |
|---|---|---|
| 1 | 输入有效的电子邮件和密码后检查响应 | 电子邮件: guru99@email.com 密码：lNf9^Oti7^2h |
识别测试数据可能非常耗时，有时可能需要重新创建测试数据。这就是需要记录的原因。
步骤3） 执行动作。
为了执行测试用例，测试人员需要在 AUT 上执行一组特定的操作。具体如下：
| 测试用例 ＃ | 测试用例 Description | 测试步骤 | 测试数据 |
|---|---|---|---|
| 1 | 输入有效的电子邮件和密码后检查响应 | 1）输入电子邮件地址
2）输入密码 3）点击登录 |
电子邮件: guru99@email.com
密码：lNf9^Oti7^2h |
很多时候，测试步骤并不像上面那样简单，因此需要文档记录。此外，测试用例的编写者可能会离职、休假、生病或忙于其他重要任务。新员工可能会被要求执行该测试用例。文档化的步骤不仅能帮助他，还能方便其他利益相关者进行审查。
步骤4） 检查被测系统（AUT）的行为。
软件测试中测试用例的目标是检查被测系统 (AUT) 的行为是否符合预期结果。这需要按如下方式记录：
| 测试用例 ＃ | 测试用例 Description | 测试数据 | 预期结果 |
|---|---|---|---|
| 1 | 输入有效的电子邮件和密码后检查响应 | 电子邮件: guru99@email.com 密码：lNf9^Oti7^2h |
登录应该成功 |
在测试执行期间，测试人员将根据实际结果检查预期结果并指定通过或失败状态
| 测试用例 ＃ | 测试用例 Description | 测试数据 | 预期结果 | 实际结果 | 成功/失败 |
|---|---|---|---|---|---|
| 1 | 输入有效的电子邮件和密码后检查响应 | 电子邮件：guru99@email.com 密码：lNf9^Oti7^2h | 登录应该成功 | 登录成功 | 通过 |
步骤5） 除此之外，你的测试用例可能还有类似的字段，
前提条件指定了测试运行前必须满足的条件。例如，对于我们的测试用例，前提条件是必须安装浏览器才能访问被测网站。测试用例还可以包含后置条件，指定测试用例完成后必须执行的操作。例如，对于我们的测试用例，后置条件是登录时间和日期必须存储在数据库中。
测试用例的关键要素
一个标准的测试用例通常包括：
- 测试用例 ID – 唯一标识符（例如，TC001）
- 标题或 Description 测试验证的内容
- 前提条件 测试开始前必须具备的条件
- 测试步骤 要执行的具体操作
- 测试数据 输入值或参数
- 预期结果 你应该看到的结果
- 实际结果 实际发生了什么？
- 状态 通过、不通过或被拒
测试用例与测试场景
A 测试场景 描述需要测试的内容——是整体功能还是用户体验流程。
A 测试用例 另一方面，它解释了如何验证该功能——具体步骤、数据和预期结果。
简单来说：
- 测试场景 = 想法 要测试的内容。
- 测试用例 = 实现 如何检验这个想法。
不妨这样想——
“如果把测试场景比作章节标题，那么每个测试用例就是对该章节进行详细解释的段落。”
示例说明：
我们举个例子来说明：
测试场景：
“检查网站的登录功能。”
相关测试用例：
- 请使用有效的用户名和密码验证登录。
- 请核对错误信息，确认密码是否无效。
- 使用空字段验证登录。
- 验证密码字段会隐藏输入文本。
这里的情况是…… 单功能目标， 而测试用例则将其分解 具体、可测试的条件。
阅读更多关于……的信息 测试用例与测试场景的区别
编写高质量测试用例的好处
- 高质量的测试用例确保全面彻底。 测试覆盖率 在整个质量保证过程中保持一致性和可追溯性。
- 它们帮助测试人员发现 及早发现问题， 保持 回归稳定性并确保每项功能都符合业务需求。
- 编写良好的测试用例是 清晰、可重复使用、可重复操作 允许任何测试人员或自动化工具可靠地执行这些测试。
- 它们也起到……的作用 沟通桥梁 促进开发人员、测试人员和利益相关者之间的沟通——减少歧义并节省时间。
- 通过记录测试目标、步骤和结果，团队可以 衡量进度，遵守标准， 并高效地管理更新。
- 最重要的是，要有好的测试用例。 降低维护成本 加快自动化速度并提供 对软件质量的信心。
- 它们既可作为新测试人员入职培训的动态文档，也可作为人工智能的结构化输入。 测试管理工具。
编写测试用例时应避免的常见错误
即使是经验丰富的测试人员也会犯一些小错误，从而降低测试质量。
避免这些错误可以显著提高…… 准确性、清晰度和可维护性 你的测试套件。
- 步骤描述含糊不清： 像“检查登录页面”这样含糊不清的指令会让测试人员感到困惑。请使用清晰、以操作为导向的步骤。
- 忽略负面情况： 务必包含无效输入或边界测试，以确保全面覆盖。
- 重复使用不明确的测试数据： 未标记或不一致的数据会导致测试结果不可靠。请维护一份共享的测试数据表。
- 测试用例过于复杂： 冗长、多步骤的案例难以维护。保持每个案例的简洁性和原子性。
- 产品变更后忽略更新： 过时的测试用例会产生错误的结果。 Rev定期查看和复习。
- 缺乏可追溯性： 始终将测试用例与需求关联起来，以便跟踪覆盖率和合规性。
- 跳过同行评审： 新鲜的视角能及早发现不清晰或冗余的步骤。
