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

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

郑子颖：阿里巴巴研究员，2002年上海交通大学计算机系硕士毕业。2018年3月加入阿里，负责质量和技术风险。

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的高频演练来讲吧。若是每次演练还有不少问题，那是不可能搞高频的。能高频作演练的前提是咱们的隔离机制、恢复能力已经到必定的水平了。对于测试运行来讲，高频跑测试要收到效果，须要把隔离和用完即抛作好。

对于高频跑测试，一个很常见的疑虑是：原来一天只跑一次，失败的用例我已经没有时间一一排查了，如今高频跑了，我岂不是更没时间了？个人回答是：实际上，并不会这样，由于开始高频跑了之后，很快问题就会收敛的，因此总的须要排查的量多是差很少的或者反而小了的。

三板斧之二：隔离

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

• 避免测试运行彼此影响，减小噪音。
• 提升效率，执行某些破坏性测试的时候再也不须要相互协调

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

• 硬隔离（全隔离环境、物理隔离）要成为终态，关键是成本。要在不增长质量盲区的前提下压缩成本。例如，若是能把整个支付系统都压缩在一台服务器里面跑[2]，并且全部的功能（包括中间件层面的，例如定时任务、消息订阅、分库分表规则等）都能很好的覆盖，那是一个理想的终局。每一个人均可以随时搞几套全量环境，那是很爽的。另外，对架构的拆分解耦（例如，咱们作的按域独立发布）是有助于下降硬隔离的成本的，能够把一整套被测系统部署的scope大大缩小。
• 软隔离（半共享环境，逻辑隔离，链路级别隔离）要成为终局，关键是隔离的效果。若是隔离作到完美了，就能把今天的联调环境部署到生产环境里去跑。这样，就不存在stable环境稳定性的问题了。这样，作到了真正的testing in production，也是个很理想的终局状态。

这两种终局状态，我在我之前的工做中都达到过。的确都能work的。这两种隔离要通往终局，都是技术挑战。压缩成本是技术问题。逻辑隔离作完全作牢靠也是技术问题。

对于咱们今天的支付或电商系统来讲，咱们将来的终局是硬隔离仍是软隔离呢？如今还很难说。从技术可行性方面判断，软隔离更有可能成为咱们的终局。硬隔离作到深水区之后就很难作了，由于会遇到架构的物理极限。突破架构的物理极限，有可能产生新的质量盲区。但至关长的一段时间里，硬隔离会继续对咱们帮助很大。例如，咱们要作各类很是规测试的时候，就须要硬隔离。软隔离要作到可以支持很是规测试，技术复杂度很高。从上个财年开始，我在我团队搞一键拉全量测试环境（硬隔离）的缘由就是：一键拉全量环境相对比较容易作，主要就是自动化，而基于路由的软隔离方案一会儿还不太ready，短时间内达到咱们须要的隔离水平还很难。

硬隔离和软隔离也不是对立的，是能够一块儿用的。例如，咱们在拉起基于路由的隔离环境的时候，拉会新的数据库。在数据库层面是一种硬隔离，是对数据库层面软隔离能力欠缺的一种补充。

总之，隔离是必须的。采起何种隔离方案，要阶段性的基于复杂度、成本、效果等因素的综合考量。

三板斧之三：用完即抛

我最喜欢的另外一句话是：Test environment is ephemeral。这句话是我原创的。Ephemeral的意思就是short-living，短暂的，短命的。我对个人QA团队反复讲这句话，但愿同窗们能在平常工做中时刻记得这个原则。

"Test environment is ephemeral"就意味着：

1. 咱们的test setup能力要很强。咱们今天在搞的一键拉起环境，就是这种能力的一部分。并且setup起来之后，要能快速verify。
2. 咱们的test strategy、test plan、testability design和test automation，必须不依赖一个long living的测试环境。包括：不能依赖一个long living 的test environment里面的一些老数据。例如，Test automation必须能本身造数据，造本身须要的全部的数据。

有了这些能力，可以以零人力成本、很是快速且很是repeatable的从无到有建一套“开箱即用”的测试环境，可以造出来测试须要的全部数据，咱们就能作到测试环境的用完即抛：要跑测试了就新建一个环境，测试跑完了就把环境销毁掉。下次要用再建一个新的。并且，不仅仅是测试环境，测试执行机也要用完即抛。

对于用完还须要保留必定时间的环境，也要设一个比较短的上限。例如，我之前采用过这样的作法：

• 联调测试环境默认生命周期是7天。
• 若是到时间还须要保留，能够延展有效期（expiration date）。每次展期最多能够展7天（至关因而 newExpDate = now + 7，而不是newExpDate = currentExpDate + 7）。
• 最多能够展期到30天（从createDate开始算），须要30天以上的，须要特批（好比，事业群CTO）。
• 这样的好处就是倒逼。必须一刀切的倒逼，一开始会有点痛苦，但很快你们就会习惯的，自动化什么的很快就跟上了。不这么逼一逼，不少改进是不会发生的。

用完即抛的好处是：

• 解决环境腐化问题，减小脏数据
• 提升repeatability，确保每次测试运行的环境都是一致的
• 倒逼各类优化和自动化能力的建设（测试环境的准备、造数据、等等）
• 提升资源使用的流动性。实际的物理资源不变的前提下，增长流动性就能增长实际容量。

测试环境用完即抛的确会引入一些新的质量风险。若是有一套长期维护的环境，里面的数据是以前老版本的代码生成的，部署了新版本代码后，这些老数据是能够帮咱们发现新代码里面的数据兼容性问题的。如今用完即抛，没有老数据了，这些数据兼容性问题就可能没法发现。

这个风险的确是存在的。解决这个风向的思路是往前看，而不是往回退。咱们要探索数据兼容性问题是否有其余的解法。有没有其余的测试或者质量保障手段。甚至要想想，怎么作到“从测到不测”，把数据兼容性问题经过架构设计来消除掉，让它不成为一个问题。

3. 落地

上面讲的三板斧，高频、隔离、用完即抛，的确是有点理想主义的。咱们今天的基建、架构、自动化建设，离理想状态还有很多差距的。

但咱们就是要有那么一点的理想主义的。把这三板斧作好，技术上的挑战是很是很是大的，但咱们有乐观主义，相信咱们可以达到目标。咱们有现实主义，咱们能够分解目标，结合实际状况，一步步的去作。

Note：
[1] 这里的用例主要指的是功能性的测试用例，包括：unit test、单系统的接口测试、全链路/端到端的测试，等等。
[2] 这样子作，实操层面的一个可能的负面影响是它可能会discourage微服务化治理（包括，域自治性，独立测试、独立发布能力等）。

原文连接 本文为云栖社区原创内容，未经容许不得转载。