一、测试用例设计基础：定义、重要性与核心要素

大家好，我是老赵。今天咱们聊聊测试用例设计最基础的东西。

说实话，我带过不少新人，很多人一上来就急着写用例，结果写出来的东西要么漏测，要么别人看不懂。为什么会这样？说白了，就是没把基础打牢。

1.1 什么是测试用例？

测试用例，英文叫 Test Case。简单来说，就是一份操作说明书。

它告诉你：

• 在什么条件下开始测
• 按什么步骤操作
• 期望看到什么结果

我个人的习惯是，把测试用例想象成「菜谱」。你照着菜谱做菜，只要步骤对，味道就不会差太多。测试用例也是这个道理——照着它测，就能判断功能对不对。

1.2 测试用例为什么重要？

你可能觉得，写用例浪费时间。我以前也这么想。

记得有一次，我接手一个紧急项目，时间紧任务重。我心想「凭经验直接测吧」，结果呢？测了三天，漏了两个严重 bug，上线后被用户骂惨了。从那以后，我再也不敢不写用例了。

测试用例的重要性，我总结为四点：

1. 保证覆盖率 —— 避免凭感觉测，漏掉边界场景
2. 可重复执行 —— 回归测试时，照着用例跑就行
3. 知识传承 —— 新人来了，看用例就能上手
4. 评估工作量 —— 用例数量 = 测试工作量的量化指标

1.3 测试用例的核心要素

一个完整的测试用例，必须包含以下 7 个要素。我一个个说。

1.3.1 用例编号（ID）

每个用例的唯一标识。我习惯用「模块_功能_编号」的格式，比如 LOGIN_001、PAY_001。

嗯，这里要注意：编号要有规律，别乱起。不然回头找用例，能把你找疯。

1.3.2 标题

一句话说清楚测什么。比如「登录成功-正确用户名和密码」。

标题要简洁，别人一看就知道测的是哪个场景。

1.3.3 前置条件

开始测试前，需要满足的条件。比如：

• 用户已注册
• 数据库中有测试数据
• 网络连接正常

我曾经见过一个新人，前置条件写「打开浏览器」——这其实不算前置条件，这是测试步骤的一部分。别搞混了。

1.3.4 测试步骤

一步一步的操作指令。要写得清晰、可执行。

举个例子：

步骤1：打开登录页面
步骤2：输入用户名 "admin"
步骤3：输入密码 "123456"
步骤4：点击「登录」按钮

注意：步骤不要写「输入正确的用户名」这种模糊描述。什么叫「正确」？你得写具体值。

1.3.5 预期结果

执行完步骤后，系统应该表现出的行为。这是测试用例的「灵魂」。

比如：

• 页面跳转到首页
• 右上角显示用户名「admin」
• 数据库 user 表中新增一条登录记录

1.3.6 实际结果

执行测试后，系统实际表现出的结果。这个是在测试执行时填写的。

如果实际结果和预期结果一致，用例状态就是「通过」。不一致，就是「失败」。

1.3.7 状态

用例的执行状态。常见的有：

• 通过（Pass）
• 失败（Fail）
• 阻塞（Blocked）
• 未执行（Pending）

我一般用表格来管理这些要素，清晰直观。下面是一个示例：

ID	标题	前置条件	测试步骤	预期结果	实际结果	状态
LOGIN_001	登录成功-正确用户名和密码	用户已注册（admin/123456）	1. 打开登录页 2. 输入 admin 3. 输入 123456 4. 点击登录	跳转首页，显示用户名	跳转首页，显示用户名	通过
LOGIN_002	登录失败-错误密码	用户已注册（admin/123456）	1. 打开登录页 2. 输入 admin 3. 输入 000000 4. 点击登录	提示「密码错误」	提示「密码错误」	通过

1.4 知识体系结构图

下面这张图，是我梳理的本章知识结构。你看一眼，就能明白测试用例设计的全貌。

1.5 小结

好了，这一章的内容就这些。总结一下：

• 测试用例就是一份操作说明书，告诉你「怎么测」和「期望什么」
• 它很重要，能帮你避免漏测、方便回归、传承知识
• 7 个核心要素缺一不可：ID、标题、前置条件、测试步骤、预期结果、实际结果、状态

我个人觉得，测试用例设计最难的其实不是写，而是「想清楚」。你想想看，如果你连预期结果都写不出来，那你怎么知道测完是对是错？

下一章，咱们聊聊测试用例的设计方法。嗯，到时候我会分享一些实战中的小技巧。