用例评审是什么
用例评审在用例设计完成后、执行开始前进行，检查覆盖完整性与可执行性：需求是否逐条对应、预期结果是否可判定、数据与环境是否可准备、是否与已有用例重复、优先级标注是否合理。目标是让用例在真正执行之前就暴露出歧义、遗漏与不可执行的描述，而不是等执行时才发现问题。
基本信息
| 时机 | 设计完成后、执行开始前；高风险模块可在设计中途先评一轮 |
|---|---|
| 参与人 | 测试主导，开发与产品按需参加，跨模块需求加相关方 |
| 输入 | 需求与验收标准、用例清单、历史缺陷列表 |
| 输出 | 评审意见、修订记录、遗留问题清单与处理人 |
| 检查重点 | 覆盖对齐、可判定性、数据可准备、无重复、优先级合理 |
典型使用场景
- 需求验收前：每条需求与用例做双向对照，找出覆盖缺口
- 新成员产出的用例：统一断言质量与可执行性标准
- 高风险模块：支付、权限、数据删除等提前邀请开发参与评审
- 缺陷复盘后：把出过问题的用例类型加入评审检查清单
- 用例库清理：批量识别重复、过期与失效的用例
- 外包与跨团队交付：作为质量门槛，评审结论正式留档
评审清单（节选）
评审清单（节选）
# 用例评审清单
# [ ] 每条需求至少对应一条用例，含异常路径
# [ ] 预期结果明确、可判定，而不是「功能正常」
# [ ] 前置条件与测试数据可准备、可复现
# [ ] 与既有用例无重复，或已合并
# [ ] 优先级标注与实际风险匹配
# [ ] 历史缺陷对应的用例已重点抽查评审关注点与常见问题
| 关注点 | 检查方式 | 常见问题 |
|---|---|---|
| 覆盖对齐 | 需求条目双向对照 | 新增需求上线却没补用例 |
| 断言质量 | 预期结果可判定 | 只写「显示正常」无法判定 |
| 数据准备 | 数据来源与生成方式明确 | 依赖手工造数，无法复现 |
| 重复检测 | 与用例库去重 | 多条用例测同一场景浪费工时 |
| 优先级 | 按风险与使用频率标注 | 全标高优先级导致资源摊薄 |
评审结论要留档：意见、处理结果、遗留项都记录在用例管理工具里，否则同一问题会在多轮评审中反复出现，也无法证明用例质量在改善。
评审效率技巧：全员先各自预读并标注疑问，会上只讨论有争议与高风险条目，低风险条目抽样确认，避免逐条朗读。