阿里研究员：测试稳定性三板斧，赶紧来学习一下

       前言

       1. 测试稳定性问题

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

• 　　·某个服务的版本部署的不对
• 　　·测试执行机的硬盘满了，因为上次运行时写的log没清掉
• 　　·数据库里有脏数据
• 　　·测试用例写得有问题
• 　　·测试运行时有人手工执行了一次定时任务，把流水捞走了
• 　　·消息串了
•         ...

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

　　2. 测试稳定性三板斧

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

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

1. 　　·高频（Frequency）
2. 　　·隔离（Isolation）
3. 　　·用完即抛（Disposable）

　　三板斧之一：高频

　　"If it hurt