8.0
热点
AI SCORE
编程提效2026-08-09 05:18
AI生成测试的隐藏成本：维护负担远超生成价值
dev.to · AI#AI编程#测试工程#技术债务
Editor brief · 编辑速览
AI能快速产出大量测试代码，但维护成本未降反升；人类对大模型PR的审查标准会更宽松，导致技术债务累积。
AI 编码工具出色地解决了一个问题：它们能以极快的速度生成代码。
这听起来显然是一件好事。
大多数时候也确实如此。
但软件开发从来都不是受打字速度限制的。
昂贵的部分在后面——理解代码。六个月后，当写这段代码的人——或者模型——已经忘记它为什么存在时，再去修改它。
测试自动化是这个问题变得尤为突出的领域。
你可以让 AI 编码助手：
为我们的注册、登录、结账、密码重置、仪表盘、发票、设置和管理员页面编写 Playwright 测试。
几分钟后，你可能就会得到数百甚至数千行测试代码。
这感觉像是难以置信的杠杆效应。
直到测试套件开始失败。
这就是审视 AI 生成测试代码隐藏成本的核心论点：
生成成本已经大幅下降。
维护成本却没有。
在某些情况下，AI 实际上反而提高了成本，因为现在你有比团队手动编写更多的代码。
还有另一个微妙的问题。
人类倾向于以不同的方式评判大型 AI 生成的 Pull Request。
当团队中的某个人写了 80 行代码时，你可能会仔细阅读。
当 AI 助手生成了 1800 行呢？
你只看看文件名，检查一下 CI 是否为绿色。
这对于普通应用代码来说很危险，对于测试代码来说可能更糟，因为一个糟糕的测试可能会愉快地通过数月。
这篇关于测试 AI 编码助手 Pull Request 的指南 中有一些好想法，但更重要的原则很简单：
AI 生成的测试需要像 AI 生成的产品代码一样经过验证。
"生成成功"不等于"测试了正确的东西"。
现在我们从编写测试代码的 AI 转向真正决定采取什么行动的 AI。
这引入了一个新问题：
如果模型选错了工具怎么办？
Agent 可能有权访问：
该操作本身可能运行完美，但它只是选错了操作。
因此，测试 AI Agent 中的工具选择失败成为测试产品的一部分。
动态 Web 应用使这变得更加困难。
部分渲染、变化的状态、异步更新和过时的上下文可能导致 Agent 自信地与页面的"昨天版本"交互。
工具选择、状态漂移和部分渲染的组合，在未来几年可能会成为一个更大的 QA 类别。
AI 测试修复是另一个听起来几乎普遍好的功能。
自动修复它。
但想象一下应用程序曾经有：
测试再也找不到它的元素了。
AI 修复系统找到新按钮并自动更新了测试。
从技术上讲，它修复了选择器。
从语义上讲，它可能改变了测试的含义。
这就是为什么我喜欢在信任自动修复之前评估 AI 生成测试修复的想法。
自愈应该减少维护工作。
它不应该悄无声息地重写你的规格说明。
传统测试仪表盘喜欢通过率。
但对于 AI 生成或 AI 修复的测试，我认为团队需要另一类指标：
这个结论有多可信？
这包括：
这就是为什么这些关于在 CI 中衡量 AI 测试失败的想法很重要。
下一代 QA 仪表盘可能不只是显示 PASS 或 FAIL。
它们会告诉你系统为什么相信这个结果。
这是我思考测试自动化未来发展的有趣方向。
最糟糕的结果是：
AI 生成了人类几乎无法理解的大型自动化框架，然后另一个 AI 来维护这些框架，因为人类已经无法理解它们了。
这在技术上是令人印象深刻的。
但这也是一个奇怪的归宿。
更好的结果是 AI 生成人类仍然可以检查、理解和修改的测试表示。
用 AI 来减少工作。
不要用它来创建一个更大的黑盒。
因为真正的生产力指标不是：
AI 生成了多少测试代码？
而是：
你的团队需要考虑多少测试基础设施？