第一章：测试用例基础
大家好，我是这门课的主讲人。做了十几年测试，我带过不少团队，也看过太多人把测试用例当成「填空题」来写。今天咱们就从最基础的东西聊起——到底什么是测试用例？
什么是测试用例？
说白了，测试用例就是一份「操作说明书」。它告诉测试人员：你要测什么、怎么测、测完应该看到什么结果。
我见过很多新人，上来就点界面、瞎操作。问他测了什么，他说「都点了」。问他结果呢？他说「没报错」。这种测试，说白了就是浪费时间。
真正的测试用例，应该像菜谱一样清晰。你看菜谱做菜，每一步都明确，最后能不能做出那道菜，心里有数。测试用例也是这个道理。
核心定义：测试用例是为特定目标而设计的一组输入、执行条件和预期结果的集合。它是测试执行的最小单元。
测试用例的核心要素
一个完整的测试用例，必须包含以下五个要素。我习惯叫它「五件套」——少了任何一件，这个用例都不合格。
| 要素 | 说明 | 示例 |
|---|---|---|
| ID | 唯一标识，方便追溯和管理 | TC-LOGIN-001 |
| 标题 | 一句话说清测什么 | 验证正确用户名密码登录成功 |
| 前置条件 | 执行前必须满足的状态 | 用户已注册，账号状态正常 |
| 步骤 | 可操作的具体动作 | 1. 输入用户名 2. 输入密码 3. 点击登录 |
| 预期结果 | 执行后应该看到的现象 | 页面跳转到首页，显示用户昵称 |
ID：给用例一个身份证
ID 不是随便编个号就完事了。我建议用「模块-功能-序号」的格式。比如 TC-LOGIN-001，一看就知道是登录模块的用例。
为什么这么讲究？有一次我在项目中追一个 bug，开发说「你那个用例编号多少？」我一看，用例标题是「测试1」——当场就尴尬了。从那以后，我团队里谁写「测试1」这种标题，直接打回重写。
标题：一句话说清楚
标题要让人一眼看懂测什么。格式建议：「验证[条件]下[操作]的[结果]」。
举个例子：
- ❌ 坏标题：登录测试
- ✅ 好标题：验证密码错误3次后账号被锁定
你想想看，如果用例有几百条，光看标题就能定位问题，能省多少时间？
前置条件：别让测试跑偏
前置条件是最容易被忽略的。我见过太多人写用例，上来就是「输入用户名、输入密码、点击登录」——结果用户还没注册呢，测个啥？
前置条件要写清楚：
- 数据准备：比如「数据库中已存在用户 admin」
- 环境状态：比如「网络连接正常」
- 系统配置：比如「登录失败次数限制为3次」
小技巧：前置条件写完后，问自己一句「如果这个条件不满足，用例还能执行吗？」如果答案是「不能」，那这个条件就是必要的。
步骤：越细越好
步骤要写成人话，让一个刚入职的新人也能照着做。我习惯用「动词+对象」的格式：
- ❌ 模糊：登录系统
- ✅ 清晰：在用户名输入框输入「admin」，在密码输入框输入「123456」，点击「登录」按钮
嗯，这里要注意：步骤不要写「如果...那么...」这种条件判断。那是用例设计要考虑的，不是步骤里该写的。
预期结果：最见功力的地方
预期结果写得好不好，直接体现测试人员的水平。很多人写「系统正常响应」——什么叫正常？你倒是说清楚啊！
好的预期结果要具体、可验证：
- ✅ 页面跳转到首页，右上角显示「欢迎，admin」
- ✅ 数据库 user 表中该用户的 last_login_time 字段更新为当前时间
- ✅ 接口返回 HTTP 200，响应体中包含 字段
避坑指南：我曾经遇到一个项目，预期结果写的是「页面显示正常」。结果上线后用户反馈页面白屏——测试说「我测的时候是正常的啊」。你看，这就是预期结果不明确的后果。
为什么需要写用例？
这个问题我问过很多新人。有人说「领导让写的」，有人说「流程要求的」。其实写用例的真正价值，我总结为三点：
- 保证覆盖率——脑子记不住所有场景，写下来才不会漏
- 方便复用——这次测完，下次回归还能用
- 知识传承——你离职了，新人能接着你的用例干活
我见过最惨的一个项目，核心测试人员离职了，留下一堆「测试1」「测试2」这样的用例。新来的同事根本看不懂，只能从头测起。结果呢？漏了一个边界条件，线上出了事故。
所以，写用例不是给别人看的，是给自己留后路。
本章知识体系
下面这张图，把测试用例的核心逻辑串起来了。我建议你多看几遍，理解每个要素之间的关系。
写在最后
这一章的内容，说白了就是打地基。很多人觉得基础的东西不重要，总想学高大上的自动化、性能测试。但你看那些真正的测试大牛，写出来的用例就是比别人清晰、好维护。
我个人习惯，每写一个用例都问自己三个问题：
- 别人能看懂吗？
- 能复现我的操作吗？
- 结果能验证吗？
如果答案都是「是」，那这个用例就合格了。下一章，咱们聊聊怎么设计用例——不是随便写，而是有方法、有套路地写。