那个让我凌晨三点崩溃的用例

凌晨三点，办公室里只剩我工位上的灯还亮着。

屏幕上，Jenkins的自动化测试报告刚刷出来——失败用例17条，通过率83%。我点开每一条失败记录仔细看：元素点击超时、页面加载失败、元素未找到……所有错误都指向同一个结论：不是程序出bug了，而是环境不稳定、网络波动、页面渲染慢了那么一两秒。

最让我崩溃的是，我重新手动跑了一遍刚才失败的用例，全过了。17条失败，一条都不该失败。

那一刻我坐在工位上，盯着屏幕上那个"失败"的红字，心里只有一个念头：自动化测试到底在测什么？如果连稳定运行都做不到，那些报告里所谓的"测试结果"有什么意义？

为什么自动化跑不稳

后来我才明白，自动化测试不稳定，本质上是"理想环境"和"真实环境"之间的差距造成的。

手工测试的时候，人是有"弹性"的。页面加载慢了，你等两秒再点；网络波动了，刷新一下就好；弹窗突然冒出来，随手就关掉。但自动化脚本没有这种弹性——它按照预设的步骤执行，每一步的等待时间固定，一旦实际环境偏离了脚本的预期，它唯一会做的事就是报错、退出、把一条记录标红。

在聚客AI的课上，老师讲过一个让我印象很深的数据：一个中等规模的自动化测试项目，由环境问题导致的假失败占比通常在30%到40%。也就是说，你看到的失败用例里，差不多每三条就有一条是"冤假错案"。

这个数字让我倒吸一口凉气。如果一个测试报告里三分之一以上的失败都不可信，那这份报告有什么价值？

重跑方案，不是万能药，是止痛药

学失败重跑方案之前，我对这件事有偏见。我觉得"失败就重跑"是在掩盖问题，会让真正的bug被忽视。但学了之后我明白了，重跑方案的本质不是"掩盖失败"，而是"过滤噪音"。

课上讲的策略比我想象的要细致得多。不是简单的"失败就重跑三次"，而是分层级的处理：网络超时类错误可以立即重跑，因为往往是瞬时波动；元素定位失败需要等待几秒再尝试，因为可能是页面渲染滞后；而断言失败、业务逻辑报错这类硬错误，重跑多少次结果都一样，直接标记为真实失败。

这种分层逻辑让我重新理解了自动化测试的本质：它不是简单的"用脚本替代手工"，而是要把人的判断和弹性也编码进去。一个合格的自动化测试系统，应该具备基本的"抗干扰能力"——知道什么情况值得再试一次，什么情况必须停下来报告问题。

从"跑完就行"到"跑得可信"

实施重跑方案之后，最直观的变化是测试报告的可信度大幅提升了。

以前每天早上来公司，第一件事就是看昨晚的自动化报告。看到"失败"两个字，心里先紧一下，然后花半小时逐个排查，结果大部分都是环境问题。现在有了重跑机制，那些偶发性的失败被自动滤掉了，报告里的"失败"基本都能对应到真正的代码问题。

这个过程让我重新理解了自动化测试的价值。它不是为了取代手工测试，也不是为了生成一份好看的报告。自动化的真正价值是"可信赖"——当它说"失败"的时候，团队可以第一时间相信这是一个需要认真对待的问题，而不是先怀疑"是不是环境又抽风了"。

技术之外的思考

做自动化测试这几年，我对"不稳定"这件事的理解也在变化。

最开始，我觉得"不稳定"是我的代码写得不够好，是我定位策略不够健壮，是我等待时间设得不够长。后来我发现，测试本身就是一个概率性事件——页面渲染快慢、网络延迟高低、服务响应时间波动，这些都不是脚本能完全控制的。

接受这个事实之后，我开始用不同的视角看失败重跑：它不是"掩盖问题"，而是"承认不确定性的存在，然后用策略去管理它"。就像写代码要处理异常一样，测试脚本也应该处理"环境异常"——重跑就是其中一种常见的处理方式。

老师说的一句话我到现在还记得："自动化测试的价值，不在于跑出100%的通过率，而在于每一次失败都有意义。"

这大概就是我学这门课最大的收获。失败重跑方案教会我的，不是怎么写重跑逻辑，而是怎么让每一次失败都值得被认真对待。