重试失败的测试是否是处理不稳定测试的好策略？

#1 楼

我发现重试测试极具风险，除非您认真调查每一次重试。

我从未见过有组织检查过任何重试。实际上，他们使用重试机制的原因是故意减少了他们花费在调查故障上的时间。基本假设是故障是由于测试而不是系统引起的。这是一个非常非常危险的假设。

如果自动化测试在后续运行中给出不同的结果，则意味着某些关键变量不在测试的控制范围内。变化的东西可能在系统中，或者在测试代码和测试环境中。

风险1：掩盖真实的系统故障

如果系统中不受控制的变量，那么每次失败都会尝试为您提供有关系统的信息。如果您重试这些测试，而在随后的运行表明成功时忽略了失败，则您将故意忽略测试旨在提供给您的信息。

如果您认真调查每个失败，则可以降低这种风险。但是正如我之前所说，我从未见过任何组织在重试通过后就认真调查失败。

风险2：破坏信任

如果不受控制的变量在测试代码中或测试环境，那么测试本身在某种程度上是不可靠的。以我的经验，破坏组织对自动化测试的信任几乎不需要可靠性。要重新获得这种信任非常非常困难。

我的强烈建议：请勿使用自动重试。相反，找到不受控制的可变性来源，并加以控制。如果找不到源，或者无法控制源，则将测试标记为不可靠，然后在单独的测试运行中运行不可靠的测试。

可靠性非常重要

我在组织中看到的一个陷阱：“通过所有测试”是测试自动化的目标。

在开发系统时，通过测试是一个很好的目标。在自动化测试时很危险。对于测试自动化，目标是不通过所有测试。目标是：编写能够可靠地告诉您一些您反复想知道的事情的测试。

可靠性至关重要。通过重试来适应片状测试是很危险的。它可以掩盖实际的系统问题。并且它可能破坏您的组织对其自动化测试的信任。

如果测试不可靠，请对其进行修复，消除它们，或将不可信运行标记为不可信。

（为什么，我坐的马很高？）

#2 楼

我在@Kevin上工作，这取决于。

我现在使用的测试系统非常复杂，它取决于由长链子系统组成的基础架构，每个子系统具有很高的可靠性。
作为示例，我们假设99.9％的可靠性和20个子系统。总共有大约98％的正常运行时间，这意味着每天将近半小时！

另一方面，如果您要处理的是对生命至关重要的系统，那么我绝不会认为易碎测试是可以接受的。

另一方面，我有看到片状测试被删除，而没有回到您对测试的最初假设，这使情况变得更糟。

我唯一能提供的可靠建议是尝试花费一些时间来了解这种不稳定性的根源和解决方案。摆脱它，不一定要解决它，但可以解决它，或者重新考虑您的测试环境或代码来重构它。

#3 楼

对于如此多的问题，答案是“取决于情况”。至少对于我使用的测试用例，它们往往会失败，因为同时运行的其他一些测试用例会干扰它们。在理想的世界中，您可以在隔离的环境中运行这样的测试用例，但这通常是不可行的。

所以我个人说答案是看那些容易出现问题的测试用例，并理解为什么它们很容易出现问题。您应该拥有可用于确定测试用例为何不稳定的日志记录。如果您确定其不稳定的原因是因为它在错误的环境中运行，则可以找出解决环境问题的方法，或者执行类似Google的操作并重新运行它们/跟踪它们失败的频率，并且仅

如果它们可以连续修复x次，请对其进行标记。

如果可以修复测试用例，是的，应该这样做，但是与所有事情一样，您必须平衡修复工作量测试用例与不接受修复所承受的风险量，修复所花费的时间等有关。

我要说的是，阅读他们的博客文章，将其16％的测试用例指定为片状声音对我来说太高了。但是，如果不进行调查，很难说这是否太高。

#4 楼

研究片状测试非常耗时。因此，想出一个使它变得更容易，更快的策略似乎是一个好主意。

根据经验，我认为重新运行测试三次是不可思议的数字。经过三次尝试后失败的测试始终是被测应用程序的问题。根本原因较少出现的是一些测试基础结构问题。 （通常需要花费很多时间才能解决）

您的第一点担忧是坚定的。如果有时只是出问题了而现在我们只是忽略了它，而用户却可能三分之一地遇到相同的问题，该怎么办。因此，我认为对Google文章的以下评论非常重要：


我们的重新运行机制仅用于当用户明确要求时标记为易碎或
的测试。


这意味着您必须进行一些研究，然后将其标记为片状。现在，您可以定义自己的清单，以定义何时将测试标记为易碎。只有片状测试才能重新运行3次。不仅盲目地运行所有测试三次。我认为对于单元测试，您可能永远不需要重新运行它们。对于功能性UI测试，这种情况会更经常发生。

您的第二点似乎与云世界无关。并行运行测试，并使测试套件达到所需的速度。

监视重新运行

如果添加默认重新运行您所有测试的策略。比您应该添加测试结果监视和研究比其他测试更不稳定的测试。

XL TestView之类的工具可让您从多个渠道收集测试结果并查看其结果趋势。现在，您只需要关注每天/每周失败的测试，而只有第二次或第三次才能通过。

我认为您确实需要添加保护措施以防止遗漏仅在以下情况下发生的问题某些情况下。为此，您必须不时分析您的测试结果。

#5 楼

在比较失败测试的重新运行的优缺点时，拥有可靠的测试环境是必要条件，而全面覆盖只是次要的。
重新运行的真正问题在于，它可能不会成功。解决脆性问题。除非您进行的测试非常少，否则您仍然会有很高的脆弱性，这将使您的E2E测试层几乎无用。

Dropbox使用的“ under_test”方法是一种简单的解决方案，可能会解决您的问题：




我们开发了一种简单的方法来将测试的相关部分指定为要测试的实际业务逻辑。
我们修改了测试框架行为，以不同的方式对待这些关键部分之外的失败，如“无法测试”，而不是
“失败”。

这大大减少了脆弱性（90％），反过来
减少了维护时间并增加了代码测试的覆盖面，并且
开发人员对测试过程的信任。


在此示例中，仅代码的业务部分是指定为“ under_test”，因此仅将此部分中的故障（也包括片状故障）视为故障，其他部分中的故障将被忽略。

q4312 078q