DevOps测试在企业中如何落地？

于济萌

作者 | 朱姗
编辑 | 济萌

作者简介

jusa

英国埃塞克斯大学理学硕士，从事测试开发行业多年。经历过大型软件的研发工作，对软件研发有丰富的经验，同时具备互联网软件测试框架研发和方案整合能力，对软件质量保障有体系化的思考和经验。能够面对复杂情形构建体系化的质量控制策略，并具备良好的落地实践。

序言

互联网时代，企业越来越注重产品的快速迭代与交付，当然产品质量也是举足轻重。企业在有限的资源情况下，快速的步调意味着更多的挑战，本次演讲重点在于测试人员如何无缝连接客诉，运营，产品，研发，运维以及高效快速搭建DevOps测试体系从而保证产品快速交付的质量。

本文的六个部分：

1. 什么是DevOps测试?
2. 如何适应DevOps的组织和文化;
3. 一个关于测试的故事;
4. 测试金字塔;
5. 建设可靠可重复的交付流水线;
6. 数字驱动改进。

(一)什么是DevOps测试?

什么是DevOps测试呢？其实和传统测试相比，DevOps测试对测试人员可能会有更高的要求，对业务的把控和研发技术的了解，还有对整个业务的发展和价值等都要有一定的理解。

1.1.聚焦DevOps测试

第一，聚焦业务的价值。这个听上去有一点学院派。但是，在普通人理解做测试的人就是研发开发而已；然后，我们点一点看一看有没有BUG。如果有BUG就是我们的工作成绩，当然我们也会开发并去改这个BUG的程序。

其实自从接触DevOps测试以来，我发现测试不仅仅是研发开发完了再测一测。就是说，如果有BUG求着开发改一下，然后我们再回归。实际上并不是这样的，我们可以站在更高的角度，即：业务的价值。谈到业务的价值，它就是大家经常听到有关投资回报率，即：我们投入的资本得到的效益的一个比例。

有人说测试是非增值的部分（属于成本部分），其实测试也可以是一个增值的部分。因为，作为测试人员肯定希望工资或者职位有所提升，也就是奖金可以发的更多。但是，前提是我们的团队、产品得到用户的喜欢；我们做出好的服务；我们带来了价值；然后我们才有更多的收益。换句话说，就是只有公司有更多的收益，我们才能得到更多的奖励。

第二，DevOps测试是在流水线的任何阶段。这个任何阶段是指什么呢？所谓流水线大家都知道；举个例子：我们平时在餐厅里面吃饭，一道菜要经过很多的工序才能摆在我们面前，可能先从原材料的采购，到厨师切菜、做菜烹饪、传菜，最后到服务员将菜端到我们面前，这其实就属于一个流水线。并且，这条流水线是可重复的。

在每一个阶段，测试人员都要参与其中的；也就是从最开始产品的需求，然后到研发、分析、设计、代码实现，再到测试的集成环境，我们的UAT环境、预发布、归度，到最后的上线。整个所有的环节我们都应该会参与，这也是我们测试需要全局把控的一个点。

是在我们这个领域，自动化其实不是一个新的词汇，也不是一个新鲜的技术或者是一个很高大上的东西。而是，我们在这些流水线上重复其每一个阶段。同时，我们能做自动化的部分就应该进行自动化，这样能够提高测试的效率。

最后，一个是快速的反馈。因为在传统的项目中，测试会有一个集中的时间和测试点；换种说法就是等全部研发完毕之后，再给我们提测。这个时候需要准备测试的环境，准备测试的数据，还有测试的案例。在整个软件开发周期中，某一个中间的部分是专署我们测试的环节，只有等中间的部分结束之后才会生成测试报告，同时反馈给对端。

其实，DevOps测试更多提倡的是一种快速的反馈。就好比现在很多公司有创业，第一步就是要抓住市场，抢占市场先机，同时快速反馈也代表着快速告知团队我们的质量。

1.2.DevOps中沉默的脊柱

对于DevOps测试，我个人认为是沉默的脊柱。因为，很多的讲座和视频以及跟IT行业很多朋友交流，大家都不断提到DevOps是Development+Operations，从字面意义上来说是开发和运维。但是，测试在这中间也是必不可少的一环。并非我们做了自动化之后测试就会被消灭掉，而是我们在DevOps整个生态中能够建立更多的威信和创造出更多的价值。

从图中，我们可以看到产品是从需求到研发的分析协作编码，到持续集成的测试，然后到持续的部署，接下来进行持续的监控，最后到持续的反馈和优化。这是一个闭环，而且是一个完整的生态，其中持续测试，就是我说的脊柱。

1.3.DevOps给测试带来的好处

DevOps给测试带来的好处有：
第一，测试环境虚拟化自动化部署。
第二，自动化构建变得简单。
第三，配置管理数据更新维护更便捷。
第四，提高测试效率。
这几个点会在之后进行详细叙述。

(二)如何适应DevOps的组织和文化

我们如何适应DevOps的组织和文化？大家在了解DevOps的时候，焦点都在研发和运维互相协作，以及打破壁垒和创造价值上。其中，我们的测试也是要打破部门壁垒，早参与、多参与，而且多分享、信任，并且有主人翁的精神。我们测试不是一个边缘化的地位，而是我们也可以成为软件生命周期中很重要的一环和一个角色。

我们怎么样去适应这个组织和文化呢？首先，我们需要运用创新工具来改变做事的思维和协作的方式。对于冗余的、笨重的、低效率的沟通或者协作都要消除。同时，我们要拥抱变化，积极响应团队的目标；不要觉得测试工具的改变会给自己带来很多的挑战从而感到害怕和没有信心。而是，应该有一颗拥抱变化的心态，积极的参与，并且持续的改进。

(三)一个关于测试的故事

3.1.测试的故事以及剖析

首先，分享是一个关于测试的故事。我跟很多做测试的同行有交流，所以这个故事并不是发生在某一个特定的人身上；而是我们大部分测试人员都会有这样的体会。最近我朋友圈里最流行一个图，就是我是谁的小程序截图。我们是测试或者开发怎么样，有一些调侃和吐槽。我们测试在工作中也会有很多吐槽，也不容易。

现在是互联网时代。很多的系统不仅仅是单体式架构（创建一个产品完成整个市场的响应和对接），而是要多方的协同工作；即:这个系统只是公司内部一些API之间的调动不够，还要去调其他公司的一些接口。比如:有一个网站是卖食品，全中国有那么多种类的食品，我们不可能创建一个工厂去生产所有种类的食品；而是，选着跟不同的供应商合作并对接。那么，这个时候就会产生第三方。

我们在测试的过程中，很多时候都停留在一种等待的状态。比如：测试卖食品的网站需要等待商户提供可用可测的接口，然后才能执行整个测试。这个时候我们就会受阻，我们心里面其实非常的纠结。

另外，是测试人员的流动。因为无论什么原因，比如：有更高的薪水、有更广阔的平台、学到更多的技术，或者搬到另外一个城市去生活。还有就是测试新人，有流动必然有新人进来。这些都会给我们做测试带来一些效率上的变动。因为，新的人进来要熟悉业务和工具。

同时，测试工程师的配比也不是测试团队可控的。现在，很多公司会考虑成本问题。所以，测试工程师的配比并不是按照国外所说的1：1、1：2的比例。我们可能达不到，因为需要降低成本，即：人员上投入的成本。

其次，很多公司在招聘的时会写上要求，比如：会哪些技术，要求有丰富的工作经验。但是，在招进来之后，会发现对于做手工测试的人员，却不会做自动化。同时，人员也会发现在团队里面的存在感非常弱，会没有参与感，会感觉人家是那么的高大上，我就只会手工的点一点，感觉这个团队也许有和没有我都差不多。

那么这是为什么呢？因为，大部分企业都开始采用敏捷的流程。就是一个个小的迭代，可能两到三周会发一次版。而发版为了不影响线上用户的使用，我们会选择在半夜进行发版，哪怕偶尔会出现停服的状态。但是，这个时候大家都处于非常疲倦的状态。记得有一次，我大概半夜两点半做测试，我就拿着APP在点，其实我点的是我们生产的，根本不是我们测试的，所以一直点没有发现问题。基于上述，半夜发版时人多少都有一些疲倦。这样导致可能有一些BUG很难去发现它。

再则，就是测试环境资源特别紧张，我相信这也是大多数公司都会存在的问题。当系统比较复杂的时候，我们需要不同的机器类型，比如：做兼容性的测试时，把测试的系统部署在多台服务器上。如果有集群涉及的机器更多，那么这个时候测试的环境，比如：UAT和预发布，我们都按照生产上的配比去搭配测试环境，准备许多不同的测试机器。从公司的角度来说，这个投入有点偏大。

接下来，是产品在上线前会经过一些测试。比如：我们是三周的测试和研发，前两周是研发，第三周是测试。有时候我们发现第三周可能在周一的时候还是不能测。为什么？因为，我们一直在等，等测试环境，等运维部署好测试环境，等开发说代码很好了。这种被动的等待使得测试团队的效率在外界看来怎么那么慢；而且，之前都给你们排好了，有一周的时间来测；但是到现在还没有动手。

还有，准备测试其耗时很长，尤其当我们进行一些跑批的测试。比如：同步大量的第三方货品信息到数据库里面，这时候会有大量的数据过来；如果进行测试准备，那么耗时会非常的长。

最后，无论是传统的瀑布，还是现在流行的敏捷，都会有一个排版，也就是工作的进度。我们可以把最开始的计划（就是给测试排任务的时间表）和在执行测试整个过程中的时间表进行对比。从而分析我初期人力估算、时间估算和实际情况有哪些差异，差异的点在哪些模块哪个环节。这个时候的焦点就在于我们一直在等待，阻塞、浪费和瓶颈，而且我们的士气也没有那么积极。这是为什么呢？因为，我们感觉自己为什么还不能测试？领导问你们测好了吗？可以上线了吗？我们说还在等，就显得我们有一点无奈和无助。

3.2.方案

通过实践，我们总结出来一个方案：
第一，管理层积极的支持，跨部门的协作。
第二，我们建设测试服务平台，搭建镜像管理平台。
第三，标准化分层测试，数字驱动改进，并且建设稳定可重复的流水线。

3.3.以微见著 Start Small

Start small，这个词从字面意义上来说就是从小做起。什么是从小做起？比说：我喜欢喝咖啡，可以直接去星巴克买一杯咖啡，也可以自己动手做一杯咖啡；如果我想花费更少的成本去获得一杯我想要喝的咖啡，那肯定是自己动手丰衣足食，这样的成本会最低。

那么，星巴克和这杯咖啡有什么联系？因为，我们自己冲泡咖啡会从自己买豆子，再到研磨、萃取和冲泡。这个流程每一个小环节其实都是一小步，我们不可能一下子把豆子做成咖啡，而是每一个环节都要一步一步来完成。

很多人跟我说DevOps测试就是一些忽悠人的东西和一些所谓的新技术，可是这不都是老技术和老概念吗？就换一个名词来忽悠我们，忽悠我们来买票，忽悠我们听一些讲座和培训，其实并非是这样的。还有朋友跟我说，DevOps测试要那么人一起协同工作，然而我们团队里的人并不喜欢改变我们的一些习惯；而且假设我们是乙方，我们的甲方也不愿意配合我们做一些相应的协调。这样导致我们不喜欢的东西太多了，然后不可控的东西也太多了。

其实我想说不要太焦虑，就是不要担心我们无法控制的事情，我们为什么管一些不可控制的事情呢？

再举个例子：我有一点微胖，我的先生常常跟我说，你这么胖为什么不去运动，为什么老是要吃冰淇凌，你可以控制饮食和积极锻炼吗？我当时的回答是没有时间。因为我每天要上班，而下了班还得去锻炼，那还要不要吃饭以及洗澡睡觉？

但是，当逛街看到漂亮的衣服，或者在路上看到那么多美女，这个时候我会想要减肥了。然后，我去咨询营养师和医师，发现了我的指标三高有一点偏高。营养师跟我说：让你一下子去改变，你可定接受不了。接下来，他给我的建议是慢慢来，怎么来呢？做一个替代方案，这样我的指标就慢慢的恢复正常了。

所以我们不要害怕改变，因为想看到成果肯定需要改变的。但是也不要一下子将所有的东西都进行改变，我们可以慢慢的来，水滴石穿，最后总能见到效果的。

同时在这里还要提到使用精益的方法。关于精益的方法，大家或许有一定的了解了；它就是丰田的理念：要杜绝浪费，要提高效率。还有就是找到一个愿意合作的伙伴，互相督促，互相鼓励和互相进步。另外一个点是我们要准备一个基线，方便我们做出改变要前后对比，这样才知道进步了多少。最后是改进一个测试的流程，并且分享。

3.4.运用已知的手段

使用现在拥有的手段，换句话说：自动化测试不是一个新的技术，而且我们也不要急于自动化，错误的自动化将造成技术债。就像买车买房一样，你背了债，你要偿还利息就会越来越多。我们应该是梳理自己公司目前团队所拥有的，并且已经熟悉的工具。

3.5.单元和接口测试以及UI自动化测试框架

接下来，我要讲一些知识。一个是单元测试，需要关注几个点：一个是检测函数返回值，检测函数抛出的异常。检测端口被调用的次数。

然后，是借口测试：检测数据类型、数据格式、业务逻辑。

最后是UI的测试框架。这里只是简单提供给大家参考，分为用例层、提取层和工具层。为什么会有这么一个框架的存在？如果简单的用目前市面上开源的直接使用，可能得到的结果并不是非常好。因为我们发现测试执行很不稳定。然后，我们要花更多的时间去看自己的程序和框架，所以建一个可靠稳定的测试框架是很有必要的。

(四)测试金字塔

老生常谈的测试金字塔，也就是所谓的分层测试。Google测试之道里面有提到：有一个比例是单元测试、接口测试，还有UI的测试是7：2：1。但是，我们应该从自身的情况来考虑我们的测试。因为这个比例并不是固定的，而是要根据自己项目的特点来调配这个比例。如果就你一个人在做测试，你会要求自己把所有的单元测试都做到70%吗？那其实是不现实的，我们应该要考虑当前实际的情况。

对于分层测试，这里列了为什么执行测试？由谁执行，以及测试的工具有哪些，还有频率，还有投资回报率，以及我个人的一些建议。。

(五)建设可靠可重复的交付流水线

上述所说的可靠可重复的交付流水线，其实就是长成上图这样子的。我们的研发在编码完成之后，要进行一个自测。在代码投入之后，我们要触发编译、扫描和测试。然后，单元测试会执行镜像。接着就是模块的测试和系统测试。

那么，下一步就是日常的测试。这里提到一个人工决策，为什么会有人工决策？因为，并非所有的测试都可以自动化完成的。

举个例子，比如探索性测试，如果连我自己都不知道预期的结果是什么样的，难道人工智能就会知道吗？目前来看人工智能至少是不知道的。

在做完日常测试后，我们会做集成测试、拉出分支和准入测试。准入测试是什么呢？就是在做大规模测试的时候并不是说开发、运维准备了一个环境就会测试了，而是有一系列的判断是不是可以进行大规模的测试。

然后上灰度：灰度目前采用的是DNS自定义的措施。

最后上生产：生产有一个监控和报警。为什么要有监控和报警呢？不是说我们测完了就上线了，并在线上走一轮就完事了。而是，有一些BUG隐藏得很深。因此，不是上了线点一轮就OK了，没有BUG了。还有就是自身的漏洞，在某个特定的点才爆发出来，这个时候对用户会产生一些负面的影响，所以我们就会有监控。其实我们的测试人员也要看监控，如果有异常的订单都要快速的响应。

搭建测试服务平台从三个方面来做：
1. 测试数据服务；
2. 一个是Mock；
3. 一个是日志搜索引擎。

测试数据服务是可以写代码、调用一些结果或者从线上引流过来。Mock就相当于打桩，演电影有一些替身，这个就是替身。Mock Server，我们可以进行第二次的开发，效果是降低耦合。日志搜索引擎，我们在发现BUG的时候，要先自己过一遍这个到底是不是一个BUG（有可能它是个伪BUG），所以我们要借助强大的日志。这里提到的是ELK，这个也是开源的，我们测试人员自己可以搭建一套，或者和运维研发人员协商一起搭建。

(六)数字驱动改

最后，我提到的是数字驱动改进。有些领导说你什么时候能给我答案，你的测试结果是怎么样的？你的状态是怎么样的？如果你回答是一天，有可能这个领导会说为什么还要一天？我晚上就要上线了，或者我要很快的知道目前这个产品质量的状态。

那么，这个时候如果你采用自动化测试，并且快速的量化测试结果，其实可以达到秒级、分级的响应。这里的例子是把测试结果推送给微信。上面显示的是凌晨两三点执行的测试结果。当测试环境在云上或者假设部署在云上，以及当云平台做一些迁移的时候，也许不需要让整个测试团队在深更半夜都留下来值班，而是可以通过自动化的测试流程来快速的得到响应，知道测试的状态和进度，然后反馈给研发团队和领导。