别急着执行 AI 写的用例，先让它做一次用例评审

现在很多测试团队已经开始用 AI 辅助生成测试用例。

效率确实上来了：一份需求文档丢进去，几十条甚至上百条用例很快就能产出。但问题也随之出现：用例数量变多了，并不代表质量变好了。

我在实际测试工作中遇到过几类典型问题：

• 用例标题看起来完整，执行步骤却不够落地
• 预期结果写得很大，但没有明确校验点
• AI、文件上传、异常分支等高风险场景容易漏
• 多条用例覆盖相似内容，执行时成本很高
• 需求里需要澄清的点，被用例直接“默认通过”了

所以我换了一个思路：既然 AI 能辅助写用例，也可以让 AI 先对用例做一次结构化评审。

这篇文章分享一次真实工作流改造：用 AI 结合需求文档和 Excel 用例，对一批“产品发布页”测试用例做评审，找出缺失场景、质量问题和后续整改方向。

为避免涉及内部信息，文中的项目名称、文件路径和业务细节均已做脱敏处理。

一、为什么要先做用例评审？

传统用例评审通常依赖人工经验。

如果用例只有十几条，人工逐条看问题不大。但当 AI 一次生成几十条用例后，评审成本会明显上升。测试同学不仅要判断覆盖是否完整，还要检查每条用例是否能执行、是否有重复、是否缺少测试数据。

我更希望 AI 帮我先完成第一轮“粗筛”：

• 找出需求中未覆盖的关键路径
• 标记粒度过大的用例
• 识别步骤和预期不一致的用例
• 找出重复、冗余或可以合并的用例
• 汇总需要产品或研发澄清的问题

这样人工评审时，就不需要从 0 开始逐条扫，而是可以直接聚焦在风险点和争议点上。

二、评审输入材料

本次评审使用了两类输入：