阿里研究员：测试稳定性三板斧，我怎么用？

如何治理测试稳定性问题?很多人会说：环境、流程管控、监控、工具化、加机器、专人负责、等等。这些都是对的。不过这些都是解决方案层面的，而不是方法论和理论体系层面的。今天，阿里研究员郑子颖来说说测试稳定性的三板斧。据说，阿里同学们都非常认同这三板斧，看完文章感觉很多做的事情有了理论基础。

1. 测试稳定性问题

理想情况下，我们希望每一个失败的测试用例[1]都是由真正的缺陷引起的。实际情况中，用例失败的原因大多是一些其他的原因：

某个服务的版本部署的不对

测试执行机的硬盘满了，因为上次运行时写的log没清掉

数据库里有脏数据

测试用例写得有问题

测试运行时有人手工执行了一次定时任务，把流水捞走了

消息串了

...

每次排查都是一堆这种问题，时间久了，开发和测试同学也就疲了。有些同学对失败的用例草草看一眼，就说这是一个“环境问题”，不再排查下去了。如此一来，很多真正的缺陷就被漏过了。

2. 测试稳定性三板斧

如何治理测试稳定性问题?很多人会说：环境、流程管控、监控、工具化、加机器、专人负责、等等。这些都是对的。不过这些都是解决方案层面的，而不是方法论和理论体系层面的。

在方法论和理论体系层面，我们对安全生产有三板斧：可灰度、可监控、可回滚。类似的，对于测试稳定性，我也有三板斧：

高频(Frequency)

隔离(Isolation)

用完即抛(Disposable)

三板斧之一：高频

"If it hurts, do it more often"是我说的最多的一句话之一。这句话从Martin Fowler那儿来的，有兴趣的可以读一下他的那篇“Frequency Reduces Difficulty”的原文。

高频跑测试的好处是：

缩短验证的delay

变主动验证为“消极等待”

识别intermittent的问题

暴露各层面的不稳定因素

倒逼人肉环节的自动化

提供更多的数据供分析

...

高频不单单是治理测试稳定性的不二法门，也是治理其他工程问题的game changer：

持续打包：以前只是在部署测试环境前才打包，经常因为打包的问题导致部署花了很多时间，还影响了后面的测试进度。针对这个问题，我们做了持续打包，每个小时都会对master的HEAD打包，一旦遇到问题(例如：依赖的mvn包缺失、配置缺失、等等)，马上修复。

天天上生产：现在每周发一次生产环境，每次都费事费力。我提出能不能天天上生产。发布还是按照原来的节奏来，每周发一次新代码，一周里的其余日子，就算没有新代码也要走一遍生产发布。空转。不为别的，就是为了要用高频来暴露问题、倒逼人肉环节的自动化、倒逼各种环节的优化。

分支合并很痛苦，那就频繁合并，一天一次，一天多次。做到极致就变成了主干开发，一直在rebase、一直在提交。

蚂蚁的SRE团队也是用的是高频的思路。为了加强容灾能力建设、提高容灾演练的成功率，SRE团队的一个主打思想就是要高频演练，用高频演练来充分暴露问题、倒逼能力建设。

高频也不是那么容易做到的。

高频需要基建保障。首先，高频需要资源。高频执行还会给基建的各个方面造成前所未有的压力。高频还需要能力水平达到一定的基准。就拿SRE的高频演练来说吧。如果每次演练还有很多问题，那是不可能搞高频的。能高频做演练的前提是我们的隔离机制、恢复能力已经到一定的水平了。对于测试运行来说，高频跑测试要收到效果，需要把隔离和用完即抛做好。

对于高频跑测试，一个很常见的疑虑是：原来一天只跑一次，失败的用例我已经没有时间一一排查了，现在高频跑了，我岂不是更没时间了?我的回答是：实际上，并不会这样，因为开始高频跑了以后，很快问题就会收敛的，所以总的需要排查的量可能是差不多的或者反而小了的。

三板斧之二：隔离

相比起三板斧里的其他两个(高频、用完即抛)，隔离的重要性应该是比较被广为接受的。隔离的好处包括：

避免测试运行彼此影响，减少噪音。

提高效率，执行某些破坏性测试的时候不再需要相互协调

隔离无非是两种：硬隔离、软隔离。至于到底是走硬隔离路线，还是走软隔离路线，要根据技术栈、架构、业务形态来具体分析。不过两条道路都是能通往终局：