前言

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

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

　　三板斧之二：隔离

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

　　·避免测试运行彼此影响，减少噪音。
　　·提高效率，执行某些破坏性测试的时候不再需要相互协调
　　隔离无非是两种：硬隔离、软隔离。至于到底是走硬隔离路线，还是走软隔离路线，要根据技术栈、架构、业务形态来具体分析。不过两条道路都是能通往终局：

　　·硬隔离（全隔离环境、物理隔离）要成为终态，关键是成本。要在不增加质量盲区的前提下压缩成本。例如，如果能把整个支付系统都压缩在一台服务器里面跑，而且所有的功能（包括中间件层面的，例如定时任务、消息订阅、分库分表规则等）都能很好的覆盖，那是一个理想的终局。每个人都可以随时搞几套全量环境，那是很爽的。另外，对架构的拆分解耦（例如，我们做的按域独立发布）是有助于降低硬隔离的成本的，可以把一整套被测系统部署的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. 落地

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

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

最后：

大白创建了一个技术交流群，群内有一些从事软件测试8-9年经验的大拿讨论交流，群内也有资料共享，想要入群的朋友可以私信大白

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

mysqls压力测试怎么用_阿里研究员：测试稳定性三板斧，我怎么用？
阿里妹导读:如何治理测试稳定性问题?很多人会说:环境.流程管控.监控.工具化.加机器.专人负责.等等.这些都是对的.不过这些都是解决方案层面的,而不是方法论和理论体系层面的.今天,阿里研究员郑子颖来说 ...
阿里研究员：测试稳定性三板斧，我怎么用？
阿里妹导读:如何治理测试稳定性问题?很多人会说:环境.流程管控.监控.工具化.加机器.专人负责.等等.这些都是对的.不过这些都是解决方案层面的,而不是方法论和理论体系层面的.今天,阿里研究员郑子颖来说 ...
阿里总监：测试稳定性三板斧，你了解多少？
一.测试稳定性问题理想情况下,我们希望每一个失败的测试用例都是由真正的缺陷引起的.实际情况中,用例失败的原因大多是一些其他的原因: a.某个服务的版本部署的不对 b.测试执行机的硬盘满了,因为上次运 ...
测试稳定性三板斧，我怎么用？
如何治理测试稳定性问题?很多人会说:环境.流程管控.监控.工具化.加机器.专人负责.等等.这些都是对的.不过这些都是解决方案层面的,而不是方法论和理论体系层面的.今天,阿里研究员郑子颖来说说测试稳定性 ...
测试稳定性三板斧，你了解多少？
一.测试稳定性问题理想情况下,我们希望每一个失败的测试用例都是由真正的缺陷引起的.实际情况中,用例失败的原因大多是一些其他的原因: a.某个服务的版本部署的不对 b.测试执行机的硬盘满了,因为上次运 ...
敏捷测试的“三板斧“
什么是三板斧可灰度:任何变更,都必须是可以灰度的,即控制变更的生效范围.先做小范围变更,验证通过之后才扩大范围可监控:在灰度的过程中,必须能做到可监控,能了解到变更之后对系统的应用可回滚:当通过 ...
阿里研究员：软件测试中的18个难题
简介:对于软件测试来说,怎么样才算测够了?如何评价测试的有效性?那么多测试用例,以后怎么删?在软件测试中会遇到非常多的问题,阿里研究员郑子颖分享了18个他总结出的难题以及相关看法,希望对同学们有所启发 ...
阿里研究员谷朴：警惕软件复杂度困局
作者 | 张瓅玶(谷朴) 阿里巴巴研究员 **导读:**对于大型的软件系统如互联网分布式应用或企业级软件,为何我们常常会陷入复杂度陷阱?如何识别复杂度增长的因素?在代码开发以及演进的过程中需要遵循哪 ...
阿里研究员：警惕软件复杂度困局
简介:对于大型的软件系统如互联网分布式应用或企业级软件,为何我们常常会陷入复杂度陷阱?如何识别复杂度增长的因素?在代码开发以及演进的过程中需要遵循哪些原则?本文将分享阿里研究员谷朴关于软件复杂度的思考 ...

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

前言

1. 测试稳定性问题

2. 测试稳定性三板斧

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

最新文章

热门文章