AI 写自动化测试用了半年，真正能上生产的只剩这些

原文：https://dev.to/speaklouder/i-let-ai-write-my-tests-for-6-months-here-is-what-actually-survived-production-4h2（作者 @speaklouder）

上个月，有同事在我们的PR频道里贴了一个Playwright测试用例，附言道：“AI 4秒钟就生成了这个，我们为什么还要手写测试。”

测试通过了。但它没有断言任何东西。它点击一个按钮，等待3秒，然后检查页面是否依然存在。绿灯亮起，价值为零。

我从事自动化测试三年有余，主要用Playwright做Web端，用Flutter做移动端。过去六个月里，我在工作流中大量使用AI。其中一些确实改变了我的工作方式，但更多的只是噪音——人们太兴奋了，以至于不愿承认那是噪音。

这里是一份坦诚的划分。

AI 真正能胜任的工作

1. 将缺陷报告转化为测试用例。

这是最大的单点收益，却几乎无人提及。我们的QA团队用自然语言编写缺陷报告，例如“应用优惠券后，移除最后一个商品，购物车总价未更新。”我将这句话连同我们的页面对象文件一起输入给模型，不到一分钟就能得到一个合理的、会失败的测试。

不是一个完美的测试，但足够合理。我仍然需要重写断言。但那些枯燥的脚手架代码、导入、fixture设置、导航步骤，全都搞定了。这大概消除了60%的输入工作。

2. 解析一个非你所写的不稳定测试。

你懂那种感觉。一个测试每跑20次就失败一次，它是一个14个月前离职的同事写的。你打开它，发现里面嵌套了四个等待和一个硬编码的8000毫秒超时。

把测试代码和追踪日志一起贴给模型，询问可能的竞争条件是什么。模型大概一半时间是对的，但即使它错了，也会提供一个可证伪的假设，这比盯着文件看要快得多。如果你想了解非AI层面的解决方案，我写过更多关于端到端测试不稳定模式的内容。

3. 为混乱的DOM结构提供定位器建议。

给它一段HTML，询问最稳定的定位器。它通常会建议你使用getByRole和getByLabel，而不是你原本想写的、噩梦般的CSS选择器。它基本上就是一个带意见的代码检查器。

AI 在哪里失灵

它不知道什么才是重要的。

AI会为“快乐路径”编写测试，因为代码里只有快乐路径。它永远不会问：“如果支付webhook被重复发送了怎么办？”这个问题来自凌晨2点被重复webhook坑过的亲身经历。那是领域知识，不是模式匹配。

我抓到的真实缺陷中，大约80%来自没人会想到用AI生成的测试。

移动端Web才是它真正的短板。

这部分让我很惊讶。AI模型是在海量的桌面Web测试代码上训练的。当你问及视口特定行为、触摸目标，或者在390px宽的屏幕上粘性导航栏如何吞噬你的点击事件时，模型的表现会急剧下降。它会自信地给你一个桌面端的解决方案，并称之为移动端方案。

我最终自己编写了关于Playwright移动端Web测试的参考手册，因为我总是得到相同的错误建议。设备模拟、真实的触摸事件以及屏幕方向处理，仍然需要真正见过这些缺陷的人来处理。

Flutter 的情况更糟。

如果你的应用是Flutter，做好心理准备。训练数据很稀薄。请求一个widget测试，它会给你一个看起来可行的东西，但使用的API在两个版本前就改变了。请求一个冒烟测试套件，它会给你一套穿着Flutter外衣的Web模式。

基于这个原因，我们的Flutter冒烟与回归测试配置几乎完全是手动构建的。AI帮助了测试内部的样板代码编写，但在测试结构设计上毫无帮助。

自愈定位器多半是营销噱头。

每个AI测试工具都推销这个功能。实践中，一个能静默修复自身的定位器，就是一个停止告诉你UI已发生变化的定位器。有时，UI变化本身就是缺陷。我宁愿我的测试大声地失败。

我当前的实际工作流程是这样的

1. 我自己编写测试计划。用自然语言，写在任务票据里。什么应该坏掉，以及我为什么关心。
2. AI根据这个计划加上我现有的页面对象生成测试骨架。
3. 我重写每一个断言。每一个。
4. 在进入CI流水线前，我在本地运行20次。
5. 如果在第4步中出现不稳定，我会删除它并重新开始，而不是添加等待。

第3步是人们会跳过的步骤，但恰恰是最关键的。AI生成的断言检查某个东西是否存在；人写的断言检查某个东西是否正确。这是完全不同的工作。

我的其他自动化测试笔记更深入地探讨了CI方面，如果你正在从头搭建这套体系的话。

令人不安的部分

AI 提升了我编写测试的速度。但它并没有让我更擅长判断应该编写哪些测试。而第二项技能，恰恰才是这份工作的核心。

我认为目前对于刚进入 QA 领域的人来说，存在着一个真正的风险。如果你在学会分析故障模式之前，就先学会了如何提示 AI，你将会产出一个规模庞大、看起来完全通过但什么也抓不住的测试套件。我已经审阅过几个这样的套件了。它们比没有测试更糟糕，因为它们制造了一种虚假的信心。

现在告诉我我错了

我有三件事想在评论区听到你们的回复，我会一一回应。

第一。 AI 曾经为你生成过的最蠢的测试是什么？我想收集这些案例。我遇到的是一个在登录流程后断言 expect(true).toBe(true) 的测试。

第二。 在座有人真的在真实生产套件中让自愈式定位器实际发挥作用了吗？我真心愿意在这个问题上被证明是错的。如果你有这样的成功案例，请告诉我细节。

第三。 如果你测试 Flutter 或 React Native，AI 对你有用吗？还是你的体验和我一样糟糕？

我也很好奇，是否有人已经转向了基于 MCP 的设置，让模型直接驱动浏览器而不是生成代码。我尝试过两次，每次结果都比直接编写测试更慢，但我怀疑是我使用方式不对。

请在下方留下你的看法。尤其是在你不同意的时候。

原文：https://dev.to/speaklouder/i-let-ai-write-my-tests-for-6-months-here-is-what-actually-survived-production-4h2（作者 @speaklouder）