阿里研究员：治理测试稳定性的三板斧
郑子颖
讲述：丁婵大小：2.54M时长：05:32
如何治理测试稳定性问题？很多人会说：环境、流程管控、监控、工具化、加机器、专人负责，等等。这些都是对的。不过这些都是解决方案层面的，而不是方法论和理论体系层面的。近日，阿里研究员郑子颖发文介绍了测试稳定性的三板斧。据说，阿里同学们都非常认同这三板斧，即高频（Frequency）、隔离（Isolation）、用完即抛（Disposable），具体如下。
三板斧之一：高频
高频跑测试的好处有以下几点：
缩短验证的 delay
变主动验证为“消极等待”
暴露各层面的不稳定因素
倒逼人肉环节的自动化
提供更多的数据供分析
……
高频不单单是治理测试稳定性的不二法门，也可以治理其他工程问题，比如做持续打包、每天发布生产环境等来暴露问题，并及时修复。
蚂蚁的 SRE 团队也是用的是高频的思路。为了加强容灾能力建设、提高容灾演练的成功率，SRE 团队的一个主打思想就是要高频演练，用高频演练来充分暴露问题、倒逼能力建设。
不过，高频也不是那么容易做到的，这需要基建保障，也需要资源，因为高频执行会给基建的各个方面造成前所未有的压力。另外，高频还需要能力水平达到一定的基准才行。
三板斧之二：隔离
隔离的好处包括：避免测试运行彼此影响，减少噪音；提高效率，执行某些破坏性测试的时候不再需要相互协调。
隔离无非是两种：硬隔离、软隔离。至于到底走哪条路线，要根据技术栈、架构、业务形态来具体分析。不过两条道路都能通往终局。
硬隔离即全隔离环境、物理隔离，要成为终态，关键是成本，要在不增加质量盲区的前提下压缩成本。
软隔离即半共享环境，逻辑隔离，链路级别隔离，要成为终局，关键是隔离的效果。如果隔离做到完美了，就能把今天的联调环境部署到生产环境里去跑。这样，就不存在 stable 环境稳定性的问题了。这样，做到了真正的 testing in production，也是个很理想的终局状态。
这两种终局状态，我在我以前的工作中都达到过。这两种隔离要通往终局，都是技术挑战。压缩成本是技术问题，逻辑隔离做彻底、做牢靠也是技术问题。
另外，硬隔离和软隔离也不是对立的，是可以一起用的。例如，我们在拉起基于路由的隔离环境的时候，拉新的数据库。在数据库层面是一种硬隔离，是对数据库层面软隔离能力欠缺的一种补充。
总之，隔离是必须的。采取何种隔离方案，要阶段性的基于复杂度、成本、效果等因素的综合考量。
三板斧之三：用完即抛
我最喜欢一句话：Test Environment is Ephemeral。其中，Ephemeral 的意思就是短暂的、短命的。我对我的 QA 团队反复讲这句话，希望同学们能在日常工作中时刻记得这个原则。
“Test Environment is Ephemeral”就意味着：
我们的测试设置（test setup）能力要很强，而且要能快速验证。
我们的测试方案、测试计划、可测试性设计和测试自动化，必须不依赖一个长存的测试环境，不能依赖老数据，而是要自己造数据。
有了这些能力，能够以零人力成本快速从无到有建一套“开箱即用”的测试环境，能够造出来测试需要的所有数据，这样就能做到测试环境的用完即抛。不单单是测试环境，测试执行机也要用完即抛。
这样做的好处是：能够解决环境腐化问题，减少脏数据；提高可重复性，确保每次测试运行的环境都是一致的；倒逼各种优化和自动化能力的建设；提高资源使用的流动性，实际的物理资源不变的前提下，增加流动性就能增加实际容量。
不过，测试环境用完即抛的确会引入一些新的质量风险。如果有一套长期维护的环境，里面的数据是之前老版本的代码生成的，部署了新版本代码后，这些老数据是可以帮我们发现新代码里面的数据兼容性问题的。现在用完即抛，没有老数据了，这些数据兼容性问题就可能无法发现。
解决这个风险的思路是往前看，要探索数据兼容性问题是否有其他的解法。有没有其他的测试或者质量保障手段。甚至要想一想，怎么做到“从测到不测”，把数据兼容性问题通过架构设计来消除掉，让它不成为一个问题。
目前来看，高频、隔离、用完即抛三板斧有些理想主义，但面对技术挑战，我们有乐观主义，相信能够达到目标。我们有现实主义，可以分解目标，结合实际情况，一步步去做。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
Landy这和KodeRover的环境模块设计理念不谋而合2
收起评论