让 AI 生成测试用例，最常见的场景是这样：你把一份需求丢进去，几秒钟后它吐回来 100 条用例，整整齐齐，每条都带编号、前置条件、步骤、预期结果。

有人看到这个数字会很高兴：”效率真高，100 条。”

但做过用例评审的人会立刻问一个更关键的问题：这 100 条里，有多少是真正有效的？

这里的”有效”不是”格式完整”，而是：它能对应上一条真实需求、能被执行、预期结果能被判断、不和其他条重复、也不是 AI 编出来的规则。

这篇文章我想讲清楚：怎么从一堆 AI 生成的用例里，把”有效”的那部分筛出来。判断标准不玄学，是一张可以逐条套用的检查表。

一、先问一个反直觉的问题：用例多，就代表覆盖好吗？

100 条用例，和”覆盖好”之间没有必然关系。

我见过一个很典型的反例：AI 把同一个登录场景拆成了”输入正确密码””输入错误密码””不输密码””输入特殊字符密码”……看起来分了很多条，但它们本质上都是”登录密码校验”这一个测试点的不同取值。数量上去了，测试点的覆盖并没有真正变宽。

反过来，10 条用例如果每条都对应一个不同的业务规则，那它的有效覆盖可能比 100 条”注水”的用例还高。

所以第一步，先别被总数唬住。判断有效性，要逐条看它到底验了什么，而不是数它有多少条。

二、单条用例：先过这七道检查

对每一条用例，我会问七个问题。任何一个答不上来，这条就值得打问号。

1. 能不能追溯到需求？

这条用例验的规则，在需求里找得到吗？

AI 最大的风险之一，是顺着自己脑补的”常识”往下写，写出需求里根本没有的东西。比如需求只说了”支持账号密码登录”，AI 却凭空加了一条”连续失败三次锁定账号”——这条用例对应的规则在需求里不存在。

有效的用例，必须能指回一条真实的需求条目。 指不回去的，要么是 AI 编的，要么是需求本身没写清，都需要单独处理，不能直接当成有效用例收下。

2. 前置条件成立吗？

用例能不能跑，第一步取决于前置条件是不是真实、可满足的。

常见问题：前置条件写得太笼统（”用户已登录”——登录到什么状态？什么角色？），或者前置条件之间互相矛盾（”未登录用户”+”已绑定手机号”），或者依赖一个根本不存在的状态。

前置条件必须具体到能据此准备测试数据的程度。否则这条用例只是”看起来能跑”，真执行起来第一步就卡住。

3. 步骤可执行吗？

步骤要具体到”照着做不会产生歧义”。

如果一条用例的步骤是”进入页面进行操作，检查结果”这种大而化之的描述，它就不是一条可执行用例，只是一句正确的废话。有效的步骤，应该能让人（或脚本）明确知道：点哪里、输入什么、走哪条路径。

4. 预期结果能被判断吗？

预期结果要落在可观察、可判断的对象上。

“操作成功”不是有效预期；”提交后列表出现新记录，且状态显示为已提交”才是。预期结果越具体，这条用例越能真正拦住缺陷；预期越笼统，它就越可能”永远通过”。

5. 是不是在重复？

100 条里，往往藏着一大批”换个说法再来一遍”的重复项。

判断重复不能只看标题，要看它验的测试点是不是同一个。两条用例，一条叫”登录成功进入首页”，一条叫”正确账号密码能进入系统”，标题不同，验的是同一件事，这就是重复。重复项不仅没有新增覆盖，还会在回归时白白浪费执行时间。

6. 有没有虚构规则？

这一条和”可追溯性”相关，但更隐蔽：AI 可能把某个技术细节或行业惯例当成产品规则写进用例。

比如它默认”密码至少 8 位””手机号必须是 11 位”，但这些规则需求里并没有，是 AI 从训练数据里”猜”出来的。这类虚构规则一旦被当成真需求去验收，轻则白测，重则把开发带偏。

7. 边界覆盖了吗？

有效的用例，不能只测”正常路径”。

一个测试点，如果只写了正常情况，没有写边界（最大值、最小值、空值、异常值）和异常路径（失败、超时、中断），那它对这条规则的覆盖是残缺的。AI 生成的用例特别容易”重正常、轻异常”，因为正常路径最好写。

三、整体结构：单条没问题，也可能整体失效

单条用例都过关了，还要再看一层——这 100 条作为一个整体，结构合不合理。

结构膨胀

AI 喜欢把需求拆成一堆并列的一级模块。我做过的一个真实案例里，AI 把一个功能拆出了 22 个一级模块——数量没错，但根本没法评审，因为真实的业务主线被淹没在一堆并列项里了。

模块要沿主流程合并子流程，横向的检查维度不该和主流程并列堆在一起。 一级模块过多，本身就是结构失效的信号。

用例平铺

另一个常见问题是”平铺”：大量可执行的判断点直接摊在业务目录下，还原不出用户的操作路径。

好的用例结构是有层级的——先有共同入口，再有前置状态，然后是连续操作、页面流转，最后落到可观察的结果。如果一堆 case 直接平铺、彼此没有父子关系，说明 AI 没有真正理解业务路径，只是把判断点罗列了一遍。

把过程当结果

还有一种隐蔽的错误：把”中间动作”标成”用例结果”。

比如一条用例的”结果”写的是”点击开始校验”，或者笼统的”通过校验”——这两个都不是可判断的结果。真正的结果应该是”校验完成后，页面显示通过/失败的具体状态”。把中间动作当结果，用例等于没写完。

包装层

“核心流程用例”这种标题，看着像一个分类，其实没有任何业务含义——它既不是页面，也不是入口，也不是流程或规则。这种包装层会让用例树看起来很规整，实际上什么都没分类。

四、一个可以落地的筛法

综合上面两层，我一般会用一个”两轮筛”的流程来处理 AI 生成的批量用例：

第一轮，筛单条质量。 用第二节的七道检查，把每条用例标记成三类：

  • 有效：七道都过关，可以直接进入评审或执行；
  • 待修改：格式在，但某一项不具体（比如预期结果太笼统），补一补能用；
  • 无效：不可追溯、虚构规则、无法执行、纯重复，直接剔除。

第二轮，筛结构质量。 看剩下的用例作为一个整体的组织：

  • 一级模块数量是否可评审；
  • 用例有没有形成清晰的父子路径，还是平铺了一堆判断点；
  • 有没有把中间动作当成结果、有没有无意义的包装层。

两轮筛完，你得到的就不再是一个虚高的”100 条”，而是一个知道里面有多少真能用、多少要改、多少该扔的结论。

五、为什么不能指望 AI 自己筛

有人会想：那再让 AI 自己评审一遍不就行了？

可以，但要清楚 AI 自评的局限。AI 既生成又评审，用的是同一套”常识”，它大概率会把自己脑补的虚构规则也判成”合理”，把自己写平铺的结构也判成”清晰”。用一个和生成时相同视角的检查，很难发现自己同一视角下的问题。

更可靠的做法，是把判断标准固定成明确的、确定性的检查项——就像上面这张检查表——让它独立于”生成者的主观感受”而存在。这样无论是人来筛，还是用脚本辅助筛，结论都是可复现的。

这也是为什么”有多少用例真正有效”这个问题，最终不该由 AI 自己来回答，而该由一套稳定的评判标准来回答。

结语

AI 生成 100 条用例，真正的价值不在于”100”这个数字，而在于你能不能从这 100 条里，稳定地识别出有效的那部分。

判断的方法并不复杂：单条看七项质量，整体看结构是否可评审、可执行、可判断。把这两个层面走一遍，”100 条”就不再是一个需要你去猜的数字，而是一份你知道分量的用例清单。

因为有效的测试用例，从来不靠数量取胜，而靠每一条都验在点子上、且整体能被看明白。