我劝你别急着让 AI 写测试用例
“它写了 100 条测试用例，却没一条敢拿去生产环境跑。”
我向来是不惮以最坏的恶意来推测”AI 自动生成测试”的，然而看官们大抵都只盯着”AI 写代码”这一点。
满本都写着两个字——侥幸。
测试，大抵是软件工程里最不值钱的一环。写代码的看不起写测试的，做架构的看不起写代码的。现在 AI 来了，写测试的连饭碗都快保不住了。
我横竖睡不着，把这半年的 AI 测试账本翻了一翻，才从字缝里看出字来。
AI 确实能生成测试，但更多的是，它把水搅得更浑了。
一、覆盖率 90%，上线却炸了？
上周，新来的实习生给我看他的 PR。
“勋哥，我用 AI 写了 50 个测试用例，覆盖率飙到了 95%！”
我颇有些欣慰，心想孺子可教。于是点开了测试报告。
只一眼，我便沉默了。
那 50 个用例，清一色在测”正常路径”。输入 A，输出 B，断言通过。
但最关键的三个边界条件，一个都没测：
- 如果金额是负数怎么办？
- 如果并发请求来了怎么办？
- 如果第三方接口超时怎么办？
AI 不懂业务，它只懂语法。你喂给它一段代码，它就能帮你把这段代码，严严实实地测上一百遍。
但它从不问”该不该测”，只问”怎么测”。
二、AI 是个听话的刽子手
你让 AI 测什么，它就测什么。
你喂给它一段错误的计算逻辑，AI 也会帮你把这段错误的逻辑，用 50 个不同的输入测上一百遍。然后告诉你：”恭喜你，所有测试通过！”
这哪里是测试？这分明是在给错误逻辑做合法性背书。
AI 生成的测试用例，往往存在两个致命缺陷：
1. 领域知识真空 通用大模型没有企业内部的业务规则库。比如”满 100 减 20 与 8 折券能否同用”、”非交易时段撤单自动失效”这类规则，AI 根本不知道要测。
2. 粒度失控 同一个功能点下，部分用例写了 10 余个冗余步骤，而关键场景仅用 1 步概括，预期结果模糊到”功能正常”四个字。
它测出了代码的形，测不出业务的魂。 就像八股文做得再好，也挡不住洋人的大炮。
三、怎么解？三道人工审查关
既然 AI 写的测试不能信，那就不用了吗？
那倒也不是。大抵是使用方法不对。
我总结了一个原则：
把 AI 当”初级测试工程师”，不要当”质量把关人”。
AI 能帮你干什么？
- 生成样板代码和重复性断言
- 补充边缘参数组合（如 null、空字符串）
- 快速生成 Mock 对象
但你想让它干什么？
- 定义核心业务场景的验收标准
- 判断测试用例的业务覆盖度
- 做最终的发布决策
这些它干不了，也不该让它干。
四、说句难听的
别被”AI 测试提效”的泡沫迷了眼。
AI 填平了”写断言”的坑，但把”设计测试场景”的坑挖得更深了。
以前测试人员的门槛，是”会不会写代码”。 现在测试人员的门槛，是”能不能判断 AI 测得对不对”。
AI 能替你写测试，但替不了你懂业务。 AI 能替你跑用例，但替不了你兜底。
如果你还在指望”AI 能包揽测试的一切”，那我建议你，还是洗洗睡吧。
万一，你成了那个因为测试没覆盖而背 P0 事故的人呢？
大抵如此罢。
关于码孖AI
码孖AI，专注 AI 工程化落地。
说白了就是帮程序员少干点活——但别指望 AI 替你思考，它只会替你打字。
关注我，持续更新实战踩坑指南。
:::callout tip 觉得有用？ 点个「在看」，分享给同样在 AI 落地路上挣扎的朋友。 :::