现在很多测试团队已经开始用 AI 辅助生成测试用例。
效率确实上来了：一份需求文档丢进去，几十条甚至上百条用例很快就能产出。但问题也随之出现：用例数量变多了，并不代表质量变好了。
我在实际测试工作中遇到过几类典型问题：
- 用例标题看起来完整，执行步骤却不够落地
- 预期结果写得很大，但没有明确校验点
- AI、文件上传、异常分支等高风险场景容易漏
- 多条用例覆盖相似内容，执行时成本很高
- 需求里需要澄清的点，被用例直接“默认通过”了
所以我换了一个思路：既然 AI 能辅助写用例，也可以让 AI 先对用例做一次结构化评审。
这篇文章分享一次真实工作流改造：用 AI 结合需求文档和 Excel 用例，对一批“产品发布页”测试用例做评审，找出缺失场景、质量问题和后续整改方向。
为避免涉及内部信息，文中的项目名称、文件路径和业务细节均已做脱敏处理。
一、为什么要先做用例评审？
传统用例评审通常依赖人工经验。
如果用例只有十几条，人工逐条看问题不大。但当 AI 一次生成几十条用例后，评审成本会明显上升。测试同学不仅要判断覆盖是否完整，还要检查每条用例是否能执行、是否有重复、是否缺少测试数据。
我更希望 AI 帮我先完成第一轮“粗筛”：
- 找出需求中未覆盖的关键路径
- 标记粒度过大的用例
- 识别步骤和预期不一致的用例
- 找出重复、冗余或可以合并的用例
- 汇总需要产品或研发澄清的问题
这样人工评审时，就不需要从 0 开始逐条扫，而是可以直接聚焦在风险点和争议点上。
二、评审输入材料
本次评审使用了两类输入：
| 输入材料 | 说明 |
|---|