测试用例编写规范：从命名到定义的完整指南
写测试用例这事儿，我做了十几年了。说实话，见过太多团队因为用例规范没做好，后期维护成本高得吓人。今天我就把压箱底的经验拿出来，跟你聊聊用例编号、标题、前置条件这些看似基础，实则门道很深的内容。
核心观点：测试用例规范不是束缚，而是团队协作的润滑剂。好的规范能让新人快速上手，让老人减少沟通成本。
一、用例编号规则：给每个用例一个身份证
用例编号，说白了就是每个测试用例的唯一标识。我在项目中遇到过最头疼的事，就是两个用例编号重复，结果bug报告里引用的用例根本对不上号。
我个人习惯的编号格式是这样的：
模块前缀-功能缩写-序号-版本号举个例子：
| 模块 | 功能 | 编号示例 |
|---|---|---|
| 登录模块 | 密码登录 | LOGIN-PWD-001-V1.0 |
| 支付模块 | 微信支付 | PAY-WECHAT-023-V2.1 |
| 搜索模块 | 模糊搜索 | SEARCH-FUZZY-015-V1.2 |
小技巧：模块前缀建议用3-5个大写字母，一眼就能看出是哪个模块。我习惯把前缀表贴在团队共享文档里，新人来了先背这个。
编号里为什么要加版本号？嗯，这里要注意。版本迭代时，同一个功能可能被改得面目全非。有了版本号，你就能快速判断这个用例是否还适用。我曾经就因为没加版本号，拿着旧用例测新功能，白白浪费了半天时间。
二、用例标题规范：让人一眼看懂测什么
标题怎么写？我有个简单的原则：谁 + 在什么条件下 + 做什么 + 期望什么。
你想想看，如果标题写成「测试登录功能」，那等于没写。改成这样：
- 「用户输入正确用户名和密码，点击登录，成功跳转首页」
- 「用户输入错误密码3次，账号被锁定，提示剩余解锁时间」
- 「未注册用户点击登录，提示账号不存在」
是不是清晰多了？
避坑指南：我曾经见过一个团队，标题里写「测试各种情况」，结果用例库里2000多条用例，一半都是这种标题。后来重构时，光改标题就花了一周。记住：标题要具体，具体到不能再具体。
三、前置条件：别让测试跑偏了
前置条件，就是测试开始前必须准备好的状态。说白了，就是「你要测这个功能，得先把环境搭好」。
我一般把前置条件分成三类：
- 数据准备：比如需要有一个已注册用户、需要有一条待支付的订单
- 环境配置：比如需要开启GPS权限、需要连接WiFi
- 状态要求：比如用户已登录、页面已加载完成
举个例子，测试「用户取消订单」这个用例：
前置条件：
1. 用户已登录（账号：test001，密码：123456）
2. 存在一条状态为「待支付」的订单（订单号：ORD20240101）
3. 订单创建时间在24小时内为什么要写这么细？因为如果前置条件不明确，测试人员可能用「已发货」的订单来测取消功能，那结果肯定不对。我遇到过这种乌龙，后来就养成了写详细前置条件的习惯。
四、测试步骤：每一步都要可执行
测试步骤怎么写？记住一句话：让一个完全不懂业务的人，照着步骤也能操作。
好的测试步骤长这样：
- 打开浏览器，访问 https://www.example.com/login
- 在用户名输入框输入「admin」
- 在密码输入框输入「123456」
- 点击「登录」按钮
- 观察页面跳转情况
不好的测试步骤：
- 登录系统（太模糊，怎么登录？）
- 输入信息（什么信息？）
- 检查结果（检查什么？）
我的经验：每个步骤只做一件事。比如「输入用户名和密码」要拆成两步。为什么？因为如果出错了，你能精确知道是哪一步出了问题。
五、预期结果：别让测试人员猜
预期结果，就是「你希望系统怎么反应」。这个写不好，测试就变成了猜谜游戏。
我见过最差的预期结果：「系统正常运行」。什么叫正常运行？页面不报错就叫正常运行？
好的预期结果要具体到：
- 页面跳转到哪个URL
- 弹窗显示什么文字
- 数据库里哪个字段变成了什么值
- 接口返回什么状态码
举个例子：
预期结果：
1. 页面跳转到首页（URL：https://www.example.com/home）
2. 页面右上角显示用户昵称「admin」
3. 接口 /api/user/info 返回状态码 200
4. 数据库 user 表中该用户的 last_login_time 更新为当前时间你想想看，这样写出来，测试人员还需要问「这样算不算通过」吗？不需要，直接对照检查就行。
六、优先级与严重级别定义：分清轻重缓急
优先级和严重级别，这两个概念经常被混淆。我简单解释一下：
- 优先级：这个用例什么时候测？先测还是后测？
- 严重级别：这个bug有多严重？会不会导致系统崩溃？
我习惯用四级定义：
| 级别 | 优先级 | 严重级别 |
|---|---|---|
| P0/S0 | 立即测试，阻塞其他测试 | 系统崩溃，数据丢失，核心功能不可用 |
| P1/S1 | 本轮迭代必须测完 | 主要功能异常，但可绕过 |
| P2/S2 | 有时间就测，没时间可延后 | 次要功能异常，不影响核心流程 |
| P3/S3 | 低优先级，可放到下个版本 | 界面问题，文案错误，体验不佳 |
个人经验：我一般把P0用例控制在总用例的5%以内。为什么？因为P0用例意味着「不测完不能发版」，如果太多，每次发版都卡在测试上。我曾经见过一个项目，P0用例占了30%，结果每次发版都要加班到凌晨。
七、知识体系总览
下面这张图，是我对测试用例编写规范的整体理解。你可以把它当作一个检查清单：
这张图把六个核心要素串起来了。你写用例时，可以对照着检查：编号有没有？标题清不清楚？前置条件写全了吗？步骤能不能执行？预期结果够不够具体？优先级定得合理吗？
最后说一句：规范是死的，人是活的。我见过很多团队把规范定得死死的，结果没人愿意遵守。我的建议是：先定一个简单版本，跑起来，然后根据实际问题不断优化。好的规范，是长出来的，不是写出来的。