有时会失败并有时会通过的不稳定测试非常令人沮丧:

没有任何单一原因会导致每个不稳定测试失败
使用该应用程序的真实用户似乎不会发生这种失败
需要花费大量的精力和时间来探究测试失败并尝试提出解决方案
,它们会减慢开发和测试过程的速度。
它们会产生误报-测试失败而没有实际问题,而是因为时间,网络,视觉效果问题
通常会由于时间不足而导致片状测试无法继续进行

处理片状的一般策略是什么测试?
如果需要上下文:我们正在使用Protractor / WebDriverJS进行端到端浏览器自动化UI测试。

评论

另请参阅:sqa.stackexchange.com/questions/23172/…

@dzieciou是的,几分钟前偶然发现它,同时研究了重新运行片状测试的严重程度。好信息!谢谢!

对不起,@ alecxe,但这确实感觉像是sqa.stackexchange.com/questions/27923/的副本。但是由于开放赏金,无法将其作为副本关闭。

@MichaelDurrant没问题。已经接近了,但是我认为Yu Zhang专门询问了间歇性错误-100%的时间都无法再现。在这里,我问的是不稳定的测试-有时会失败,有时不会的..希望这样做有意义。谢谢!

好的,在进一步审核之后,我已将我的修改内容从其他内容中删除了

#1 楼

这是我们目前在团队中实施的一般方法:


测量脆度以识别不稳定的测试。一种方法是将可疑测试从主部署管道移至隔离区,在相同的环境条件下多次重复执行这些测试,然后选择产生混合结果的测试(请参阅Martin Fowler的“消除测试中的不确定性”)。 >
修复错误的测试代码。这包括修复明显的错误和更改测试设计。


测试中的明显错误涉及:缺乏隔离性,异步行为,远程服务,时间问题,资源泄漏和全局状态。有关这些问题的说明,请参见《测试中的马丁·福勒的消除不确定性》。学术论文《片状测试的实证分析》中还对根本原因和可能的解决方法进行了更详细的分析。
当团队主要依赖端到端测试时,测试设计中的反模式包括倒置测试金字塔,而很少使用集成测试,甚至更少的单元测试。端到端测试不仅趋于不稳定(因此可靠性较低),而且在隔离故障的根本原因方面也越来越慢。有关更多详细信息,请参阅Google Testing Blog中的Just to No to more end-to-end test。
还有证据表明,测试越大,越容易出现片状。同样,某些工具与更高的片状测试率相关。例如,WebDriver测试(无论是用Java,Python还是JavaScript编写)都以易记的信誉而著称(请参阅Google Testing Blog中的易记测试来自何处?)。这些问题的常见解决方案是:在测试中做更少的事情,从proc之外转为in-proc并从端到端转为组件和单元测试(有关这些解决方案的说明,请参阅Microsoft的Flaky Test Automation赢得) 。


使用片状测试来发现错误。自动化测试有两个目的:网关控制和发现新的错误。网关控制用于验证是否可以包含提交或可以将构建部署到测试环境或可以发布产品。网关控制需要稳定而快速的测试。不稳定的端到端测试虽然适合于发现更多的错误,但不适用于此处。但是,他们的结果需要更多的分析,因为正如OP所指出的,通过片状测试发现的许多错误都是假阳性。 Microsoft的Flaky Test Automation获奖讨论了该技术的细节。


评论


很好的后续阅读资料集,谢谢,今天学到了一些新东西!

– alecxe♦
17年7月3日在0:49

#2 楼

这是一篇处理易碎测试的通用文章:

https://semaphoreci.com/community/tutorials/how-to-deal-with-and-eliminate-flaky-tests

我们发现,使用图像驱动的测试工具(Sikuli,Kantu,Testplant ...),片状测试更易于诊断,因为屏幕截图更容易告诉您出了什么问题,而不是剖析HAR文件和其他网络跟踪。但是它仍然发生。因此,我们的方法是将片状Selenium测试移至Kantu,并将片状Kantu测试移至Selenium。这通常可以消除此问题,因为Selenium测试由于时间和网络原因而失败更多,而图像驱动的测试通常因CSS /字体/分辨率问题而失败。

更一般:使用多个测试工具来获得“第二意见”。通常,在一个工具中测试只是片状。

评论


关于使用其他测试运行程序的出色建议。我认为这可能很有价值的两个原因:1)您可能需要重写测试,这样做可能会重新确认测试是否是可靠的测试,2)每个测试运行者都有不同的特征,如果两项测试均未通过(意味着您的测试很差)。一次通过测试并在另一个跑步程序中失败似乎只是暂时的胜利。但是进步仍然是。

–约翰·伯利(John Burley)
17年7月2日在4:22

#3 楼

通常,在处理不稳定的测试时,我通常遵循此流程图。



#4 楼

我喜欢设置一个重新运行策略,在该策略中,我们重新运行所有失败的测试,直到它连续三次失败。如果两次测试仍然失败,那将是一次真正的失败测试,​​而不是由网络,时间,浏览器或其他基础设施问题引起的。测试有时是用户可能遇到的真正问题。因此,请务必偶尔研究一下您的易碎测试,但是通过重新运行策略,您可以将其推迟到有一段时间之前。运行测试。

随机失败会导致对测试套件失去信心。确保花一些时间来解决问题。

像其他人已经说过的那样,在末端2末端测试中将其最小化,因为它们具有最高的易碎性比率。

其他内容:


https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html


#5 楼

反对片面考验的Google员工本人是徒劳的。

(是的,最后一个链接是对著名科幻小说的引用)。

#6 楼

根据我的经验,您应该执行3个步骤:


测试隔离。您可以在以下博客之一中阅读有关它的更多信息:

https://martinfowler.com/articles/nonDeterminism.html

https://qualityengineer.blog/ 2018 / best-practices-1-test-quarantine /


介绍重新测试策略。只需在每次运行后重新运行失败的测试,然后检查第二次执行是否有帮助。您可以自动执行此过程。
在测试中找出造成片状的根本原因。以下是有关Google如何处理此问题的文章:
https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html


评论


至少在其他答案中已经提到了第一个链接和第三个链接,而您提到的所有三点都已提及。除非对旧问题提供新的见解,否则请避免发布新的答案。

–c32hedge
18 Mar 11 '18 at 20:31

有两点-1)您是qualityengineer.blog的一部分吗? 2)尤其是在回答较旧的问题时,期望答案会带来一些新鲜的东西。您能否描述这个答案带来的新鲜感?

–corsiKa♦
18 Mar 12 '18 at 14:30