测试用例评审 10 个必查点从执行者到评审者作者楠风测开 | 5 年测试工程师 | 上海 本文 3000 字 | 阅读 8 分钟 | 建议收藏 ⭐先说为什么Day 1 我讲了测试工程师的 4 个阶段Day 2 讲了用例设计。今天讲一个很多测试工程师都忽略的事用例评审。我刚做测试的时候写完用例就完事了。结果漏测场景没被发现开发说这用例没法跑上线后 bug 频发后来我才明白用例评审才是用例价值最大化的关键。今天这篇文章把 10 个必查点完整讲透。看完你就能从写用例的人升级为评审用例的人。一、为什么用例评审这么重要真实数据我对比过两组团队的用例质量A 组无评审用例覆盖率 65%执行后漏测 30% B 组严格评审用例覆盖率 92%执行后漏测 8%差距巨大。原因 11 个人想不到的方法1 个人的思路有限多人评审能发现个人盲区。举例你写登录功能用例时可能想不到密码连续错 3 次锁定账号这种场景。但评审时别人会问安全策略呢原因 2发现假用例很多新人写的用例预期结果是功能正常。这不是用例这是无效用例。评审能让假用例暴露出来。原因 3提升团队能力评审是技术分享的过程。参与评审的人都能学到东西。二、10 个必查点详细检查点 1用例是否覆盖所有需求点判断方法把需求文档的每个功能点列出来逐一对照用例。举例用户登录功能 需求点 1. 输入用户名密码 2. 校验用户名密码 3. 登录成功跳转 4. 登录失败提示 5. 记住密码功能 用例覆盖 ✅ TC001 输入正确用户名密码覆盖 1-2-3 ✅ TC002 用户名错误覆盖 4 ✅ TC004 记住密码覆盖 5 ❌ TC003 密码错误 → 没有覆盖密码错误的具体场景评审问题- 这条用例对应了哪个需求点 - 是否每个需求点都有至少 1 条用例检查点 2等价类划分是否完整判断方法检查输入数据的等价类划分是否覆盖有效和无效两类。举例用户名字段 - ✅ 有效等价类6-20 位字母数字 - ❌ 缺少无效等价类长度不够、特殊字符 评审问题 - 有效等价类是否都覆盖了 - 无效等价类是否都考虑了检查点 3边界值是否到位判断方法检查所有数值边界是否都测了。举例年龄字段 1-150 边界点0、1、150、151 是否都测了 常见遗漏 - 整数 vs 小数 - 0 和 负数 - 最大值 1 评审问题 - 上点、下点、离点都测了吗 - 边界点是否完整检查点 4异常场景是否考虑判断方法列出所有可能的异常情况看用例是否测了。异常场景清单 - 网络中断 - 服务器超时 - 数据库异常 - 并发操作 - 重复提交 - 特殊字符注入 - 数据为空 - 权限不足 评审问题 - 异常场景覆盖了多少 - 哪些异常场景还没测检查点 5前置条件是否清晰判断方法每条用例的前置条件是否明确。反例 测试登录功能没有前置条件 - 在什么环境下测 - 数据是否准备好 - 用户是否已存在 正例 测试登录成功 - 环境测试环境 - 数据用户 test/password123 已存在 - 操作输入正确用户名密码 - 预期登录成功跳转首页评审问题- 前置条件是否完整 - 数据准备是否到位检查点 6预期结果是否可验证判断方法预期结果是否可以客观判断对错。反例 - 系统正常工作 → 什么是正常 - 界面显示正确 → 什么是正确 正例 - 页面跳转到 /home显示用户名 - 提示密码错误请重新输入 - 页面显示订单提交成功订单号 12345评审问题- 预期结果是否具体可验证 - 是否避免了正确正常等模糊词检查点 7用例之间是否独立判断方法一条用例的执行不依赖另一条用例的结果。反例 TC001 注册账号 TC002 登录账号依赖 TC001 创建的用户 正例 TC001 注册账号 TC002 登录账号前置条件用户已存在评审问题- 用例之间是否独立 - 是否明确了前置条件检查点 8用例命名是否规范判断方法用例命名是否清晰、统一。反例 - 测试1 - 登录测试 - 登录功能测试 正例 - TC_LOGIN_001_正常登录 - TC_LOGIN_002_密码错误 - TC_LOGIN_003_连续输错3次锁定命名规则TC_模块_编号_场景 示例TC_LOGIN_001_正常登录检查点 9用例优先级是否合理判断方法用例优先级是否符合业务重要性。P0核心场景必须测 - 正常登录 - 正常下单 P1重要场景应该测 - 密码错误 - 库存不足 P2一般场景可以测 - 登录页面 UI - 表单校验提示 P3边缘场景有时间再测 - 极端边界值 - 罕见异常评审问题- 优先级划分是否合理 - P0 用例是否覆盖了核心场景检查点 10用例是否可重复执行判断方法同样的步骤多次执行结果一致。反例 TC1 注册一个账号 - 每次执行一个账号是哪个 - 怎么保证幂等 正例 TC1 注册账号用户名test_001 - 明确指定用户名 - 第一次执行成功 - 第二次执行提示用户名已存在评审问题- 用例是否可重复执行 - 是否有幂等性考虑三、实战评审流程Step 1评审前准备- 提前 1 天发出用例文档 - 通知相关人员开发、产品、测试 lead - 准备评审会议室 / 线上会议 - 评审材料 ✅ 测试用例文档 ✅ 需求文档 ✅ 评审 checklistStep 2评审中控制在 1 小时0-5 分钟介绍用例概况 5-40 分钟逐条评审用例 40-55 分钟讨论争议点 55-60 分钟总结待修改项 每个用例评审 3 个问题 1. 这条用例覆盖了哪个需求点 2. 这条用例的预期结果是否可判断 3. 这条用例有没有遗漏的场景Step 3评审后- 输出评审纪要 - 列出待修改项owner deadline - 跟踪修改结果 - 修改后再次 review 关键变更四、常用评审 Checklist 模板□ 用例是否覆盖所有需求点 □ 等价类是否完整 □ 边界值是否到位 □ 异常场景是否考虑 □ 前置条件是否清晰 □ 预期结果是否可验证 □ 用例之间是否独立 □ 命名是否规范 □ 优先级是否合理 □ 是否可重复执行用法评审时每条用例过一遍这 10 个问题。五、楠风的经验我做测试 5 年前 3 年是被评审后 2 年是主持评审。被评审时- 不懂装懂开发问什么答不上来 - 用例写得很糙被批得体无完肤 - 慢慢学会每条用例都要经得起问主持评审时- 提前发材料让大家有时间看 - 控制时间1 小时结束 - 记录争议点会后跟进 - 关键变更再次 review真实数据评审前用例覆盖率 60% 评审后用例覆盖率 92% 评审前执行时漏测 25% 评审后执行时漏测 8% 评审前上线 bug 数月均 30 评审后上线 bug 数月均 10核心心得 用例评审不是挑刺是共同打磨。很多新人怕评审怕被批评。但你要反过来想评审是让别人帮你提高的机会。七、3 个月行动清单如果你也想提升用例评审能力今天□ 找 1 个你之前写的用例用 10 个检查点过一遍 □ 找出至少 3 个你没考虑到的场景本周□ 参与 1 次团队的用例评审 □ 主动提问 3 个问题 □ 学习别人是怎么写用例的90 天□ 能独立评审别人的用例 □ 成为团队用例评审的核心成员 □ 写一份团队通用的用例评审指南 □ 推动建立团队用例评审规范八、写在最后用例评审不是浪费时间。从写用例的人到评审用例的人是测试工程师的关键跃迁。希望这篇文章能帮你成为团队用例评审的核心成员。评论区聊聊你参与过用例评审吗有没有什么难忘的经历我会尽量回复。关于作者楠风测开 | 5 年测试工程师 | 测试开发 做测试平台、写技术博客、分享成长路径 如果你想看更多我的内容可以搜索楠风测开 或者关注我的同名账号如果这篇文章对你有帮助点赞 收藏建议收藏评论区告诉我你的评审经历转发给同样想提升的同行全文 3000 字 | 阅读 8 分钟 | 建议收藏【原创声明】本文为楠风测开原创转载请联系作者授权。