Flaky Tests 不可靠的测试

Flaky的字面意思是“古怪”、“离奇”的意思，在这里有不可理解、不可靠的含义。Flaky Tests是一种不可靠的测试现象：即在同样的软件代码和配置环境下，得不到确定(有时成功、有时失败)的测试结果。理想情况下，测试结果应该是一致的(Consistent)。一段代码要么就符合预期的运行结果，通过测试；要么就与预期结果不符，测试失败。然而，实际上的质量保证测试会出现完全同样的代码和配置会出现不一致的测试结果。这种现象我们称为flaky test。

测试是软件开发质量保证(QA)的重要环节，不论是网页、应用程序、还是App等开发，都需要进行测试把关方能最后发布。其中常用的测试方式有回归测试(regression testing)。当软件变更或者升级，都会用回归测试来验证已有的功能是否正常的运行。回归测试有一个重要的假设：测试结果是确定的。而Flaky test的结果就是不确定。这使得我们无法信任回归测试的结果。

一、Flaky test带来的问题

1. 难以评估开发人员的能力

测试结果是最容易量化的一个指标，很多公司评价开发人的能力，绩效评核都是基于测试的通过或失败数量或者比率的。当测试结果变得不可靠时，这种评核机制将会失去公允性。

2. 带来时间上的浪费

一些没有变更的代码如果有flaky test带来的测试失败，将带来时间上的浪费。因为开发人员会花大量的时间来调试以应对flaky test的结果，而非代码变更带来的结果。

3. 质量隐患

Flaky test可能隐藏了真正的bug。当flaky test频繁地出现测试失败，开发人员会忽略测试失败的结果，从而错过发现真正的bug。

4. 信任危机

开发人员开始不再相信测试的结果，测试人员开始不太相信开发人员的代码质量。为了一些无法确信结果的测试，双方开始产生怀疑甚至敌对。

Flaky tests并非罕见，有报道说Google有16%的测试就有flaky现象。

是什么造成flaky test的呢？

二、出现flaky test的原因

1. 异步等待

当测试执行时提交了一个异步调用，结果由于种种原因未能正常返回，即开始继续执行。

2. 并发

多个线程在同时执行时，未能按预期的设计进行交互。

3. 有顺序依赖性的测试

原则上测试应具备合理的独立性（而非相互影响），实际并非如此。有些测试会共享某个状态标志，这些状态标志的变更被其它测试所改变，从造成相关测试结果不正常。

4. 资源溢出（如：内存溢出）

如资源没有正常的释放，如内容溢出或数据库连接数满了。

5. 网络不稳定

有时是网络环境的问题，有时是Socket管理不善。

6. 系统时间及相关问题

依赖系统时间的一些测试，包括时间未能同步环境造成的不稳定结果。

7. I/O相关操作

没有及时关闭使用完的文件，该文件被垃圾回收器(garbage collection)关闭。造成后续要使用这个文件测试的结果不稳定。

8. 随机数

有些随机数会影响测试结果，例如：随机到一个特殊的值 ，测试就会失败。

9. 浮点运算

浮点运算特别是高性能运算的算法需要周密的设计，有时上益(overflow)和下益(underflow)问题是flaky test的根源。

10. 无序的集合(collection)数据类型

当轮循某个无序的集合，返回结果也是无序的。如果测试对返回结构的顺序有依赖性，就会出现flaky test的情况。

三、如何处理flaky test

通常有以下几种方法：

1. 忽略

一些开发人员会完全忽略这种测试结果，直接认为是测试本省的问题，而不是代码的问题；

2. 重复运行

一些人将多次重新运行他们的测试，如果测试连续失败或者达到一定失败率的情况下，则认定为测试不通过。

例如：在Google，一个测试结果为失败的用例，在相同的代码和环境下重新运行10次，假如有一次测试通过，则称之为不稳定的测试(flaky test)。

3. 查找代码的问题

最安全的方法是真正找出代码中是否问题，充分调查原因并解决它。如果没能及时发现存在的问题，后续的开发都会建立在这些错误的代码之上，将来会导致更多的问题。

3.1. 重新检查代码、重新检查测试环境、检查外部因素；

3.2.分析是否和时间有关系。如：在某个特定时间运行测试通过，某个特定时间运行测试失败；

3.3. 分析运行环境。如：是否在开发人员的电脑运行正常，而在测试时运行失败？或者在开发人员电脑上失败的方式不同。

通常这些flaky test难以重现，解决这些问题的关键在于是否能收集到详细的相关数据。如：日志、memery dump、系统当前状态、系统截图等等。这些数据可以大大的帮助分析出现flaky test的原因。

四、总结

有时flaky test原因很容易诊断，并且可以快速修复。通常情况下，这种调查和修复的成本高昂且非常耗时。有时为了确保测试结果的确定性，开发人员甚至重写相关代码。

有人说，flaky test is a war that never ends. 我们只有积极的面对它，识别flaky test，控制它的负面影响，甚至正面的利用flaky test结果来促进质量改进。

参考文章：

1. What Flaky Tests Can Tell You by Josh Grant - January 25, 2016

2. Flaky Tests - A War that Never Ends by The Code Gang - December 5, 2017

3. An Empirical Analysis of Flaky Tests

4. 一分钟了解Flaky Test https://blog.csdn.net/u012150933/article/details/84866497