阿里妹导读:如何治理测试稳定性问题?不少人会说:环境、流程管控、监控、工具化、加机器、专人负责、等等。这些都是对的。不过这些都是解决方案层面的,而不是方法论和理论体系层面的。今天,阿里研究员郑子颖来讲说测试稳定性的三板斧。听说,阿里同窗们都很是认同这三板斧,看完文章感受不少作的事情有了理论基础。数据库
郑子颖:阿里巴巴研究员,2002年上海交通大学计算机系硕士毕业。2018年3月加入阿里,负责质量和技术风险。安全
理想状况下,咱们但愿每个失败的测试用例[1]都是由真正的缺陷引发的。实际状况中,用例失败的缘由大可能是一些其余的缘由:服务器
每次排查都是一堆这种问题,时间久了,开发和测试同窗也就疲了。有些同窗对失败的用例草草看一眼,就说这是一个“环境问题”,再也不排查下去了。如此一来,不少真正的缺陷就被漏过了。架构
如何治理测试稳定性问题?不少人会说:环境、流程管控、监控、工具化、加机器、专人负责、等等。这些都是对的。不过这些都是解决方案层面的,而不是方法论和理论体系层面的。微服务
在方法论和理论体系层面,咱们对安全生产有三板斧:可灰度、可监控、可回滚。相似的,对于测试稳定性,我也有三板斧:工具
三板斧之一:高频测试
"If it hurts, do it more often"是我说的最多的一句话之一。这句话从Martin Fowler那儿来的,有兴趣的能够读一下他的那篇“Frequency Reduces Difficulty”的原文。优化
高频跑测试的好处是:spa
高频不仅仅是治理测试稳定性的不二法门,也是治理其余工程问题的game changer:架构设计
蚂蚁的SRE团队也是用的是高频的思路。为了增强容灾能力建设、提升容灾演练的成功率,SRE团队的一个主打思想就是要高频演练,用高频演练来充分暴露问题、倒逼能力建设。
高频也不是那么容易作到的。
高频须要基建保障。首先,高频须要资源。高频执行还会给基建的各个方面形成史无前例的压力。高频还须要能力水平达到必定的基准。就拿SRE的高频演练来讲吧。若是每次演练还有不少问题,那是不可能搞高频的。能高频作演练的前提是咱们的隔离机制、恢复能力已经到必定的水平了。对于测试运行来讲,高频跑测试要收到效果,须要把隔离和用完即抛作好。
对于高频跑测试,一个很常见的疑虑是:原来一天只跑一次,失败的用例我已经没有时间一一排查了,如今高频跑了,我岂不是更没时间了?个人回答是:实际上,并不会这样,由于开始高频跑了之后,很快问题就会收敛的,因此总的须要排查的量多是差很少的或者反而小了的。
三板斧之二:隔离
相比起三板斧里的其余两个(高频、用完即抛),隔离的重要性应该是比较被广为接受的。隔离的好处包括:
隔离无非是两种:硬隔离、软隔离。至于究竟是走硬隔离路线,仍是走软隔离路线,要根据技术栈、架构、业务形态来具体分析。不过两条道路都是能通往终局:
这两种终局状态,我在我之前的工做中都达到过。的确都能work的。这两种隔离要通往终局,都是技术挑战。压缩成本是技术问题。逻辑隔离作完全作牢靠也是技术问题。
对于咱们今天的支付或电商系统来讲,咱们将来的终局是硬隔离仍是软隔离呢?如今还很难说。从技术可行性方面判断,软隔离更有可能成为咱们的终局。硬隔离作到深水区之后就很难作了,由于会遇到架构的物理极限。突破架构的物理极限,有可能产生新的质量盲区。但至关长的一段时间里,硬隔离会继续对咱们帮助很大。例如,咱们要作各类很是规测试的时候,就须要硬隔离。软隔离要作到可以支持很是规测试,技术复杂度很高。从上个财年开始,我在我团队搞一键拉全量测试环境(硬隔离)的缘由就是:一键拉全量环境相对比较容易作,主要就是自动化,而基于路由的软隔离方案一会儿还不太ready,短时间内达到咱们须要的隔离水平还很难。
硬隔离和软隔离也不是对立的,是能够一块儿用的。例如,咱们在拉起基于路由的隔离环境的时候,拉会新的数据库。在数据库层面是一种硬隔离,是对数据库层面软隔离能力欠缺的一种补充。
总之,隔离是必须的。采起何种隔离方案,要阶段性的基于复杂度、成本、效果等因素的综合考量。
三板斧之三:用完即抛
我最喜欢的另外一句话是:Test environment is ephemeral。这句话是我原创的。Ephemeral的意思就是short-living,短暂的,短命的。我对个人QA团队反复讲这句话,但愿同窗们能在平常工做中时刻记得这个原则。
"Test environment is ephemeral"就意味着:
有了这些能力,可以以零人力成本、很是快速且很是repeatable的从无到有建一套“开箱即用”的测试环境,可以造出来测试须要的全部数据,咱们就能作到测试环境的用完即抛:要跑测试了就新建一个环境,测试跑完了就把环境销毁掉。下次要用再建一个新的。并且,不仅仅是测试环境,测试执行机也要用完即抛。
对于用完还须要保留必定时间的环境,也要设一个比较短的上限。例如,我之前采用过这样的作法:
用完即抛的好处是:
测试环境用完即抛的确会引入一些新的质量风险。若是有一套长期维护的环境,里面的数据是以前老版本的代码生成的,部署了新版本代码后,这些老数据是能够帮咱们发现新代码里面的数据兼容性问题的。如今用完即抛,没有老数据了,这些数据兼容性问题就可能没法发现。
这个风险的确是存在的。解决这个风向的思路是往前看,而不是往回退。咱们要探索数据兼容性问题是否有其余的解法。有没有其余的测试或者质量保障手段。甚至要想想,怎么作到“从测到不测”,把数据兼容性问题经过架构设计来消除掉,让它不成为一个问题。
上面讲的三板斧,高频、隔离、用完即抛,的确是有点理想主义的。咱们今天的基建、架构、自动化建设,离理想状态还有很多差距的。
但咱们就是要有那么一点的理想主义的。把这三板斧作好,技术上的挑战是很是很是大的,但咱们有乐观主义,相信咱们可以达到目标。咱们有现实主义,咱们能够分解目标,结合实际状况,一步步的去作。
Note:
[1] 这里的用例主要指的是功能性的测试用例,包括:unit test、单系统的接口测试、全链路/端到端的测试,等等。
[2] 这样子作,实操层面的一个可能的负面影响是它可能会discourage微服务化治理(包括,域自治性,独立测试、独立发布能力等)。
原文连接 本文为云栖社区原创内容,未经容许不得转载。