AI写测试的真相：能加速脚手架，但会漏掉真实Bug

上个月有位同事花了一下午，把我们的 checkout 流程交给 AI 编码助手，让它生成一套测试用例。二十分钟后，他拿到了四十个测试。纸面上覆盖率很好，语法干净，命名也像样。然后我们用上周刚修好的一个已知 bug 来跑它们，结果四十个测试全部通过了。AI 写的是匹配代码当前行为的测试，而不是代码应该做的测试。它根本不知道两者之间的区别。

这就是 AI 在测试自动化中当前真实的处境——远比大多数相关文章描述的要平淡得多。

真正有用的场景

脚手架，快速生成。 为新的测试文件写样板代码、设置 fixtures、为简单的 CRUD 接口连接断言——这正是 AI 擅长的重复性、低判断工作。真的能省时间，尤其在项目早期要写大量相似测试的时候。

发现你没想过的边界情况。 描述一个函数的输入，问它什么会让它挂掉，通常能得到一个不错的列表：空字符串、null 值、边界数字、unicode 异常。不一定全面，也不一定都和你的实际业务相关，但作为起始检查清单是合理的，比对着空白测试文件发呆要快得多。

解释现有测试失败的原因。 把 AI 助手指向一个堆栈跟踪和一个失败的断言，问"这里可能发生了什么"，这是被低估的用法之一。它快速匹配常见失败模式——差一错误、类型不匹配、明显的空指针问题——尽管它并不能总是诊断出更深层的原因。

重构测试代码本身。 清理重复的 setup 逻辑、把一堆复制粘贴的测试转换成参数化套件、更新旧的断言语法——这些机械性工作 AI 做得很好，因为这类工作关注的是代码的形状，而不是代码要证明什么。

它不知道你的系统什么叫"正确"

这就是上面 checkout 例子的核心。AI 可以写一个针对你当前代码通过了的测试，但它没有独立的方式判断你当前的代码是否正确。它不是对照你的业务逻辑来测试，而是对照已经存在的东西来测试——这意味着它非常擅长锁定 bug，而不仅仅是捕获它们。

它不知道你实际的流量模式

生成的测试套件倾向于覆盖人类（或 AI）能想象到的输入，而不是你的系统实际接收到的输入。真实的 API 流量比任何人的想象都要乱：来自合作方过时客户端的畸形 payload、三次集成之前的某种认证 token 格式不知为何还在用、没有人会手动编写的时序模式。完全基于想象场景构建的软件测试自动化会漏掉一整类 bug——只有真实使用才会暴露的那种。

维护仍然是人的问题

AI 可以二十分钟生成四十个测试。但六个月后 API 契约改变、有一半需要更新时，它不会现身。自动化测试一直有维护成本，生成测试更快只是意味着你产生维护债务的速度也更快——除非有什么东西在追踪底层系统随时间的实际行为，并标记出漂移之处。

它不能告诉你该测什么，只能告诉你怎么测

测试自动化真正困难的部分从来不是语法。是决定什么重要：哪些流程是业务关键的、哪些失败模式是可接受的、风险实际在哪里。这是基于你的产品做什么、谁依赖它所做的判断。无论多少 prompt 都无法把这件事外包出去。

接下来的方向

现实的短期图景不是"AI 写你的测试套件"，而是 AI 做更多机械性工作——脚手架、边界情况建议、失败分类——而实际的测试策略、正确行为的 ground truth、以及持续的维护，仍然牢牢是团队的职责。在这个领域长期最重要的工具，可能不是生成测试最快最多的那些，而是让测试紧紧扎根于系统在生产环境中真正做什么的工具——而不是某个人（人类或 AI）猜它应该做什么。

下次当一个 demo 让 AI 驱动的测试自动化看起来像是一个已被解决的问题时，值得记住：那个 demo 测试的是一个已经知道答案的场景。生产环境可没那么大方。