AI 测试陷阱
你听到有人说“我们这季度的测试用例增加了 40%”，然后大家纷纷点头。
我曾在东京的一家 SaaS 公司见过这种情况。QA 负责人很自豪，管理层很满意，流水线 (pipeline) 也是全绿的。
六周后，支付系统崩溃了 72 小时。竟然没有人察觉，因为 AI 编写的测试只是在检查“是否有错误”，而不是在检查“数据是否正确”。
这就是测试盲区 (Testing Blindness)。
当你的团队生成了大量测试，却无法分辨这些测试是否在“撒谎”时，盲区就产生了。AI 让人们很容易将测试覆盖率误认为测试质量。
最近 Qiita 上的一篇文章展示了这种挣扎。一名工程师使用 AI 来处理没有自动化流程的项目。测试用例生成得很快，指标看起来也非常完美。
但这位工程师最终还是不得不手动学习 Playwright 和 API 测试。为什么？因为 AI 虽然能写语法，但它并不理解系统的运行逻辑。
测试盲区有三个主要症状：
• 断言萎缩 (Assertion Atrophy)：测试通过仅仅是因为它们检查了代码是否崩溃，而不是检查其功能是否正确。 • 边界情况盲区 (Boundary Case Blindness)：AI 专注于“快乐路径” (happy paths)。它会忽略诸如空输入 (null inputs) 或竞态条件 (race conditions) 等边界情况。 • 回归信心膨胀 (Regression Confidence Inflation)：因为测试数量翻倍了，你感到很安全。但实际上，你只是让虚假的信心翻了一倍。
根据我的经验，使用 AI 后，团队可以在短短几个月内从零测试增加到 1,200 个测试。报告看起来完美无缺，但实际的 Bug 检测率却下降了。
在日本，对管理和流程 (kanri) 的重视可能会让这些高数字看起来像是成功。而在西方，团队往往因为 AI 让测试变得太容易而跳过测试。这两条路径最终都会导致生产环境故障。
AI 在优化指标的同时，正在削弱你的调试能力。
如果你在 QA 中使用 AI，请遵循以下规则：
- 每周审计测试：随机抽取 5 个 AI 生成的测试。问自己：“什么情况会导致这个测试错误地通过？”如果你无法快速回答，说明你存在盲区。
- 设置边界配额：每生成 10 个 AI 测试，就必须手动编写 2 个边界情况测试。
- 使用“凌晨 3 点测试法”：问问自己，如果凌晨 3 点发生故障，这些测试能抓到吗？如果你不确定，说明它们还不够好。
- 保留一个模块的手动测试：手动测试一个关键环节。这能保持你的调试技能敏锐。
不要将测试数量误认为测试质量。不要让效率取代判断力。真正能救命的测试，是你真正理解的那些。
自从使用 AI 以来，你的团队是否也遇到了测试质量下降的问题？请在下方分享你的经验。
可选学习社区：https://t.me/GyaanSetuAi