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

作者 | 朱姗
编辑 | 济萌

作者简介
朱姗
英国理学硕士，从事测试开发行业多年。

2012年开始独立和美国方面合作负责E2E财务系统，工业监控系统、生物医疗工具系统等多个项目的测试，贯彻执行敏捷研发测试流程,经历过大型软件的研发工作，对软件研发有丰富的经验，同时具备互联网软件测试框架研发和方案整合能力，对软件质量保障全局有体系化的思考和经验。能够面对复杂情形构建体系化的质量控制策略，并具备良好的落地实践。测试心得经验受到国内多家银行，证券，互联网公司的喜爱和推崇。

序言

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

本文的六个部分：

1. 什么是 DevOps 测试?

2. 如何适应 DevOps 的组织和文化;

3. 一个关于测试的故事;

4. 测试金字塔;

5. 建设可靠可重复的交付流水线;

6. 数字驱动改进。

1、什么是DevOps测试?

什么是 DevOps 测试呢？和传统测试相比，DevOps测试对测试人员可能会有更高的要求，对业务的掌握和研发技术的深入了解，以及如何快速融入到业务的的可持续发展，整个业务的价值生态和发展趋势也要有全局的理解。

1.1.聚焦DevOps测试

第一，聚焦业务的价值。这个听上去有一点学院派。一般人理解软件测试是一种实际输出与预期输出之间的审核或者比较过程,测试人员主要目的就是找bug,如果有bug就是测试者的工作业绩。

自从接触DevOps测试以来，我们发现测试不仅仅是研发代码写完了提交给测试进行验证，以及回归bug就终止了。

Devops测试推崇的是让测试者可以站在更高的角度，即：业务的价值去审视和优化自己的工作。谈到业务的价值，耳熟能详的就是体现在投资回报率。

有人说测试是非增值的部分（属于成本部分），其实测试其实完全可以是一个增值的部分。因为，作为测试人员肯定希望工资待遇不断提高，职业发展更加良好。

但是，得到这一切的前提是我们最终输出的产品得到用户认可和推荐，打造最佳的用户体验，让每一个功能都顺着用户的场景走顺；

我们的产品提供用户需要的服务；为客户带来了价值；然后我们自然会得到更多的收益。

每个细小的功能都是一个小分子，只有每个小分子都是良好的细胞组成，而没有恶性肿瘤细胞，我们的大分子产品才会健康的发展起来。

第二，DevOps测试是在流水线的任何阶段。这个任何阶段是指什么呢？所谓流水线大家都知道；

举个例子：我们平时在餐厅里面吃饭，一道菜要经过很多的工序才能呈现到我们的桌面上，可能先从原材料的采购，到厨师切菜、做菜烹饪、传菜，最后到服务员将菜端到我们面前，这其实就属于一个流水线。并且，这条流水线是可重复执行的。

在日常工作时，产品负责人会维护一个按优先级排序的“产品待开发项”（Product Backlog），即从客户价值理解和描述的产品功能条目，在每次迭代的第一天，召开Sprint Planning Meeting，产品负责人会逐一挑选最高优先级的部分进行讲解。

团队可就需求细节、完成标准等进行询问，并逐条估算，放入本次迭代的开发任务中，直至 任务量饱和。

对于优秀的测试人员来说从Product Backlog就可以参与其中；也就是从最开始产品的需求产生，然后到每个迭代需求评审、分析、研发、设计、代码实现，再到测试的集成环境，我们的灰度环境、UAT环境，到最后的生产环境。

整个所有的链路环节我们都应该会参与，这也是测试人员主人翁意识和责任心的体现。

自动化测试其实不是一个新的词汇，也并非是一钟高大上的技术。只是相对于目前大部分测试人员由于受限于代码技术水平，所以自动化测试的推动较弱。

闻道有先后，术业有专攻，我们做手工测试的人员一定要渗透我们的功能业务，举例子：在需求评审期，可以挖掘需求文档的bug提醒产品经理进行优化 。

假设测试人员执行测试过程中发现，当想要配置一个活动露出的时间为明天上午11点，由于系统设计存在缺陷，配置活动的动作必须要提前1个小时以上完成系统才能在11点整正常露出，如果测试人员能及时提醒运营人员的工作，那么一定会在降低客诉率上起到一定作用为客户提供更好的客户体验。

对于自动化测试工程师，可以挖掘那一部分在某一段较长周期内，可预见的能明确输出预期值的功能进行分层提取自动化起来，从而达到提高测试效率的目的。

最后，一个是快速的反馈。因为在传统的项目中，测试会有一个集中的时间和测试点；就是等研发代码码完之后，再给测试提测。

这个时候需要准备测试的环境，准备测试的数据，还有测试的案例。在整个软件开发周期中，有一个固定的时间是专署我们测试的环节，只有等完全确认好每一个流程之后才会生成测试报告。

其实，DevOps测试更多提倡的是一种快速的反馈。就好比现在很多创业公司，第一步就是要抓住市场，抢占市场先机。

快速反馈也代表着快速告知团队我们的质量，大家最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

1.2.DevOps中沉默的脊柱

对于DevOps测试，我个人认为是沉默的脊柱。

因为，很多的讲座和视频以及跟IT行业很多专家请教交流，大家提到DevOps是Development+Operations，从字面意义上来说是开发和运维。

但是，测试在这中间也是必不可少的一环。并非我们用代码进行测试自动化之后测试人员就会被消灭掉，Devops价值文化中更多体现的是测试人员融入这个生态，使用自动化辅助提高我们的测试效率，同时对测试人员的技术和业务大局观有了更高的要求。

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

1.3.DevOps给测试带来的好处

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

2、如何适应DevOps的组织和文化

我们如何适应DevOps的组织和文化？大家在了解DevOps的时候，焦点都在研发和运维互相协作，以及打破壁垒和创造价值上。

其实，我们的测试也是要打破部门壁垒，早参与、多参与，而且多分享、信任，并且有主人翁的精神。测试人员要清楚自身的价值地位，我们是研发和业务之间最重要的桥梁！

我们怎么样去适应devops组织和文化呢？首先，我们需要运用创新工具来改变做事的思维和协作的方式。

对于冗余的、笨重的、低效率的沟通或者协作都要消除。同时，我们要拥抱变化，积极响应团队的目标；不要觉得测试工具的改变会给自己带来很多的挑战从而感到害怕和没有信心。而是，应该有一颗拥抱变化的心态，积极的参与，并且持续的改进。

3、一个关于测试的故事

3.1.测试的故事以及剖析

首先，分享是一个关于测试的故事。我跟很多做测试的同行有交流，所以这个故事并不是发生在某一个特定的人身上；而是我们大部分测试人员都会有这样的困惑。

最近我朋友圈里最流行一个图，就是我是谁的小程序截图。我们是测试或者开发怎么样，有一些调侃和吐槽。看到很多测试从业者吐出了很多苦水和不易。

现在是互联网时代。很多的系统不是纯粹的单体式架构（创建一个完美的产品去附和整个市场），而是多方协调；即:这个系统只是公司内部一些API之间的调动不够，还要去调第三方的API接口。

比如:有一个网站是卖食品，全中国有那么多种类的食品，我们不可能创建一个工厂去生产所有种类的食品；而是，通过和不同的大型现货供应商合作进行快速的批量对接。

我们在测试的过程中，很多时候都停留在一种等待的状态。比如：测试卖食品的网站需要等待商户提供可用可测的接口，然后才开始跑测试。这个时候测试处于一种被动等待的尴尬处境。

另外，测试人员的流动。因为无论什么原因，比如：有更高的薪水、有更广阔的平台、学到更多的技术，或者搬到另外一个城市去生活都会影响人员的流动。

还有就是进来测试新人，有流动必然有新人进来，这些都会给我们测试流程带来整体效率产出的降低。因为，新人进来需要熟悉业务和工具。

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

其次，很多公司在招聘的时会写上要求，比如：会哪些技术，要求有丰富的工作经验。

但是，在招进来之后，会发现对于做手工测试的人员学习自动化的成本非常高。同时，新进测试人员在团队里面的存在感较弱。

那么以上问题产生的原因是什么？因为，目前中国大部分企业都开始采用敏捷研发流程。

就是小步快跑，每一个迭代可能两到三周。而每个迭代发版为了不影响线上用户的使用都会选择在半夜进行。

高频率的半夜发版会增大团队的内耗，大家容易产生疲倦的心态，这样其实对产品的质量埋下了地雷。

再则，就是测试环境资源特别紧张，我相信这也是大多数公司都会存在的问题。当系统比较复杂的时候，我们需要不同的机器类型，比如：做兼容性的测试时，把测试的系统部署在多台服务器上。

如果有集群涉及的机器更多，那么这个时候测试的环境，比如：UAT和预发布测试环境，我们都按照生产上的配比去配置，准备许多不同的测试机器。从公司的角度来说，这个投入有点偏大。

接下来，是产品在上线前会经过一些测试。比如：我们是三周的测试和研发，前两周是研发，第三周是测试。

有时候我们发现第三周可能在周一的时候还是不能测。为什么？

因为，我们一直在等，等测试环境，等运维部署好测试环境，等开发说代码全部码好（这个时候提测可能延期）。这种被动的等待使得测试团队的效率和士气受损。

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

无论是传统的瀑布，还是现在流行的敏捷，都会有工作进度排期。我们可以把最开始的计划（就是给测试排任务的时间表）和在执行测试整个过程中的时间表进行对比。

从而分析初期人力估算、时间估算和实际情况有哪些差异，差异的点在哪些模块哪个环节。这个时候发现测试的困境是等待，阻塞、浪费和瓶颈以及消极情绪。

3.2.方案

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

3.3.以微见著 Start Small

Start small，这个词从字面意义上来说就是从小做起。什么是从小做起？比说：我喜欢喝咖啡，可以直接去星巴克买一杯咖啡，也可以自己动手做一杯咖啡；

如果我想花费更少的成本去获得一杯我想要喝的咖啡，那肯定是自己动手丰衣足食，这样的成本会最低。

那么，星巴克和这杯咖啡有什么联系？因为，我们自己冲泡一杯好的咖啡会从自己买豆子，再到研磨、萃取和冲泡。

这个流程每一个小环节其实都是一小步，我们不可能一下子把豆子做成咖啡，而是每一个环节都要一步一步来完成。

有朋友和我说DevOps其实大部分在忽悠洗脑，还有朋友跟我说，DevOps测试要那么人一起协同工作，然而我们团队里的人并不喜欢改变已有的的一些习惯；

而且假设我们是乙方，我们的甲方也不愿意配合我们做一些相应的协调。这样导致推动积极性大大降低。

其实我想说不要太焦虑，就是不要担心我们无法控制的事情，我们为什么管一些不可控制的事情呢？我们不要害怕改变，因为想看到成果肯定需要改变的。

但是也不要一下子将所有的东西都进行改变，我们可以慢慢的来，水滴石穿，用可量化的指标去呈现给你的老板看。

同时在这里还要提到使用精益的方法。关于精益的方法，大家或许有一定的了解了；它是丰田推崇的理念：杜绝浪费，提高效率。还有就是找到一个愿意合作的伙伴，互相督促，互相鼓励和互相进步。

另外一个值得关注的点是我们要梳理好基线，方便我们后期做出变革后进行前后对比，这样才好度量进步了多少。最后是改进一个测试的流程，并且分享和影响他人。

使用现在拥有的手段，换句话说：自动化测试不是一个新的技术，而且我们也不要急于自动化，错误的自动化将造成技术债。

就像买车买房一样，你背了债，你要偿还利息就会越来越多。我们应该是梳理自己公司目前团队所拥有的，并且已经熟悉的工具。

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

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

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

最后是UI的测试框架。这里只是简单提供给大家参考，分为用例层、提取层和工具层。为什么会有这么一个框架的存在？

如果简单的用目前市面上开源的selenium直接使用，团队协作实现维护成本较高。

所以我们要花更多的时间去看自己的程序和框架，建立一个可靠的稳定的测试框架是很有必要的。

4、测试金字塔

上图是我们的分层测试。Google测试之道里面有提到：有一个比例是单元测试、接口测试，还有UI的测试是7：2：1。

但是，真正的执行测试过程中我们应该因地制宜。因为这个比例并不是固定的，而是要根据自己项目的特点来找到最合适的比例配置。

如果就你一个人在做测试，你会要求自己把所有的单元测试都做到70%吗？那其实是不现实的，我们应该要考虑当前实际的情况。

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

5、建设可靠可重复的交付流水线

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

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

举个例子，比如探索性测试，如果连人类自己都不知道预期的结果是什么样的，难道人工智能就会知道吗？目前来看人工智能的博弈还在持续发展中。

在做完日常测试后，我们会做集成测试、拉出分支和准入测试。准入测试是什么呢？

就是在做大规模测试的时候并不是说开发、运维准备了一个环境就会测试了，而是有一系列的脚本来判断是不是可以进行大规模的深入测试。

接着上灰度测试，也就是部分生产流量流入。

最后上生产：生产有一个监控和报警。为什么要有监控和报警呢？不是说我们测完了就上线了，并在线上走一轮冒烟就完事了。

因为有一些BUG隐藏得很深，并非上了线点一轮就OK了，没有BUG了。在达到某些特殊的情况才爆发出来，这个时候对用户会产生一些负面的影响，所以我们就需要有监控，如果有异常的行为都要快速的响应。

搭建测试服务平台从三个方面来做：

1. 测试数据服务；

2. 一个是Mock；

3. 一个是日志搜索引擎。

测试数据服务是可以写代码、调用一些结果或者从线上引流过来。Mock就相当于打桩，演电影有一些替身，这个就是替身。

Mock Server，我们可以进行第二次的开发，效果是降低耦合。日志搜索引擎，我们在发现BUG的时候，要先自己过一遍这个到底是不是一个BUG（有可能它是个伪BUG），所以我们要借助强大的日志。

这里提到的是ELK，这个也是开源的，我们测试人员自己可以搭建一套，或者和运维研发人员协商一起搭建。

6、数字驱动改进

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

那么，这个时候如果你采用自动化测试，并且快速的量化测试结果，其实可以达到秒级响应。这里的例子是把测试结果推送给微信。上面显示的是凌晨两三点执行的测试结果。

当测试环境在云上或者假设部署在云上，以及当云平台做一些迁移的时候，也许不需要让整个测试团队在深更半夜都留下来值班。

而是可以通过自动化的测试流程来快速的得到响应，知道测试的状态和进度，然后反馈给研发团队和领导。

最后一句话：优秀的测试人员其实是拥有CEO的思维，去推动研发流程标准化建立的重要角色，因为测试是研发和产品的桥梁，做测试的你更了解一线研发和产品的情况，需要内心笃定去推动流程落地和优化，哪怕过程中会遇到困难，但是坚持做为客户为团队带来更大价值的事情是意义深远的。

---

研发运营一体化（DevOps）能力成熟度模型 第3部分：持续交付评估现在可以报名了！

猜猜您的企业在持续交付可以评几级？欢迎各大企业来电咨询评估报名

评估请咨询：牛晓玲
联系方式：010-62300559
邮箱：niuxiaoling@caict.ac.cn

培训请咨询：
杨文惠
联系方式：13021086339
邮箱：yangwenhui@greatops.net

研发运营一体化能力成熟度模型视频介绍▽