本文为Dell EMC 中国研发集团资深架构师茹炳晟老师在 430 DevOps 线上峰会的分享整理而成。
作者简介 茹炳晟 资深架构师 DELL EMC 中国研发集团
今天下午通过40分钟时间介绍一下 DevOps 体系下的测试中台建设方面的尝试以及相关探索。我一直在测试领域长期耕耘，主要涉及自动化测试、DevOps、工程效能方面，下午40分钟跟大家分享一下三个话题。
一、DevOps 体系下自动化测试能力的重要性。我们一直讲 DevOps，但是要把 DevOps 这个事情做好，如果没有相应的自动化能力支持，这个 DevOps 很难真正开展起来，尤其是 CI 方面的相关工作。
二、介绍一下中台技术的核心理念，我们讲测试中台，首先需要理解广义的中台怎么回事，大家需要对中台概念有基本认识。
三、测试中台建设的初探。
如果时间来得及，除了测试中台的基础介绍之外，还会探讨一些比较有意思、有创新并且已经在企业里面落地的一些实践。
1.关于 DevOps 体系下自动化测试能力的重要性
讲自动化测试能力对 DevOps 体系的重要性之前，看一下整个IT界发生了哪些变化。从六个纬度描述一下IT领域的技术迭代演进趋势，从应用架构、开发模式、测试模式、运维发布、资源单位、资源管理画了时间轴。
每个条目下都有非常大的变化，比如架构从单体变分层架构再到微服务架构，开发模式也从早期的瀑布模型到敏捷开发再到完全是DevOps 混合在一起的模式，以及将来可能更多是 AIOps 或者 SRE 这种模式。
测试也是在这个领域里面发生了很多变化，从早期手工测试到自动化测试的，再到现在强调测试左移贯穿整个生命周期的测试，再以后可能就是智能化测试。
在这个体系里面大家可以清楚看到整个业界的技术生态的变化是非常快的，面对如此快速变化的生态发展，软件研发能力以及DevOps的体系建设在整个过程当中起到了非常重要的推波助澜的作用。
只有当我们的研发体系、测试能力、研发执行力，能够配合这些东西的逐渐迭代和改进的时候，我们才能快速匹配我们的产品快速交付的能力。这种情况下我们的测试其实对于 DevOps 来讲，我认为是对整个 DevOps 能否正常顺利开展是起到了非常关键的作用。
下面这个图可以看到是典型的CI过程，每个环节其实都要经过测试环节。如果你的CI的流水线要能够正常、完整地跑起来，我们在每个环节都高度依赖于我们的测试，更确切地说更依赖于自动化测试能力。只有我们把自动化测试能力的成熟度做到一定级别之后，才能让各个环节无缝串联在一起。
早期的时候对于自动化测试能力可能是火车跑得快，都要车头带的模式。早期我们对于测试能力的培养，更多是在最后环节做相关测试。像早期火车一样，只有火车头是有动力的，后面被趿拖拽的箱体是没有动力的。当你拖的箱子越多的时候，必然对速度有影响。
这种模式在现在的迭代下越来越难，因为现在的软件复杂度越来越高，不管是运维的复杂度、产品架构的复杂度都越来越高，这种模式下必须转变我们测试的理念，不能再用传统的火车模式，必须把这个理念切换成动车模式。动车和火车最大的区别就在于每一节都有动力，而不是靠车头带动所有的，所以整个速度才能提升起来。
回到CI体系里面的各个环节的自动化测试，每个测试都应该在整个CI过程当中发挥应有的作用。只有把这些东西做起来，并且做到一定的稳定程度之后，整个CI的体系或者说整个DevOps的运作才能非常顺利。
但是这个过程当中，我们知道理论是简单的，实际过程当中受限于自动化能力的成熟度或者规范化程度，我们里面还有很多困难，决定往这个方向走仅仅只是开始，很多实际问题摆在我们面前。很多同学都是来自于企业的，企业都在进行自动化测试，并且也在尝试自动化测试和CI/CD。但是有很多问题，最主要的就是你的自动化测试能否稳定，如果稳定性不高，就对整个自动化测试失去信心。
同时由于你的公司里面可能不是一个项目要用CI/CD的模式，你就会发现自动化框架的选型也会成为问题，不同的项目组可能选用不同的自动化框架或者工具，这样就会造成各自都会对一些工具有定制改造，就会造成重复造轮子，很多能力跨项目跨产品，在一个公司内部被重复建设。
这个过程当中也会碰到很多通用的难点，比如测试环境准备花的精力非常大，测试数据准备也非常困难。这些东西有没有解决方案，有没有系统化能够一锤子就把这些问题系统解决掉的整个解决方案？答案是有的，我们就可以利用测试中台的方式。
我们通过测试中台可以解决自动化框架跨项目、跨产品的工具统一，以及我们对于微服务环境的自动化构建，包括全局的测试数据准备，帮助我们提高测试执行的稳定性。这就引出了今天要讲的重要话题，就是测试中台。
2. 中台技术的核心理念和发展
讲测试中台之前，先介绍一下中台的核心理念和他的基本概念。很多做 DevOps 的同学对中台技术并不一定非常清楚。首先要对中台的概念做个初步介绍，再引出测试中台这个话题就变得理所当然，而且变得非常顺。
首先聊一聊中台的概念，中台的概念在整个中国甚至整个世界范围内是非常里程碑式的概念。很多像早期的分布式架构这些词都是来自于国外，但是中台这个概念是阿里巴巴提出的，理论上是里程碑的，是完全由中国人自主提出的全新概念，但是实施过程中也有很多问题。
首先看一下中台的概念到底怎么来的？中台的概念说复杂挺复杂，说简单也简单。对于中台的概念，很多时候要把这个概念讲清楚，有可能会比较迂回。但是，如果我们从中台发展过程当中看一下中台的概念，你就会发现理所应当。
这个要从早期的阿里说起，当时做电商的时候阿里看不清将来的电商到底是什么模式，所以当时阿里的体系就对整个电商做了一拆三，也就是说淘宝做C2C，天猫做B2C，还有一淘做搜索电商的。这种模式下就出现了同一个公司里面做不同的产品线，但是你发现像淘宝、天猫、一淘这种产品线，这里面支付、搜索、物流、用户这些概念都是通用的，换句话说这些模块的功能都是通用的。
如果你把一个集团内部不同的产品线，每个产品线都要实现支付、实现用户，就会造成一个个烟囱上面都要重复造轮子。于是阿里就想出一个方法，能不能把这个东西提炼出来，比如说支付单独提炼出来，用户模块单独提炼出来，当构建具体产品应用的时候就可以用公共用户的模块，公共支付的模块，这就形成了早期的共享事业部。
后来聚划算的出现，也证实了共享事业部的英明决定，因为聚划算当时上线非常快，这个概念被提出来到上线只花了一两个月的时间，为什么能够做到这么快？其实聚划算就是站在了前人的基础上，也就是他把支付、用户模块都不是从头做起，而是用了这种模块化的思想。这其实就是是中台概念最早的萌芽状态。
中台这个概念被阿里真正提出来，缘起于2015年马云带了高管团队拜访了位于芬兰赫尔辛基的一个手机游戏公司，这家公司做出很多风靡全球的网红款爆款游戏，背后却只有区区不到200个员工，但是每年收入基本二三十亿美金的规模。所以马云非常好奇，这么小的游戏团队怎么打造出这么多网红爆款，于是2015年的时候他就拜访了这家公司。
这家公司为什么做的这么成功？其实不是每个游戏都很成功，而是他打的快，而且打的多，他必须每一枪的成本足够低，这个又怎么实现的？他用了这样一个逻辑，他把游戏开发过程当中需要用到的很多共享的东西，比如引擎、素材、存储、模型这些东西都沉淀下来，变成通用的东西。
然后当你开发游戏的时候，就像搭乐高积木一样去拼装，这样一来你很小的游戏团队只要把精力花在我如何让这个游戏做的更好玩，可玩性更高，怎么样让游戏反馈更及时，怎么样让游戏的完备性设置的更好，而不需要考虑很多底下的技术细节了。这样他就可以快速试错，也就是说我可以拼装一个游戏，这个拼装的成本非常低，而且拼装研发的时间周期也非常短，也就做到了我在打靶子的时候，不是每枪都打的准，而是每枪都打的足够快，成本打的足够低。这样才支撑了他这么多成功的游戏。
换句话说不是说他的每个游戏都非常成功，其实成功的游戏也就是这上面三四个，下面死掉的游戏连名字都没有，这些游戏死的足够快。很多时候项目不是怕失败，就是怕半死不活的项目。可以看到这种理念就非常颠覆。所以马云回来之后得到了很大启发，回来之后才真正宣布了中台战略。
讲了历史之后回头来看到底什么是中台理念？举一个非常通俗的例子总结一下刚才的思路。比如下面左手这个图有一个工具箱，假定工厂的工人拧螺丝，工人A做了一个一字螺丝刀，工人B做了一个十字螺丝刀。
那个老板觉得这两把螺丝刀很多场景下可以用，于是老板做了一个工具箱，把一字螺丝刀和十字螺丝刀放在工具箱里面，告诉大家以后如果有需要就到这个工具箱来拿，按需取用就可以了。在这个例子里面，工具箱本身就是中台，螺丝刀在企业级的能力的复用，其实就是中台的核心概念。
在这个基础上我们给出了一个中台的定义，这个定义是ThoughtWorks的首席咨询师王健讲的，他是这样定义中台的“企业级能力的复用平台”。企业级讲的是什么？一定是跨多个项目，跨多个产品线的。
这个能力定义了中台主要的承载对象，这个能力是广义的。如果说这个能力是业务就是业务平台，如果是数据就是数据中台，如果是测试能力就可以理解成测试中台。
DevOps 本身就是跨产品线的，而且是跨了很多项目，所以 DevOps 本身就是研发体系上能力复用的中台或者平台，他也是符合中台思想的。我们给出了中台概念，接下来这个图就给出了中台典型的架构，时间关系不展开了，但是我们通常讲的中台就三类，一类是业务中台、数据中台、技术中台。要保证整个东西完整的顺利交付，我们分别用DevOps和测试中台来支持完整的研发周期，本质上讲，测试和DevOps又是完全交融在一起的，相互配合完成质量保证业务发布的整体过程的。
讲了这个之后就给大家非常清晰的概念，什么叫中台。这里再多看一些，我们讲了很多技术的时候思维方式非常重要，我们刚才讲的这些中台概念基本我的理解还是属于看待问题的纬度还是比较低的，我们对于中台架构更多理解的是一种技术上的或者是架构设计上的，也就是说是在一个企业内部，比如说互联网大厂的各种中台建设。
但是如果我们发散一点来看，这种思想可以扩展到产业中台，是行业内跨企业的一些整合。DevOps的工具平台像效率云这些东西，本质上就是所谓的产业上的中台。也就是说我把这种能力从企业里面提炼出来，可以跨行业为多种同类型甚至不同类型的企业提供统一的能力，DevOps就是非常典型的这样一种能力，测试的中台也是这样的能力。
如果我们还站在这个纬度看又狭隘了，如果我们跳出这样的纬度，像饿了么和美团本质上也是产业中台，他就是把线下小的餐饮企业和线上的能力提炼出来，去哪儿也是同样的，也是通过一个平台把各个小代理商的能力整合起来。
从产业中台再往上看，就到了中台思维的概念。如果我们可以站在更高的视角，可以发现中台概念在秦国的时候就有了，苏秦挂六国相印就是这样的概念。还有华为大平台炮火支撑精兵作战，让听得见炮火的人到前面作战。如果前线明确知道该怎么打的时候通知后台，后台去炮火支援前台，这个后台的炮火其实就是中台的思维，这个炮火不是为一个战场服务的，是为多个战场服务的。
3. 测试中台的建设与探索
接下来看重点，看一下测试中台到底怎么回事。测试中台就是要解决如何和DevOps更好地做配合，在需要跑测试的各个环节上可以把测试顺利跑起来，可以把测试的东西全权代理给测试中台处理。整个CI体系更像调度或者编排的中央控制机构，测试中台就把所有的测试能力都集中在完整的平台上。
在这种思想的引导下，我们有理由建立起全面可重用的测试中台。下面的这个图看起来比较复杂，但是可以先简单看这里天蓝色的模块，其实就是测试中台当中的一些具体的服务，测试中台本身不是一个服务，测试中台本身就是由一系列的相关辅助测试执行跟测试相关的所有这些环节的综合体。
这些环节各自服务于测试过程当中的各个环节各个特殊目的，这些服务合在一起，整体构成了整个测试中台，可以为企业的某个产品或者多个产品甚至跨不同企业提供测试能力的支撑，以及和DevOps、和CI一些相关的支撑。
这个体系里面大家看一下，从小的几个纬度来看。首先来看SUT Setup Service，他就是用来帮我们搭建测试被测环境的。因为我们发现在做测试的过程当中，尤其在CI体系下做测试的过程当中，你要跑测试之前必须准备测试环境，必须拿到对应的制品包，然后对这个制品包进行部署，才能开展相关测试。但是早期的时候如果你搭测试环境，如果是单体架构，这种部署可能一个脚本就能解决问题，但是我们一开始讲过我们的架构从早期的单体向分布式向微服务在变化。
这个Service就是把被测环境安装的复杂性进行了打包，也就是说你只要知道我要搭什么环境，至于怎么搭，如何找到被测环境需要的安装包，这些东西都不用管，都由这些服务整体帮你完成所有事情。
有时候可能不能完整搭建整个被测环境，这种情况下可能会需要一些Mock服务，这种构造Mock服务的嫩李也是测试中台能力中的一部分，通常，在银行或者一些机构里面常把Mock服务称作为挡板系统，类似于挡板的概念，来帮你提供为了测试而采用的辅助系统。
在测试过程当中还会牵涉到我们要执行测试，要在CI过程当中跑某个具体测试，如果你的测试是端到端的测试，这些测试可能就要考虑不同的浏览器之间的相关兼容性，甚至是手机终端不同的兼容性。这种情况下就需要用到不同的浏览器，不同的操作系统和不同浏览器相关的具体组合，这个东西怎么得到？难道让每个同学自己安装这些环境吗？如果我要跑某个手机型号，难道我要自己找手机型号吗？显然这种东西都是非常低效，如果这些东西都要自己准备的话，CI就没有办法高效开展。
为此我们就设计了一个服务，就是完全帮你接管测试环境，这个测试环境指的是测试执行环境。比如说不同操作系统上不同浏览器版本的准备，都会有一个叫做Test Bed Service的服务帮你完成。
由 Test Bed Service 所准备好的测试执行环境通常都会有统一的agent，这个就是把测试执行过程当中相关的数据、相关信息都会通过agent发送给Test Report Service，Test Report Service的作用就是收集执行过程当中各个纬度的日志，包括测试执行环境上的日志，也会收集被测环境下的日志，然后放在统一的地方，然后给大家提供统一的测试报告，统一的问题定位，统一的问题分析趋势等等，提供这样的服务，这种东西都不需要每个团队自己做，你只需要这个所创建的测试执行环境跑测试，跑出来的测试结果都会送到这些报告上。
同样在测试过程当中，在Test Bed Service上，我们执行里面也要准备大量的测试数据，这些测试数据谁来准备？我们会有统一的Test Data Service。也就是说我的Test Cases只要告诉 Test Data Service 说我要在某套测试环境下准备一个美国的用户。你只要把这个信息告诉Test Data Service，Test Data Service就会在被测系统上直接生成或者搜索到一个符合你要求的测试数据，然后返回给测试用例，然后就会根据拿到的测试数据进一步往下做相关测试步骤。
这种情况下，我们的Test Data Service把我们对于测试数据构造的复杂性的问题打包了，变成了统一的服务，然后把这些复杂性都屏蔽掉，测试人员只需要把精力放在我需要测试什么样的业务，需要准备什么样的测试数据上，而不用管实现的具体细节了。
还有一个比较重要的或者说非常重要的，是测试执行服务，这个可以说是任何测试唯一的接口，你要发起测试不用跟其他任何东西打交道，你只要跟这个打交道就可以。这个服务提供两个对外的接口，一个接口是Request接口，还有一个接口是UI的界面。前端界面给谁用？是给人，比如说测试工程师自己，或者你的产品经理想跑一些测试，他会有个图形的界面，你可以选择我要跑哪种测试，被测环境应该用什么等等，这些东西的选择都在这个图形界面上进行完成。这是给人去用的。
还有一个接口是Request from CI/CD接口，这个接口完全给CI用的，也就是说CI/CD这些流水线里面，每个阶段都是要跑测试，CI在不同的阶段应该发起不同的测试。比如到了这个阶段，我要跑一轮API的测试，CI流水线就会通过这个API接口调用Test Execution Service。也就是说凡是要跑测试的对外接口，都是由Test Execution Service对外统一提供。
这个Service接到请求之后，就会把获取测试用例的代码，调用SUT Setup Service来搭建测试环境。同时也会调用下面这条线调用Test Bed Service去准备我们的测试执行机，他接下来就会把测试用例拉下来，然后再执行，在执行环境上执行相关的测试。整个过程整个体系全部由它来统一调度，或者由它统一完成。这样的东西其实就是测试唯一的交互接口点。
这种情况下就可以让我们的CI工作和我们的测试可以做到非常漂亮的解耦，我们把这部分东西都单独抽离出来。这样的平台不仅适用于单个产品，可以适用于整个公司的产品线，甚至可以跨公司变成产业的中台，他就变成了对外卖的产品。
当然这个过程开始的时候，我们肯定不是一股脑就可以把这些东西全部做出来，所以这种中台的建设并不是说一股脑先做这个再做那个，测试其实等不及的，所以整个过程当中我们基本都是按需一步一步来建设整个中台的。
也就是说这个过程当中并不是先做一个很大的，不是所有的企业都需要这样的测试中台，如果你的企业做一个产品，就一条单一的产品线，而且短期内也没有大的产品线，那你不要做测试中台，你应该是搭一套比较好的自动化测试平台，甚至可以把这些服务都合在一起，变成够用就行。
因为你拆开来一定是有成本的，如果你的业务场景本来就很单一，产品本身就很单一，测试中台绝对不是你的最佳选择。所以这些点上，企业落地过程当中应该都要有自己的一些相关思考。前段时间我受腾讯的邀请做过一个演讲，主要讲的就是这样的观点。
接下来看看测试中台的概念大家有了之后，测试中台到底怎么建？刚才已经给大家看了主要的两个坑，我们对整个测试中台的建设过程当中，基本的感觉是我们对于测试中台建设必须采用北极星指标的方式，北极星指标其实产品经理是在产品纬度上的概念，所有的指标最终要为最终方向服务的，北极星指标就是你最终产品想做成什么样子，然后再做相关设计。
我们测试中台的北极星指标又是什么？我们的北极星指标就是让多个产品线或者多个项目的测试能力能够共享，让多个团队重复造轮子的成本能够删减掉，而且每个团队做的最佳实践能够推广给其他的团队，而不是我自己优化了，别人没有，别人要用自己去开发，这种在公司内部就会造成大量的浪费。
如果我们把终点定成北极星指标的话，如果只看这个大图的话，大家可能觉得整个过程就是目标有了要做这个系统，我过去就行了。但是现实过程当中肯定是下面这个图，所以我要强调的几个点。第一个点就是不要一下子全上，应该从痛点开始逐步击破。
比如说测试的时候环境的部署最困难，那你一开始先做这个。比如说测试数据最困难，那我们先把测试数据建立起来。只有当你解决了一些很痛的问题，管理层看到这个东西的效果之后，大家认可了这种方式之后，你才有可能逐渐做大。
第二点可以用NBP最小可执行产品的概念打造测试中台，同时这个过程当中，在测试中台建设过程当中，有一个点一定要规避的，不是技术上的，而是管理上的。大家熟悉DevOps都知道有一个可执行指标，还有虚荣性指标。
其实对于测试中台建设过程当中，我们也要明确分清楚哪些是可执行指标，哪些是虚荣性指标，比如说我开发了很多Service，那就是虚荣性指标。这些Service开发完成之后有多少用户在用，有多少项目用了，有多少个需求的实现是通过你这个平台，通过这个测试中台发布出去的，我们应该关注这样的指标，而不是纯粹的虚荣性指标。
最后再举一个例子，前面讲的内容，这个东西还是比较大，我们给大家举两个比较典型的例子。第一个例子讲讲Test Data Service，Test Data Service能够帮助我们创建各种各样的测试数据，大家立马想了既然这个产品以后能够跨平台、跨产品共享的，这些数据本身你怎么可能让一个公共的测试中台知道所有的测试数据的创建逻辑，这简直是悖论。所以测试中台建设过程当中，一定要做思想的转变，一定要把我们的思维从原来唱戏的转变成搭台的。
刚开始的时候如果我们是草团班子，我们下乡演出。刚开始的时候要吸引大家来看，我们自己搭台自己唱戏。
随着你演的场次变多之后，我能唱的戏很有限，你为了能够继续运营下去，最佳的就是我只提供舞台，只提供这个舞台上的功能，灯光、效果、喇叭、场地等等，但是唱戏的这个事情可以让大家一起来，这样一来这个模式才能长久玩下去。这个模式如果理解了，对于测试数据服务同样的道理。
刚开始的测试数据服务里面，必须带有一些能帮我们创建典型数据的能力，比如可以创建订单等等。这个能力的创建主要是让大家先上这个船，越来越多的人上了这个船之后，大家发现我数据的多样性光靠测试数据准备的团队很难完成，这种情况下就要退而求其次，我们要变成搭台的，要变成测试数据平台，至于创建具体数据的业务逻辑不再归我管，我会以内部开源的方式或者我搭一个脚手架，你通过脚手架来生成，你只要把创建数据的业务逻辑按照脚手架实现，生成的这个包可以无缝融合到测试数据的Service里面来，我就从原来拥有数据执行逻辑的平台，变成了拥有这个平台，对于数据本身不去管控，这样一来可以把数据服务做的更通用更大。
