如果没人信任测试失败的结果，那么你的测试套件就是毫无用处的。团队不断增加测试、更丰富的仪表板或并行执行，但开发者仍然一遍遍重新运行流水线，只希望那个红框消失。这种习惯将原本可能具有价值的信号变成了昂贵的噪音。

核心问题在于信任，而非覆盖率

大多数工程团队归咎于测试不足或浏览器覆盖率不够。实际上，失败被视为噪音。96% 的通过率在仪表板上看起来很漂亮，但它无法告诉你那 4% 的失败究竟是抓住了真实的缺陷，还是需要多次重试才能通过。当开发者忽略失败时，测试套件在消耗时间与计算资源的同时，却无法影响决策。

为什么通过率具有误导性

通过率指标将所有结果压缩成一个数字，从而掩盖了两个关键问题：

  • 失败是否揭示了真实的缺陷？ 一个从未抓到 bug 的不稳定测试（flaky test）没有任何价值。
  • 需要多少次重试？ 即使最终通过率很高，一个在三次自动重试后才通过的测试套件也是不可靠的。

一个报告 99% 成功率但反复漏掉结账失败的测试套件，远比一个通过率 92% 但能抓到每一个影响收入的 bug 的套件要糟糕得多。目标不是追求高百分比，而是对风险做出更好的判断。

真正重要的指标

将关注点从通过率转向能够反映测试套件实用性的衡量标准：

  • 失败复现率 (Failure recurrence) – 同一个测试在连续运行中失败的频率。
  • 缺陷检测率 (Defect detection rate) – 失败中转化为确认 bug 的比例。
  • 诊断耗时 (Time to diagnosis) – 理解并处理失败测试的速度。
  • 重试依赖度 (Retry dependence) – 需要自动重试才能通过的测试频率。
  • 逃逸回归 (Escaped regressions) – 尽管有测试套件存在，但仍漏掉的缺陷。

追踪这些信号可以让你知道，一次失败究竟是值得采取行动的警告，还是仅仅是一个不稳定的波动（flake）。

维护的隐藏成本

一个编写只需十分钟，但每月修复却要花三个小时的测试是一项糟糕的投资。当测试变得脆弱、需要不断更新数据或依赖不稳定的 UI 选择器时，维护成本会激增。当 AI 生成测试时，这种开销会变得更加显著。如果生成的测试每次 UI 变动都会失效，那么生成速度快慢就毫无意义。

在评估 AI 生成的测试时，请询问：

  • 测试需要手动编辑的频率有多高？
  • 它对失败原因的解释是否清晰？
  • 人员修复失败需要多少上下文信息？

如果答案指向频繁的人工干预，那么自动化的收益就会消失。

可观测性：让失败变得可操作

一个需要花 40 分钟解析的 4000 行日志，和没有日志一样没用。良好的可观测性能让你快速回答三个问题：

  • 测试的预期是什么？
  • 实际发生了什么？
  • 根本原因是产品 bug、数据问题还是基础设施问题？

测试 AI Agent 需要更深层次的检查

当被测系统是一个 AI 驱动的 Agent 时，测试通过可能会掩盖内部流程的损坏。Agent 可能会通过采取错误的捷径、选择错误的工具或未能正确更新其记忆来得到正确答案。因此，可靠的测试必须检查：

  • 工具选择逻辑
  • 记忆更新行为
  • 错误后的恢复机制

只有当 Agent 在失败场景中表现出可预测的行为时，其输出才是可信的。

将测试维护视为产品工作

以对待任何其他代码的严谨态度来处理不稳定的测试：

  • 删除不再反映业务价值的测试。
  • 审查并重构需要频繁重试的测试。
  • 在数据失效前主动更新测试数据。
  • 为不稳定的或高风险的领域分配明确的所有权。

下一步关注点

关注 AI 生成的测试工具：其价值将不再取决于测试的数量，而取决于手动编辑的减少量以及失败解释的清晰度。

总结

测试套件通过每一次有用的失败来赢得信任。当失败不再有用时，增加更多的测试只会放大问题。将重心从光鲜的通过率百分比转向具体的风险指标，投资于可观测性，并将测试维护视为核心产品活动。其结果将是一个更精简、更可靠的自动化层，它能真正指导决策，而不是让团队淹没在噪音中。