全栈式互联网测试平台打造实战

白凡

今天首先是我给大家来分享一个话题。叫《全栈是互联网测试平台打造实战》。

这个东西这么说，我自己是在软件质量这个行业是做了16年，前2年做台风，后面一直做质量测试这块。然后做这种DevOps相当于在京东我是第三次，2016年时候在咱们官方组织分享了一次，当时在上海站，那个时候属于萌发，给大家讲一讲心路历程，现在已经又4年过去了，想给大家讲一些什么东西呢？因为这几年来是互联网测试的平台已经不是什么新鲜的产物了，所以想给大家讲一下怎么建平台，而不是只是谈一些观点或者偏理论性的东西，因为现在国内各个互联网公司测试团队、质量团队多多少少都会有相应的测试开发团队，他们的职责就是服务于测试人员，平台有大有小，怎么来做，今天主要给大家讲设计，如果你是一个测试架构师，怎么来设计一个测试平台，所以今天主要是围绕这个话题。这个不多说了，上午我也介绍了，我是满人，镶黄旗，跟慈禧太后也算是同宗，我本来就是他们的后人，但是不扯这个，咱们进入正文，时间非常有限。

今天给大家讲4个话题：一个是全栈式测试的平台化指引、测试的服务的原子化能力、测试左移、测试右移，开启新时代。

1. 全栈式测试的平台化指引

直接进入主题，全栈式测试的内涵，我的个人理解，所有的东西全是我个人理解，大家可以信也可以不信。

全栈式测试，我的理解是从两个维度来理解，一个是在基础层面上，咱们现在要对你公司里面产品的或者系统的这种技术形态进行全方位的测试，它的对照是什么？就是传统时代咱们一些软件测试的团队是把前端的测试、后端的测试，或者说专门做性能测试的，专门做安全测试的，把这几拨人是分开的，尤其在2010年前外企的时代或者一些传统时代，但是如今的互联网行业基本上讲究全栈式，一定要把所有的测试类型混合起来，这对平台的构建有一个考验，你的平台测试时候要考虑到不同层次、不同分层的时候测试，把它拧成一股绳，而不能孤立地去看待接口测试这个事情、性能测试这个事情。

第二个维度指的是过程上，它是基于公司的IT交付模式去设计你测试团队的组织模式与权责规范。这是什么意思？它其实跟左边是对照的，也是参照以前，以前在传统时代咱们讲CNI或者讲ISO这些过程标准，会有QA这个角色。但是在如今的互联网时代大家都紧绷效率，紧绷效率意味着啥呢？企业，尤其团队规模比较大的情况下，你是不可能有非常多的QA人员。软件过程改进这件事情渐渐也落到测试这个角色上，我不知道大家认不认同。你可以想一下你们公司有没有QA，有也不会很多，不会有那么多QA。那么做这种软件质量的，就是软件的过程改进这个职责渐渐也会落到测试的身上。所以测试这个角色它现在变得，它的职业能力或者说它的职责边界变得非常宽泛，它绝对不是光在测软件，还要保证过程的质量，因为这件事情是需要的，谁去做没有更多人去做，测试是一个非常好的职责。这是我想讲的东西。

然后直接进入正题。互联网测试全栈式包括哪些东西？大的维度咱们永远跑不到功能的层面，性能层面，安全层面、兼容性层面。这些维度。功能维度仍然占60%-80%的比重，后面三个可能会占百分之二三十，跟传统的IT系统的测试相比互联网它有多端，它尤其强调多端，而且这个多端将来会进一步蔓延。目前来看咱们的几端，移动端、接口层，PC端。

光移动端就有安卓、IOS，H5、M站、小程序等等，未来还会有汽车终端、还会有手表终端，还会有家用电器终端。现在还没有特别产业化，但是两三年之后可能就要有了，你们公司要做兼容测试，可能要测汽车操作系统，要测电冰箱的操作系统是不是兼容，一定会有这些，而且很快，5G一旦普及这些东西将来都会在上面来跑。在移动端还有一个特别的专项内容，就是网络、容错、冲突打断、系统权限、内存、埋点这些东西是属于移动互联网时代典型的特征，在十几年前是没这些玩意，光移动端就这么一大坨。我说今天我主要给大家讲的话题是拿这些东西，你站在一个测试架构师或者测试一把手的角度来想你怎么测试你们的平台，根据你们测试团队的工作内容，下面这些子系统是你要切的要拆出来的，依据这些测试的类型你要组装你的测试系统，比如移动端的测试子系统，外部测试子系统，移动端性能测试子系统，大促压测这些时间是我们电商专门有的，不做电商不太有，多多少少会有一些，像做互联网金融你们也会在618这种事情搞一些什么活动，在互联网的生态里面，阿里京东定的618、双11包括传统的节日总会有些活动，只是像电商尤其规模庞大，所以我们会有大促压测的，这些话题一会我的同事马鑫会来讲。这些测试怎么结合你的测试过程，下面这块，你每设计一个测试子系统的时候要想到它的应用场景是什么，根据你们公司或者说白了就是你定的测试过程是什么样，如何把这些测试的东西应用到不同的层面，像移动端测试子系统在回归级一般会用的，还有埋点，可以在需求级，还有回归，包括质量门槛，我写的一些特别的要素，大家可以参考。

下面这个图更准确一些，这是我个人理解18年来最精华的，我个人认为。它是结合DevOps整个流水线下你的典型的互联网测试过程它应该展示的形态，我认为这个图是我最值得自豪的一个东西。传统的或者说相对不那么互联网的一些测试过程你总会分成需求分析、开发设计、什么集成测试、系统测试、回归测试、上线反馈那几个大阶段，这都属于传统时代的这种瀑布流最上面的轴，但是在典型的互联网它怎么跟CSD去结合，应该这个样子结合，我的看法。所以这是过程维度。大家可以看工作规划、需求分析、用力设计、需求级测试、回归测试、上线验证、生产监控与反馈，这都是一个团队的核心职责。你想一想你们的公司团队是不是也从这儿开始干成。产品经历开始顶板，测试人开始排期，人不够还得借人，测试范围确定，工作量估算，这块大有学问了。到用例评审，开发自测选择，多少公司包括咱们面试也一样，你问很多公司，他总说我们公司的开发自测做得多好多好，我这里强调一点，开发人员的自测范围是测试人员给的，定义的，是一个比较好的实践，所以你需要把这个实践在平台里落实下来。你不能说我们公司开发人员做的自测怎么怎么样，没有什么证据，或者写一个邮件OK了，这是属于现象化的，你在平台里就要考虑这个维度。需求级的测试，就根据你具体的需求特征，移动端、PC端，特定数据、埋点，性能，开发体测就开始启动CI流水线，现在DevOps这些东西都是标准的。你能在你的CI流水线集成的质量门槛或者质量控制的手段越多越好，越能保证需求级的测试快速充分。这个比较经典的场景是什么，代码扫描，自动的代言测试，甚至整个FVT，环境一定要带健康度扫描，环境如果能被机器自动构建起来，一定要健康度扫描，否则一定会有些不一致的地方出现，会因为环境的问题造成你测试该不该报BUD有很多莫名其妙的事情，所以环境要一致。包括运行的测试等等，不细说了，细说太慢了。

然后进行回归测试，上线前的验证，生产监控。

下面这块值得稍微多说一点，传统软件测试的职责只是中间，就是研发的BUD管理Bug跟踪，但是在新型的互联网测试下，测试的角色被放大了很多，所谓的左移右移就是一个影子，目前互联网测试团队有一个职责是可以充当半个QA，他会去监控这个过程的预测过程，比如Bug多，比如开发人员不遵守工作规范，强制上线等等，这些异常的行为你想一想，如果测试不报那就没人报了。而且东西反反复复真实在每天可能会发生，会造成上线风险。你把一个测试工作者的职业能力给他定位到质量管理的角度，那么这个就是他的职责。道理在这里。右移就是典型的生产缺陷分析，后面我写更多的，后面有一些持续的例子给大家看。

第二个依据前面我说的技术维度还有过程维度。这个图上午我老板给大家展示，只不过他是旧的，我这是新的。依据你们公司一个团队，基本上三四十人，尤其过50人，你的测试团队，如果是一个统一的团队，有这种质量管理的一把手，什么总监、高级经理也好，不管叫啥，基本上就是考虑这个事情。二三个人没什么大问题，像我们100多人一定会有问题。所以这就是我们真实的平台，我们名字叫穹天，因为第三次做，所以没走什么弯路，现在我们做这个东西基本上从一开始策划就是比较清晰的，三层结构。上面是这些垂直话的子系统，这些子系统有的是我们自己建的，有的是兄弟团队建的，集团现有的成熟直接用，用你不能让用户脱离开，数据要一致，因为最终所有测试人捏他工作的产出要有一个统一的度量视图，这是一定的。大概是这个样子，一般基本的服务我们都把它拆成PAAS化的考量，京东这些东西做得还可以，至少不是二流，更不是三流。所以我们这些服务化开放化这些东西现在都在储备，可能几年之后就会问世了。大概设计是这个样子的。

2. 测试服务的原子化能力

这个站点大家有兴趣可以进去看，因为我接下来要讲的就是挑一些关键的节点，关键的一些原子化的服务给大家讲设计逻辑，今天给大家讲如何打造测试平台，你是测试架构师怎么来建平台。因为这个很大，所以贴图是远远不够的，所以我们在这次演讲之前特别花了三五天给大家带了一个模板，我们正式在公司内部才能用，所以我们特别现在放到京东云这么一个模板，有兴趣可以看，没兴趣可以拉倒。还是比较挫，我认为我们的前端设计不太好看，但是功能后台一切的东西都是围绕着我今天讲的内容。

第一个讲用例，如果我前面说20多个子系统一个一个给大家讲，咱们得讲一下午，这是不可能。所以今天只给半个时间，只能给大家讲一个关键的。
讲用例大家感觉这东西有啥好讲，但是我作为一个老测试我是深有体会的，几个非常普遍性的问题大家可以想一下，第一，咱们现在互联网公司下的测试用例不可能像传统的等价类边界那些方法去挟制，不可能，很多人都认为过时的。第二个现实很多公司的测试用例，咱们拿这些东西来管理，这些东西也是可以的，但是它最大的问题在啥，测试用例可以依据需求去写的，有需求有用例，或者最多分离出一套回归用例库，我来京东之前他们也是这么干的，我认为这不好。所以我这里面有第一个要点，指导性。用例的设计视角需基于系统，而不是零碎需求，我不推荐用例基于需求去写，软件系统功能的不断迭代你的用例库也要根据它不断迭代，哪个功能作废，对应的用例也要作废。哪些东西需要更新了，做一个新需求是对现有的功能特性进行的一些新的变化，那么你不要写新的用例，你应该拿老的用例去直接更新它，这样永远保证你的用例库里面有效地用例是跟产品的形态是一致的，因为软件互联网产品它的功能迭代就是在不断改，你的用例库也是不断更新，这是一致的，这个一致性非常重要。你适当选择根据它的优先级可以去选择哪些该回归哪些不回归。这是我的一个观点。

第二个是用例模版需根据测试类型分层设计，而不是固定。这是什么意思呢？前面我第一张图就画了，根据互联网这种分层测试的需求，你的接口用例，兼容性用例，不同的用例尽量以模版的形式来表现，它最大的好处在于你的团队不会特别依赖于谁能力强谁能力不强，说白了它是组织资产。能封装的封装起来，能通用的通用起来，而不是说你们公司谁谁谁写的用例特别好，这样不好，它不利于组织整体能力的打造。所以通用之后就可以高度复用，就像那些兼容性那些专项的测试根本不需要写用例，这些测试点就是你们企业一部分固化用例库，可以这么来理解。我再说一遍我这些观点，一些肺功能性测试哪怕功能里面比较固化的这些测试的用例尽量通用，让它复用起来，不要过度依赖于人的水平高低，它会形成一种组织资产。那么你在构建平台的时候一定要考虑这个，而不是满足某个个性的测试工程师我这个用例就是满足某个测试，那个不值一提，关键整个公司企业用例库是跟产品的形态是一致的。

下一个用例库需分成通用库和迭代库，后者引用前者，前者是核心。这个我刚才说了。

测试报告中如实展示用例实行回溯，基本上如果你有平台一定会这么干的，但是有些平台也不这么干。这里面我想说的最重要的一点是啥呢？一些平台或者小平台你会发现咱们的用例是用例，测试结果是测试结果，测试报告是测试报告，它串不起来。它最大的弊端在哪里？当你们公司对质量要求比较高的时候，追究线上漏测的时候你没有证据。报告上的数据、结果、Bug关联是不容串改的，如果做平台一定要考虑这个东西。不然把用例、结果报告那些东西全拼出来不好，那是容易串改的。

便捷性，就是用例形式，用表格、导图这些东西要考虑，包括易评审、易封装开发自测集，结合需求分析，对用例生产却似进行智能推送，评估预测风险，增加排期说服力。给大家解释一下，我们的用例沉淀下来，加上异常事件这些东西，进行一个综合评估之后，那么可以针对用例设计，包括测试工作量的排期进行一些智能的估算，现在还达不到一个非常准确的预测，但是我们是有兴趣往上面发展的。因为现在我们这块搞的东西基本上把能想到基本上都做好了，下一步就是上我这样的话题，测试这个角度如何去AI，智能预测一定是其中很大的场景，所以我们现在沉淀着沉淀着，一两年之后应该会有突破了。
价值性不多说了，不给大家细说了。

下面给大家参考几个东西，结合上边我这些观点，当你设计出来的平台针对用例如何去度量，可以度量哪些东西，你可以度量用例库的通用程度比，通用用例库自动化程度比，用例库与缺陷比这些东西。因为做平台最终一定要考虑度量，考虑度量你就会设置一些度量指标，如果再拿传统的指标就没意思了，一定会发现脱节的。一定要结合新型的互联网形态的测试工作的发生去设计你的度量指标，所以我估计这些概念很多人都是第一次看见，因为就是我编的。

第二个是接口测试。有啥可说的？你自己公司开发一些小的测试工具也足够，那就没意思了。首先一定要结合你全栈式测试的多维度的这种分层的思想，接口测试与功能测试，我是这么分的，功能层业务场景的测试与功能层的接口测试他们都是面向软件的功能的验证手段，一个通过UI层，一个通过接口层，他俩是互补的。只要测好这个需求，我想走UI层就走UI层，想走接口层就走接口层，哪个适合哪个便捷我就用哪个，所以他俩的测试思想一定是要一致的，你不能孤立地看待，或者有些人只是做接口测试，有人只做移动端测试，那那些人不疯了？那些做服务端的测试永远摸不了手机，那些玩爱尔思都没有机会摸安卓，反过来讲，我天天玩安卓的人都碰不到IPHONE，工作的内容非常单一，也不利于他的职业成长，就要把这些东西综合起来看待，这些东西都是你平台的能力，你养的团队充分去选择，用哪一招有效就用那一招，但是他们测试的结果是一致的，你不能孤立去看待，孤立看待一定会有过度测试那么一说。

所以，接口测试有几个要点跟大家分享一下，也是我的几个观点。第一，对接口基本验证实现全自动。既然做测试平台，你一定要想到你要超越20年前的老东西，你跟它差不多那啥意思？一点意思都没有。所以对于接口层这些服务化的协议其实完全可以有一些基本的验证，通过计算机直接测试，人无需干扰。比如那些非空的、边界值的、或者一些参数可选的，或者返回码的，这些基本的验证，你想一想你们公司的测试员肯定不可能面面俱到去测试，因为这种活很烦，非常花时间。第二时间确实有限，正常的功能我还有时间测一些选项，或者是一些数据类型或者返回码，这些基本的东西当你设计平台的时候尽可能让计算机全实现，这些基本的东西全没有人去介入，这是你做平台最大的价值之一。

常态化就不说了，监控性给大家说一点，当你考虑一个新的测试平台的时候，接口层这块一定要把监控纳入到你的测试工具里，让测试人员不工作两次，反过头来有些公司写接口脚本的人，跟做接口在生产环境下监控的人是两拨人，或者说干两次活。当你要设计平台一定要考虑这个问题，把这两个事合一，它写一次脚本又能做需求级又能做回归级的测试，同时又能满足上线生产监控的要求。因为你做平台永远要讲究效率。至少我是这么想的，我在我们这个平台每个设计上其实都会想着如何用用户操作更方便，让他不要重复工作。所以每个点都尽可能去想，一定要效率提升，只有每个点都效率提升了最后测试的整体工作效率才提升。

下面这个度量没时间讲了，以后再说了。

移动端兼容性测试子系统，我们想做自己的Testing，只不过还有Testing的商业化，这个大家一说就知道了。所以在移动端兼容性这个子系统来说，我们现在就是京东自己在孵化，还没有特别成熟，现在只能实现机器的全控，它那个Testing可能要1000台手机，我们可能100款，达不到那个规模，我们给监控自己人用就行了。时间有限，就不展开了。

3. 测试左移与右移实践

第三个测试左移。我刚才前面也说了，传统IT时代测试的职责，这是我15年前做软件测试培训师，我在2005年到2008年在那块做培训，我的工号是005呢。我们当时做培训最经典做测试给测试职位定位四大职责，16字箴言，就是需求分析、用例设计、测试执行、缺陷跟踪。对于15年前来说就是这个样子，测试工作就是干这4样活，干好就行。互联网时代附加内容，回合测试为主题，发现缺陷尽量前置，生产Bug跟踪，我是半个QA，监控过程质量，推动过程改进，要懂基础运维，这是当下互联网生态下的测试这个职业的能力结果，可以这么来理解，就干这些事。15年前的测试工程师8000块钱，你现在不都两三万吗，深圳差不多，凭啥，除了货币贬值也不至于这个程度，因为你的能力在放大，所以你的职责也在偏大，你的权利也在变大。

在京东我们如何实现这些附加内容的呢？也是通过平台，需求分析线上化，异常事件管理，生产缺陷分析，生产监控分析，基本上通过这四样。

需求分析线上化给大家讲一下。什么意思？其实就是因为互联网形态下开发人员、产品经理与测试人员对需求的评审是模模糊糊，一个说不清道不明的事。产品经理在那讲，开发测试听，你可以记一下笔记，也可以玩手机，也可以跟你的女朋友或者别人的老婆在聊天，完全没关系，因为没证据，谁说了啥根据记不住，它最大的问题就是要做一个，把三个角色拉到一个平面开展工作，对需求的分析一定要讲清楚，该哪些，变化哪些，影响哪些，它的核心你开发人员在编码之前就把软件所涉及到的质量风险、边界全谈清楚，所以我需要一个载体，这个载体不是一个文档，而是一个平台的操作流程。所以这个东西我们已经率先，我认为是突破，因为绝大多数公司还很难想到把需求这件事情，跟测试不是你的首要职责的东西给它平台化。所以这是我所面临的痛点。

第二设计目标，让需求评审的工作线上化，是产品开发的三个角色，对需求所涉及到技术变更通过特定的因子进行封装，使分析流程具有指导性，让分析操作变得简单易用。通过开发的技术分析，形成测试范围、工作估算、质量风险预测，减少开发提测后由于需求理解层面造成的BUD。因为这东西还是来源于你对Bug的分析，你们公司一个版本两个星期一个月改动了10万行代码，引起了5000个Bug，你要分析这5000个Bug，难道只是看数据吗？这太传统了，没有意义的，一定要看这些Bug怎么产生的？因为哪些环节不到位产生的，一些是由于开发人员能力不够造成的，这是技术因素，技术以外的因素就是过程因素，频繁变更，开发跟产品偷偷改了不告诉测试，这种破事经常发生吧？你给予你这些权利怎么把这些事情做好，通过平台化把它展示出来，把你的系统拆到每一个最小的因子，改到什么地方就全算出来，改到每个点需要多少种测试方法，都是可以通过平台去做一些智能的推测的。只不过现在还不准，我们现在也在孵化，在等一两年应该会相当成熟了。

它的设计逻辑基于公司的基础形态设计，我们设计9类因子源，根据特定业务来设计300多个因子。现在应该有400多了。它的操作形式就像一个调查问卷一样，非常的简单，简单易用。这个不给大家多说了。

下一个是生产缺陷分析。这是我的一个给大家的引导，因为经常面试人经常会问，你们公司测试人员怎么对线上的Bug分析的，最后分析是不是漏测怎么样，我说这远远不够，早就有了，只不过今天给大家展示一下，如果你做测试经理、高级经理，想一想，大家可以参考。对生产的Bug一定要追根溯源，从这些角度分析，出现的类型是哪一种，归属，哪一个功能点，对公司有没有资金损失，有没有特定的需求产生，用例是否进行覆盖，当你查看测试报告的测试结果，谁在哪年哪月几时几秒有没有真的运行过它，这些东西都要追根溯源，通过监控是不是可以发现，你就可以进一步来指导你的监控体系能不能增强，漏测只是其中一点，能不能提炼一些通用的回归用例，这才是测试带头人测试经理需要考虑的，不然你跟老板怎么说？上个季度漏测率高了，这个极度漏测率低了，那是一定的，可能是偶然因素，你只有通过这些角度层层分析才能真正去推进你们公司的质量体系改进了。

这是基于我们这个平台下的组织绩效，上午腾讯那个老师不也讲过吗？他们也是工程师平台化构建出工程师的能力画像，通过公司的职业晋升通道起到促进引导的作用，一样是的，京东这边之所以测试平台运转得比较良好，除了测试好以外，还要时时好，团队不认怎么办，团队认与不认怎么去处理他，所以一定要结合绩效导向。我们这边绩效导向就是三个维度，要求好、快、持续，即使我100多人全走光了，我再新招100多人不会差太多，这是平台要发挥出来的东西。所以好就对应着质量，效率就对应着快，规范就对应着持续，只有大家都在统一的工作范式下开展工作，这个东西才能持续，生生不息。

刚才是一个引导，究竟我们是怎么定的呢？这也是我定的，其实就这几个维度，这些东西都是我们真真正正绩效考核的东西。上面每个指标的结果都来自于平台，你站在一个测试经理的角度如何定义团队的绩效，基本上漏测率一定会有的，策略型的，需求的单位吞吐率，平均测试自动化执行率，回归测试效率，平均测试障碍率，过程管理规范度。当然你说京东的绩效好复杂，因为这个指标都可以拆成更小的。我们也是侧重性的，比如这个季度侧重这块，那个季度侧重这个事，你要有所倾向，但最终是围绕着什么？围绕着整个团队能力的提升，结合平台只是一个载体，通过平台把你们这个测试团队的能力无限放大，我真没时间去解释了，其实还有很多算法，只能给大家这么看一下，因为时间已经到了。

4. 开启新时代

最后一页开启新时代，这个不是一个虚的，也是我们这边现在在孵化的东西，给大家讲一些未来的测试场景。既然是这种行业峰会，给大家一定要讲一些未来的东西。全透明测试，上午我老板也说了，我们现在在孵化一个什么东西呢？尤其我们这边移动端为主，测试人员在左侧这个窗口操作手机，当然手机可能是虚拟的，因为是在云上拉过来，这个界面是假的，是云化的。右上角有一个小窗口可以动态时时展示测试覆盖率，能理解吧，测试工作全透明化，就像去医院做CT一样，做测试从UI层，扫描一下，骨骼这些东西都出来了。下一步可以做回归测试范围的智能分析。第二是多元化云端工具箱，我这些东西都是结合着DevOps体系的一部分，未来的多元化测试工具箱现在也渐渐在成型，它是一种测试的辅助平台，测试人员需要的一些数据、一些权限，这些基础的小东西要高度地，就像你可以想象，我点一个按钮，我想要一个东西，通过意识流就可以获取下来，满足你测试的前置条件，还是要触发的，这个东西也是未来的一个趋势。

第三个是基于预测的质量评估，在需求分析阶段就可以分析出你这个需求会花多长时间，有什么潜在的风险，这只是其中的一个场景，还会有很多其他的场景。

讲得很紧张，因为咱们时间控制要比较高一点。给大家讲得不多，谢谢大家。
大家有什么想交流的吗？好像有交流环节吧，两个问题。没有咱们线下聊也是，还是想跟大家分享一下我们是怎么干的，现在一定要讲一些实战式的东西，包括我们招聘包括大家求职也一样是的，各个公司都要面临着测试平台，质量管理平台，所以这个话题对大家还是有些借鉴性的。你是测试架构师怎么建平台，考虑哪些要素，甚至有些设计思想直接套就行了。没有问题就下一个。下一个是我的老师齐志宏，她是我们京东中台，我们的一个技术总监，给大家讲一讲开发的资助平台一些建设的过程。大家欢迎。