AI 测试自动化，先别怪模型不聪明

很多团队讨论 AI 测试自动化时，第一反应都是模型还不够稳，生成的用例不够聪明。这个判断不能算错，但不够完整。我最近一个月把 CI、Copilot、Codex 和测试流水线串起来跑，看到的问题更像另一面，人没有把测什么、怎么算过、失败后归谁说清楚。

这类工具最容易让人高估的地方，是它能很快生成一段看起来像测试的东西。点击、断言、元素定位、失败日志摘要，这些活它确实能接。行业里常见的自愈能力，也大多集中在元素识别和 locator 变化上，页面改版后把按钮从 A 换成 B，它能顺着属性找回来。可一旦问题上升到业务意图，它就开始发虚。比如订单金额该测前端展示，还是测支付回调、风控扣减，这背后是团队对业务边界的理解，模型只能猜。

我这边试过把一段接口契约丢给生成器，让它补测试。结果它写得挺勤快，覆盖了空值、越界、重复请求，但漏掉了一个会出事的场景，用户重复提交时，下游幂等键没有生效。这个漏测来自输入里根本没告诉它幂等失败会怎样，也没有把线上事故复盘变成可验收的测试标准。很多所谓 AI 没测出来，背后是人把测试设计当成一句话需求扔进去了。

更麻烦的是，AI 还会把错误放大。它依赖数据质量，也依赖上下文质量。测试数据如果脏，业务规则如果含糊，模型就会把偶然路径当成必然路径。它还可能从代码里反推测试，生成一堆代码能跑通的断言，未必是用户能用通的断言。这个区别在平台团队里很常见。代码路径测得越熟，越容易忽略真实用户会怎样绕路、回退、并发、超时。机器擅长维护局部正确，人负责判断整体是否值得。

从管理视角看，AI 测试自动化这个方向值得投入，但 ROI 算过没有，不能只算脚本生成时间。省下来的写用例时间，如果没配上一套验收机制，最后会变成更多没人看的失败红点。以前测试工程师写脚本，问题还容易归因；现在 AI 一次生成一批用例，团队反而要先回答哪些是冒烟，哪些是回归，剩下的再分业务关键路径和噪音。分类不清，治理就难做，自动化也可能变成成本放大器。

AI 测试自动化的难点，是让用例拥有可验收的业务边界。这句话听起来像套话，落到组织里很具体。产品、测试、研发和平台要分别给出关键路径、失败分类、数据契约和执行指标。自动化测试产生的 pass rate、执行时间、覆盖率，这些指标能看趋势，不能直接当质量结论。一个覆盖率很高的流水线，可能只是把低风险用例重复跑了十遍。

所以我会建议团队别急着把 AI 当成测试负责人。先把它当助手，把人的判断留在验收流程里。用例生成可以交给 AI，准入仍要人判断。失败日志可以让 AI 归纳，归因需要人签字。自愈能力可以接受，但每次自愈都要留下变更说明，不然半年后没人知道这条测试为什么还活着。多 Agent 协作也是这样，边界不清，最后就是互相甩锅。

我最近看这类工具，心态比刚上手时更谨慎一点。谨慎是因为它太容易把看起来自动化和实际工程效率混在一起。测试这件事，原本就是团队质量的镜像。需求模糊、数据脏、验收不严，它都会把这些问题放大，生成一堆漂亮但没用的东西。

往后看，能吃到红利的团队，往往是最早把测试资产当基础设施管的那一批。工具会换，模型会升级，边界不清的团队还是会每天追红点。

---

📌 本文编译自 Hacker News，原文 https://www.davidmello.com/software-testing/test-automation/ai-test-automation-pitfalls-vs-user-error

版权归原作者所有，本文为基于公开报道的编译与独立分析。