如果有人手动运行测试，那么他们会暂停并了解更多信息。但是，当自动测试失败时，其余部分可能会继续运行。在套件完成之前，你是没有办法看到测试报告的，并且自动化程序不会在故障时执行任何额外的操作尝试找出问题。当剩下的用例全部执行以后，测试人员可能会重新点击一下执行按钮，看看第二遍失败的用例会不会执行成功。

那么，自动测试重试好还是坏？这实际上是一个相当争议的话题。

如果你想学习自动化测试，我这边给你推荐一套视频，这个视频可以说是B站播放全网第一的自动化测试教程，同时在线人数到达1000人，并且还有笔记可以领取及各路大神技术交流：798478386   

 【已更新】B站讲的最详细的Python接口自动化测试实战教程全集（实战最新版）_哔哩哔哩_bilibili【已更新】B站讲的最详细的Python接口自动化测试实战教程全集（实战最新版）共计200条视频，包括：1、接口自动化之为什么要做接口自动化、2、接口自动化之request全局观、3、接口自动化之接口实战等，UP主更多精彩视频，请关注UP账号。https://www.bilibili.com/video/BV17p4y1B77x/?spm_id_from=333.337.search-card.all.click

什么是重试机制？

为避免任何混淆，我们理清“自动测试重试”的意思。

假设我有 100 个自动测试用例。当我运行这些测试用例时，框架将单独执行每个测试，并产生测试的通过或失败结果。在套件结束时，框架将所有结果聚集在一起。在最佳情况下，所有测试通过：100/100。

但是，假设其中一个测试失败了。在发生故障时，测试框架将捕获任何异常，执行任何清理例程，记录故障，并安全地移动到下一个测试用例上。在套件结束时，该报告将显示 99/100 通过一个测试失败的测试。

默认情况下，大多数测试框架将一次运行每个测试。但是，某些测试框架具有用于自动重新运行的测试用例故障的功能。框架甚至可以使测试人员能够指定要重试的次数。因此，假设我们为我们的 100 个测试套件配置了 2 次重试。当一个测试失败时，框架将为这个用例再执行 2 遍，再转移到下一个用例。

 

重试可能被滥用

假设你现在是自动化团队的，每晚为 Web 应用程序提供 300 个自动测试，如大家所知，Web 测试经常不太稳定，每天晚上大约十几个不同的测试失败，每天早上都花了很多时间调试问题。但是当你重新运行这些失败用例时，他们几乎总是通过。所以你现在每天晚上都会会自己的自动化测试程序设置重运行。

这种策略是好的吗？很难说！因为这实际上是在隐藏问题，而不是暴露问题。测试人员应该关注爆红，而不是绿色的通过信息， 通过重运行机制，原来产生红色警示的 10 几个用例都无一例外的通过了， 你还会花精力去分析晚上这 10 几个用例失败可能出现的原因吗？

万一当时确实是在异常的条件下，真的触发了这些用例爆红， 后面因为条件回复正常，才执行成功呢？

如果这种异常条件总是间歇性的出现呢？在这种情况下，用例重运行隐藏了可能出现的 bug。

实际上失败重运行在手工测试也很普遍，不是自动化独有的。测试人员喜欢找到一致，可重复的失败，因为这些失败很容易解释。一旦一个测试问题只是间歇性的出现，我们就没法向开发和团队其他人员解释了。这些问题可能是环境因素导致的，可能是达到的条件比较苛刻，因此难以复现。

通常情况下，如果不能轻松复现这个测试问题，我们会选择沉默，不再和开发继续争吵。而自动化的重运行机制也是这样，当一个用例失败时，我们可以选择复现，如果第二次没再出现，我们就默认了，这里没问题，因为问题没有复现！！

 

那么，失败重运行的正确打开方式是怎样的？

首先，一定要记录所有失败的日志信息和失败原因，如果有必要，不管重运行后有没有成功，只要用例有一次爆红，都应该引起测试人员的警觉：这里是很有可能出问题的。

其次，在项目迭代过程中，我们不一定有时间去解决这些间歇性发生的问题。要复现问题都比较困难，更不要说要分析，和开发人员沟通的过程了。

最终的答案，还是优先级。一致性的失败是我们重点要提交的问题，他们总是报红，不管你是不是做了重运行。当解决了这些一致性失败时，再考虑黄色问题（重运行、警告）。

不管如何，重运行机制是一种非常好的工具和手段，它能让我们知道哪些问题是一致性的，哪些是间歇性的，重点在于，作为测试人员应该警戒所有的红色和黄色，而不是想法设法把红色变成绿色。