我现在已经不太排斥让 AI 先写一版测试用例了。

以前我会有点警惕。总觉得测试用例这种东西，里面有太多业务经验和历史坑，让 AI 写，会不会只是把需求文档换一种格式复述一遍。

后来试得多了，我的态度变了。

AI 可以写第一版。甚至很多时候，它写得比我预想的更完整。

但这不代表可以直接用。

我现在的习惯是：让 AI 先生成，再用自己的测试经验审一遍。第一眼不看它写了多少条，也不看表格漂不漂亮。我先看 5 件事。

1、先看它有没有读懂业务目标
AI 很容易把需求拆成动作。

比如需求写：“用户可在订单页领取优惠券，并在支付时自动抵扣。”

AI 通常会很快写出这些用例：进入订单页，点击领取优惠券；支付时使用优惠券；优惠券金额正确抵扣；领取成功后页面展示成功提示。

这些都没错。

但我会先看一个更前面的东西：它有没有理解这个功能到底在解决什么问题。

优惠券不是一个按钮。它背后有领取资格、有效期、使用门槛、叠加规则、库存、订单状态、退款处理。

如果 AI 只围绕 “点击领取” 和 “支付抵扣” 写用例，这一版看起来完整，其实很浅。它读懂了动作，没读懂业务。

所以第一眼，我会找它有没有覆盖业务目标和业务约束。

如果没有，我会补一句提示：

请不要只按页面操作生成用例。先列出这个功能涉及的业务规则，再按规则生成测试场景。

这句话很有用。AI 的输出通常会立刻从 “页面步骤” 往 “业务规则” 靠一点。

2、再看状态有没有被拆开
测试用例最容易被 AI 写虚的地方，是状态。

很多功能不是一个动作决定结果，而是由状态组合决定结果。

还是拿优惠券举例。用户状态可能有新用户、老用户、黑名单用户、未登录用户。优惠券状态可能有未领取、已领取、已使用、已过期、已领完。订单状态可能有待支付、已支付、已取消、退款中、已退款。

AI 如果没有把这些状态拆开，就很容易生成一批 “正常领取、正常使用、异常提示” 的泛用用例。

这类用例不是不能看，但价值有限。

我会重点检查它有没有把 “对象状态” 写清楚。比如：已领取但未使用的优惠券，再次领取怎么处理？优惠券在支付页过期，系统怎么提示？订单取消后，优惠券是否退回？用户退款后，优惠券是否恢复可用？

这些不是边角料。很多线上问题就出在状态切换上。

3、第三眼看边界值，不只看数字
AI 对边界值有一个常见毛病：它会想起数字边界，但想不起业务边界。

比如满 100 减 20，它通常会写：订单金额 99.99，不能使用；订单金额 100，可以使用；订单金额 100.01，可以使用。

这很好，但不够。

我还会看它有没有想到这些边界：商品金额满足门槛，但运费不参与优惠；多商品合并支付，其中一件商品不支持优惠券；优惠券还有 1 秒过期时进入支付页；用户跨时区或系统时间切换时，有效期怎么计算。

边界值不只是数字的前后一格。它也可能是时间、权限、状态、库存、金额组成方式。

AI 如果只写数字边界，我会继续追问：

请补充时间、权限、库存、金额组成、订单状态变化带来的边界场景。

4、第四眼看它有没有写出不可测的废话
AI 很喜欢写一种看起来很专业、其实没法执行的用例。

比如：验证系统稳定性良好；验证用户体验友好；验证优惠券功能符合预期。

这种句子放在测试计划里都嫌虚，放在测试用例里更麻烦。

我会把这类用例直接删掉，或者要求它重写成可执行版本。

一个可执行用例至少要说清楚：前置条件是什么，操作步骤是什么，预期结果看哪里，哪个字段、页面、接口或数据发生了变化。

如果一条用例读完以后，我不知道怎么测，也不知道测完看什么，它就不是一条好用例。

5、最后看它有没有把风险排出来
AI 生成 50 条用例不难。难的是告诉你哪 10 条最值得先测。

真实工作里，测试时间通常不够。需求变更、提测延迟、环境不稳，这些都很正常。这个时候用例不是越多越好，而是要能分出优先级。

我会看 AI 有没有标风险等级。比如支付金额错误、优惠券重复使用是高风险；页面文案不一致可能是低到中风险；成功提示样式偏差通常是低风险。

如果它没有排，我会让它补：

请按资金风险、用户影响范围、出现概率和回归成本，为这些测试用例标 P0/P1/P2。

当然，AI 标出来的优先级也不能照单全收。它不知道你们系统的真实事故史，也不知道哪个模块最近改动最大。

但它可以给你一个初始排序。测试人再根据项目经验调整。

6、我的用法：让 AI 写初稿，让人做审稿
所以，我现在不会再纠结 “测试用例能不能让 AI 写”。

可以写。

但我更愿意把它叫作 “用例初稿生成”，不是 “用例设计完成”。

这两个词差别很大。

AI 适合帮我铺开场景，补充一些我一时没想到的分支，把需求快速整理成结构化内容。

但它不适合直接替我判断风险。尤其是那些藏在历史缺陷、老系统逻辑、灰度策略和业务默认规则里的东西，还是要人来审。

如果你也想试，可以从一个很小的流程开始：先拿一段需求，让 AI 生成用例。然后按业务目标、状态拆分、边界场景、可执行性、风险优先级这 5 件事检查。

这比一上来追求 “让 AI 完整替我设计测试方案” 更稳。

工具可以快一点。

判断最好慢一点。