测试稳定性三板斧，我怎么用？

• 行机的硬盘满了，因为上次运行时写的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团队的一个主打思想就是要高频演练，用高频演练来充分暴露问题、倒逼能力建设。

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

（编辑：淮安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!