什么是重试机制？ 为避免任何混淆，我们理清“自动测试重试”的意思。
假设我有100个自动测试用例。当我运行这些测试用例时，框架将单独执行每个测试，并产生测试的通过或失败结果。在套件结束时，框架将所有结果聚集在一起。在最佳情况下，所有测试通过：100/100。
但是，假设其中一个测试失败了。在发生故障时，测试框架将捕获任何异常，执行任何清理例程，记录故障，并安全地移动到下一个测试用例上。在套件结束时，该报告将显示99/100通过一个测试失败的测试。
默认情况下，大多数测试框架将一次运行每个测试。但是，某些测试框架具有用于自动重新运行的测试用例故障的功能。框架甚至可以使测试人员能够指定要重试的次数。因此，假设我们为我们的100个测试套件配置了2次重试。当一个测试失败时，框架将为这个用例再执行2遍，再转移到下一个用例。
重试可能被滥用
假设你现在是自动化团队的，每晚为Web应用程序提供200个自动测试，如大家所知，web 测试经常不太稳定，每天晚上大约十几个不同的测试失败，每天早上都花了很多时间调试问题。但是当你重新运行这些失败用例时，他们几乎总是通过。所以你现在每天晚上都会会自己的自动化测试程序设置重运行。
这种策略是好的吗？很难说！ 因为这实际上是在隐藏问题，而不是暴露问题。测试人员应该关注爆红，而不是绿色的通过信息， 通过重运行机制，原来产生红色警示的 10几个用例都无一例外的通过了， 你还会花精力去分析晚上这 10 几个用例失败可能出现的原因吗？
万一当时确实是在异常的条件下，真的触发了这些用例爆红， 后面因为条件回复正常，才执行成功呢？
如果这种异常条件总是间歇性的出现呢？在这种情况下，用例重运行隐藏了可能出现的 bug。
实际上失败重运行在手工测试也很普遍，不是自动化独有的。测试人员喜欢找到一致，可重复的失败，因为这些失败很容易解释。一旦一个测试问题只是间歇性的出现，我们就没法向开发和团队其他人员解释了。 这些问题可能是环境因素导致的，可能是达到的条件比较苛刻，因此难以复现。
通常情况下，如果不能轻松复现这个测试问题，我们会选择沉默，不再和开发继续争吵。而自动化的重运行机制也是这样，当一个用例失败时，我们可以选择复现，如果第二次没再出现，我们就默认了，这里没问题，因为问题没有复现！！ 那么，失败重运行的正确打开方式是怎样的？ 首先，一定要记录所有失败的日志信息和失败原因，如果有必要，不管重运行后有没有成功，只要用例有一次爆红，都应该引起测试人员的警觉： 这里是很有可能出问题的。 其次，在项目迭代过程中，我们不一定有时间去解决这些间歇性发生的问题。要复现问题都比较困难，更不要说要分析，和开发人员沟通的过程了。 最终的答案，还是优先级。一致性的失败是我们重点要提交的问题，他们总是报红，不管你是不是做了重运行。 当解决了这些一致性失败时，再考虑黄色问题（重运行、警告）。