AI 工程化踩坑实录（4/5）：别急着让 AI 写测试用例
“AI 写了 300 个测试用例，覆盖率从 40% 飙到 85%。然后线上还是崩了。”
上个月，一个做金融 SaaS 的朋友老周跟我吐槽。
他们团队引入 AI 写测试用例，效果立竿见影。原来手工写 100 个用例要两天，AI 半小时出了 300 个。覆盖率从 40% 直接干到 85%。
CTO 在周会上表扬了团队。大家也很高兴。
然后上线那天，支付接口超时了。
为什么？因为 AI 生成的 300 个测试用例里，没有一个测的是”支付超时后重试”这个场景。
AI 测了什么？测了”正常支付流程”的 80 种变体。输入不同金额、不同币种、不同用户类型……全测了。
但它没测”如果第三方支付网关无响应怎么办”。
因为 AI 不知道你们公司的支付网关是走银联通道，银联通道 historically 有 3% 的超时率。这个知识不在它的训练数据里。
覆盖率 85%。但那 15% 全是关键场景。
2026 年，腾讯云发了一篇《AI 测试工具的 5 大认知误区》，我看完颇有些共鸣。五个误区，每个都戳在痛点上。
误区一：AI 理解业务逻辑。
它不理解。
AI 能分析代码结构，识别函数签名，推断输入输出类型。但它不知道”这个字段在你们公司代表 VIP 等级，等级 3 以上才能走人工审核流程”。
它生成的测试用例，是基于代码的”形”，不是业务的”神”。
误区二：高覆盖率 = 高质量。
这就是老周踩的坑。
85% 的覆盖率听起来很美。但如果这 85% 全是 happy path，剩下 15% 才是真正容易出问题的边界条件——那这个覆盖率数字就是自欺欺人。
AI 倾向于测”容易测”的东西。 正常输入、标准流程、预期输出。这些用例好写、好跑、好过。
但真正需要测试的是那些”不容易测”的场景：并发、超时、数据不一致、权限绕过。这些恰恰是 AI 最不擅长的。
误区三：AI 可以替代探索性测试。
探索性测试是什么？是一个有经验的测试工程师，不按用例走，而是凭直觉和经验去”找茬”。
“这里如果快速连续点两次会怎样？”
“如果用户在弱网环境下提交表单会怎样？”
“如果把 URL 里的参数从 id=1 改成 id=admin 会怎样？”
AI 做不了这些事。因为探索性测试的核心是”创造力”和”恶意”——你得站在攻击者的角度想问题。 AI 的训练目标是”生成合理的测试”，不是”找到最刁钻的破坏方式”。
说白了，AI 太”乖”了。它不会去干坏事。但测试这件事，本来就是要干坏事的。
误区四：维护成本消失了。
沙丘智库 2025 年的报告说，AI 生成测试用例能降低 60% 的脚本维护成本。
听起来很美。但现实是——维护成本没有消失，它转移了。
以前你维护的是手写用例的逻辑。现在你维护的是”AI 生成的用例到底覆盖了什么”。当业务变了，你面对的不再是”改 10 行代码”，而是”重新让 AI 生成一遍，然后逐条检查新生成的用例有没有偏离”。
这个”逐条检查”的成本，报告里没算。
误区五：AI 测试 = 合规。
金融行业的朋友注意了。
你用 AI 生成测试用例，审计来的时候问你：”这些用例的设计依据是什么？覆盖策略是什么？谁审核的？”
你说”AI 生成的”。
然后审计的脸色就变了。那表情我见过，翻译过来就是”你在逗我？”
AI 生成测试用例在合规场景下的可追溯性和可解释性，目前是一个灰色地带。 你最好先确认你们的合规部门接受不接受。
testerhome 上有一篇文章，收集了 10 家头部企业用 AI 写测试的实战数据。核心发现：
- AI 确实能提升覆盖率，平均提升 35%
- 手动工作量确实减少了，平均减少 40%
- 但所有企业都提到一个共同问题：AI 生成的用例需要大量人工校准
“大量”是多少？一家企业的 QA 负责人说：”AI 出了 500 个用例，我们逐条审完之后，删了 200 个，改了 150 个，真正能直接用的只有 150 个。”
有效率 30%。
你花 40% 的精力省了手动编写时间，然后花 60% 的精力校准 AI 的输出。总成本并没有降低多少。
不对，让我重新算。省了 40% 的手动编写时间，但校准时又花掉了 60%。如果原来手动写要 100 分钟，现在变成”40% × 100 + 60% × 100 = 100 分钟”。
没省。一秒钟都没省。
那为什么还有企业乐此不疲？
说了这么多问题，不是让你不用 AI 写测试。
是让你别把 AI 当主力，当辅助。
第一步：人先写核心用例。
把最关键的业务场景、边界条件、异常流程，自己写出来。这些是骨架，不能让 AI 碰。
比如支付系统：正常支付、支付超时、重复支付、退款、部分退款——这些核心用例必须人来。
第二步：让 AI 补充边缘用例。
骨架搭好之后，让 AI 帮你补：不同输入组合、不同数据类型、边界值。这些是体力活，AI 做得又快又全。
第三步：逐条校准。
AI 生成的每一条用例，都要过一遍：这个场景真的有意义吗？这个预期结果对吗？有没有遗漏的前置条件？
但不要信任 AI 的默认输出。 它不是你的 QA 工程师，它是你的测试实习生——干得快，但你需要盯紧。
——说到实习生，我想起去年我们组真来了一个实习生。干活也是又快又粗糙，和 AI 一模一样。所以说 AI 像实习生，不是比喻，是写实。
AI 写测试用例这件事，大抵就像一个不会做饭的人进了厨房。
他能切菜——切得还很快。但他不知道火候，不知道调味，不知道哪道菜该先下锅。
你把切菜的活交给他，自己去掌勺。这样效率确实高了。
但如果你把整道菜都交给他——那这顿饭，大抵是没法吃了。
这便是 AI 写测试的真相了。
——虽然话说回来，如果你只是让 AI 帮你生成一些边界值测试，那确实又快又好。我上周就让 AI 帮我测了一个日期解析函数，它找出了三个我没想到的边界情况。这种活交给 AI，确实省心。
但核心的业务场景测试，还是得人来。
关于码孖AI
码孖AI，专注 AI 工程化落地。我们相信：AI 不是来替代程序员的，是来帮程序员省时间的——前提是，你得会用。
关注我，持续更新实战踩坑指南。
:::callout tip 觉得有用？ 点个「在看」，分享给同样在 AI 落地路上挣扎的朋友。 :::