2. 测试用例编写规范：从编号到评审的完整指南
说实话，我刚入行那会儿写测试用例，就是想到哪写到哪。领导问「这个用例覆盖了哪些场景」，我支支吾吾答不上来。后来带团队了，发现新人犯的错跟我当年一模一样——用例写得像流水账，评审时被怼得哑口无言。
这一章，我就把测试用例编写的核心规范掰开揉碎了讲。你按这个套路写，至少能保证用例可读、可执行、可追溯。
2.1 用例编号：你的用例身份证
用例编号不是随便编个号就完事了。它要能一眼看出：哪个模块、什么类型、第几条。
我个人习惯用这套规则：
| 字段 | 格式 | 示例 |
|---|---|---|
| 项目前缀 | 2-4位大写字母 | OPS（运营平台） |
| 模块代码 | 2位字母 | LG（登录模块） |
| 用例类型 | 1位字母 | F（功能）、P（性能）、S（安全） |
| 序号 | 4位数字 | 0001 |
最终编号长这样：OPS-LG-F-0001。你一看就知道：这是运营平台登录模块的第1条功能用例。
2.2 测试标题：一句话说清楚测什么
标题是给评审人和执行人看的。写得好，别人不用点开详情就知道你在测啥。
我总结了一个公式：
「在[条件]下，执行[操作]，验证[结果]」
举个例子：
- ❌ 差标题：登录测试
- ✅ 好标题：输入正确用户名和密码，点击登录，验证成功跳转首页
你看，好标题把前置条件、操作步骤、预期结果全浓缩进去了。执行人照着标题就能跑，不用反复翻详情。
2.3 前置条件：别让执行人猜
前置条件就是「在开始测试之前，系统必须处于什么状态」。写不清楚，执行人要么跑不通，要么跑出假结果。
我曾经遇到过一个坑：用例写着「用户已登录」，但没说是哪种登录方式。结果执行人用手机号登录，用例里测的却是扫码登录的功能，白白浪费半天排查时间。
前置条件应该包含：
- 数据准备： 需要哪些测试数据（如：存在一个已激活的VIP用户）
- 环境状态： 系统处于什么模式（如：处于离线状态）
- 依赖操作： 必须先完成什么步骤（如：已执行过注册流程）
正确示例：
- 前置条件：
- 1. 数据库中存在一个已激活的VIP用户（账号：vip_test，密码：123456）
- 2. 用户当前处于未登录状态
- 3. 网络连接正常
2.4 测试步骤：清晰到新人也能执行
测试步骤要细到什么程度？细到一个刚入职一周的新人，照着步骤做，不会来问你「下一步点哪里」。
我常用的步骤写法：
步骤1：打开浏览器，访问 https://test.ops.com/login
步骤2：在用户名输入框输入「vip_test」
步骤3：在密码输入框输入「123456」
步骤4：点击「登录」按钮
步骤5：等待页面跳转，观察页面顶部是否显示「欢迎回来，VIP用户」注意几点：
- 每个步骤只做一个操作，别合并
- 操作对象要具体（哪个按钮、哪个输入框）
- 输入数据要明确（别写「输入有效数据」，要写具体值）
2.5 预期结果：可观察、可度量
预期结果是最容易被糊弄的部分。很多人写「系统正常运行」「页面显示正确」，这种话等于没写。
好的预期结果要满足三个条件：
- 可观察： 肉眼能看到什么变化（弹窗、跳转、文字变化）
- 可度量： 能用数据验证（响应时间 < 2秒、返回码 200）
- 无歧义： 不同的人验证，结论一致
对比一下：
| 类型 | 写法 | 问题 |
|---|---|---|
| ❌ 模糊 | 登录成功 | 什么叫成功？跳转了算不算？ |
| ✅ 清晰 | 页面跳转至首页，顶部显示用户名「vip_test」，URL变为 /home | 三个可验证点，一目了然 |
2.6 优先级：决定先测什么
优先级不是拍脑袋定的。我一般按功能重要程度和故障影响范围两个维度来定：
| 优先级 | 定义 | 示例 |
|---|---|---|
| P0 | 核心功能，出问题直接阻塞发布 | 用户登录、支付流程 |
| P1 | 重要功能，出问题严重影响体验 | 搜索功能、订单查询 |
| P2 | 一般功能，出问题可接受但有损体验 | 个人资料编辑、消息通知 |
| P3 | 边缘功能，出问题影响极小 | 页面样式微调、文案优化 |
P0用例必须全部通过才能发版。P3用例可以延期到下个版本。这个规则要在团队里达成共识，不然每次发版前都在吵「这个bug修不修」。
2.7 用例评审流程与标准
用例写完了，别急着提交。评审这关过不了，后面执行全是坑。
我带的团队，评审流程是这样的：
- 自审： 作者自己过一遍，检查格式和逻辑
- 互审： 同组同事交叉检查，找遗漏场景
- 专家评审： 测试架构师或技术负责人把关
- 业务确认： 产品经理确认业务逻辑正确
评审标准我列了个清单，每次评审照着打勾：
- ☐ 用例编号格式正确，无重复
- ☐ 标题符合「条件+操作+结果」公式
- ☐ 前置条件完整，数据准备明确
- ☐ 测试步骤可执行，无歧义
- ☐ 预期结果可观察、可度量
- ☐ 优先级合理，与业务影响匹配
- ☐ 覆盖了正常流程、异常流程、边界值
2.8 知识结构总览
下面这张图，把测试用例编写的核心要素串起来了。你可以把它贴在工位上，写用例时对照着看。
2.9 写在最后
测试用例规范不是束缚你的条条框框，而是帮你减少返工、提升效率的工具。我见过太多团队，前期用例写得随意，后期执行时反复修改，评审时吵得不可开交。与其这样，不如一开始就按规范来。
嗯，这一章的内容就这些。你写用例的时候，把这张知识结构图摆在旁边，每写完一条就对照检查一遍。坚持一个月，你会发现自己的用例质量提升一大截。