DevOps下的质保测试方法

毕宏飞

作者简介

董申曦
作为课程专业讲师和世界质量报告中国区撰稿人，多年从事于TMAP测试方法论和TPI框架的理论研究，积极探索TMAP测试方法论如何与企业的实际开发运维质量保证和测试体系（如Agile, DevOps）相结合，深入研究世界五百强企业在质量控制方面的最佳实践，致力于为现代企业提供专业测试及质量体系咨询服务和基于最佳实践的独立卓越测试中心建设工作，有丰富的跨国公司和本土公司卓越测试中心（TCOE）的实施经验。并积极推动中国本土的企业的测试实践及提供各类落地测试解决方案，包括基于云的测试服务(Taas)，移动测试框架（Mobile Testing Framework），以及各类自动化，性能测试，安全测试等。

前言

先自我介绍一下吧，我叫董申曦，大概在2014年的全球最佳实践联盟上我做过一个大概30分钟的演讲，是关于 DevOps 这个理论的，实际上是一个测试检验标准。这次很有幸，老萧、汪珺邀请我做一个 DevOps 测试的专场，我们以 DevOps 为主，今天借这个平台给大家聊一下作为一个咨询公司，从咨询方这个视角，所看到企业在 DevOps 的变革，在这个变革当中，我们关于测试的变化。有多少同事听说过世界质量报告？它里面有包含很多当前的一些趋势，投资的趋势、技术的趋势不同的地域的趋势。

不管是做日常测试工作的、经理、运维，还是CXO，从今天的演讲主题里都能够拿到你要的东西。首先我们会讲 DevOps 下测试面临的挑战，在我们的视角，作为凯捷持续的质保方案。同时如果你已经很好的应用了，他带来的最佳实践是什么？基于测试的视角，在大企业当中，或者在一些传统型企业当中，它的变革是怎么发生的？最后就是最终的一个质量观点，在 DevOps 大环境底下，我们测试关键的点是什么，他的KPI有哪些？

一、Client Challenges 面临的挑战

二、DevOps QA/Test Solution 质保测试方案

三、Business Benefits 业务效益

四、Case Story 参考案例

五、Point of View 质量观点

六、Solution Detail 方案细节

一、Client Challenges 面临的挑战

有挑战我们才有动力，才会解决问题。当你的运算负责人、老板、CXO要预算的时候，在敏捷大环境底下为什么他们愿意投？

比如说软件故障，能够更快反映真实的需求，让需求更快上线。然后有一些高效快速的使用工具支持这个团队，这些都是我们在整个 DevOps 的环境底下追求的目标和解决的痛点，这个大家都是日常当中碰到的吧？

这些东西怎么转换成CXO想到的，怎么做 DevOps 的转型呢？我们从痛点出发，来讲这个问题会比较容易。昨天我们在晚宴的时候，和汇丰的人聊到怎么推动 DevOps ，怎么解决在现有的企业组织架构底下文化技术推动难的窘境？我们建议从咨询方的角度去说，汇丰两天无法访问账户，没有交易就没有收入，还有其他很多问题，这是都是软件故障。软件故障为什么发生？显然是没有被测试到，表面上的看到的问题还是说我们测试没有找到。

那么上图中这个数据65%，显示 DevOps 已经成为一个热点，既然要快速交付，快速交付意味着时间很短，在这样的情况下，你要做到高质量的测试和高质量的交付，这个本身就是一个冲突的事情，对不对？在这个情况下，软件故障是会增多的，在这些增多的软件故障背景下，我们可以讲好我们的故事，讲好我们解决这些软件故障带来的问题和钱。站在测试的角度，特别是测试力的角度，大家注意要有这样的思维，就是刚刚提到的一定要换成钱。老板听得懂钱，听不懂 DevOps ，是吧？然后呢，我们站在 DevOps 下测试的立场，为了客户和业务能够更快的交付高质量的软件，里面就要采用很多的原则，比如说很多测试前移、左移，尽早测试、最优测试、自动化测试，这是都是在场景下某一个专案的术语。所以整个 DevOps IT 的挑战，其实还是来自越来越多的迭代、周期越来越短，以至于造成我们在测试端有很重的压力。

二、DevOps QA/Test Solution 质保测试方案

接下来我们讲站在我们的视角，接触过大中小型企业的咨询商的一个视角，看到的质保方案。大家重点关注这个，就是站在咨询的角度，其实我们看测试是更广更宽的，宽度在哪里？ DevOps 的成熟度评估其实是个很重要的标准。凯捷咨询做评估的时候，有一个叫TPI，相当于成熟度模型。在这里我们有一个基于大部分客户里抽出来的模型，是评估你 DevOps 的成熟度的，其实归结下来，跟张乐老师谈到的道法术器是有关联的。是不是真的Dev和Ops连在一起的？所以类似的就是在质量咨询这里我们有成熟度模型，测试环境与服务虚拟化，还有测试数据的自动化。

我们有电信端的大客户，比较麻烦的是构建测试。测试数据准备通常要花上好几天，甚至一周的时间，为什么？就是因为数据库非常庞大，它所对接的相应的一些子系统很多，那么怎么做数据构建的自动化？我们谈更多的其实是UT的自动化，然后 SIT 的自动化，或者是配置环境管理的自动化。刚刚谈到的一些东西，我们数据怎么来自动化？然后一些质量监控，昨天不同的专场谈到很多质量标准点的监控，有服务器的性能，API的接口等。最后基于工具和解决方案，我们大概提出了资产库，包括 DevOps QA 过程的工具包，质量蓝图，主要是一系列真正做测试的方法论。举一个例子，如果有条件判断达成一个结果，我把所有的可能性全测完，就是把这个测试做好了？真不是，所以TDD的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。而BDD和TDD有什么差距？BDD先关注用户的场景，然后有一些智能化的集成框架，一些虚拟框架的东西。

下面这个图就是我们整个在凯捷的视角设计的东西，有成熟度评估模型，有整个的解决方案，有资产库。

三、Business Benefits 业务效益

讲了上面那些东西，我们就要讲怎么跟大老板汇报，拿到他们的支持。如何在大环境当中为你的测试团队拿到更重要的地位或者是更多的支持？

这个图是我们从 DevOps 相关测试的东西之后所看到的性能实际的东西，指你整个团队的表现，也就是绩效。我们总结出来一些成功杠杆，比如说精益方法，生命周期自动化等。最后有QE与 SDET 的方法，这个概念是微软一个很重要的概念。 SDET 做的事情更多是探索行测试，基于白盒的，基于你的代码做分析，然后来看哪些东西可以成功，哪些东西是大概率失败的。基于这些杠杆，我们从你的 DevOps 转型，从零到最后，从低级到高级，每个部分要做的分数。比如说精益方面，我们中级要到60分，你把所有时下最流行的这些开源工具连起来，看起来很好，但是活不好。对于这些比如说我们自动化的保障，API混合测试的部分，关注的第一个是精益方法。从小的开始不断试错，愿意做尝试，没有最优的，你尝试了以后，才知道适合不适合你。当你谈到每个领域和杠杆的时候，这些都会联系你的ROI，从这个角度入手可以真正的打动他们。

四、Case Story 参考案例

我们讲了一些挑战，看到了我们咨询对于 DevOps 测试一个视角的解读，然后对于一些收益和成果的一个展示。接下来结合两个案例，来给大家讲一下我们在过程当中看到的部分。

4.1 欧洲某大型邮政企业

这是欧洲一个大型邮政企业，整个的看到支撑86个应用程序，7M用户，200个接口，18个服务合作伙伴。这个实践最好的方法用BDD，实现在 DevOps 测试的驱动，在UK邮政里面，其实前端的自动化框架还是用了比较多的 Selenium 。开发与质量保证环境搭建时间从4天缩短到4个小时，环境故障停机从每月8小时减少到4小时。95%以上是一键完成配置，发布周期从三周缩短到一周。需求处理能力提升50%，开发成本降低30%。

Cucumber 是一个基于BDD的解释器，最大的作用是让你可以用相对通用的语言，然后写清楚你的测试场景，真正的代码。BDD更关注用户的场景和行为，更快梳理出来之后，怎么办？汪老师谈到，在 DevOps 测试人员的职责已经没有了，大家都在强调开发运维要合到一起，互相做一些事情，那测试到哪里去了？测试还有价值吗？我们现在所面临的很多的企业，开始走 DevOps ，这是一个方向，大家都认为这是对的方向，但是我那一群测试团队怎么办？是不是在你们企业当中，包括互联网企业也有同样的问题，我这些测试人怎么办？现在赶鸭子上架让他们做代码开发吗？你的团队能不能跟开发一起去解bug？BDD和TDD就是一条路，因为TDD到BDD你的测试人员是需要写代码的。Cherkin 是类似 Ruby 的代码语言，这个代码语言其实是能够帮你在什么时候，什么条件下能够拿到什么，我期待的结果是什么，是要变成代码的。所以测试人员一定比开发人员更了解场景，这个是测试人员的价值。PO就坐在我的团队里面，难道他不了解用户场景吗？难道他不了解用户需求吗？他了解，但是他知道怎么测试吗？在敏捷和 DevOps 转型的时候，测试人员最重要的就是在前期的需求分析会上能够提出接受标准。其实光提出接受标准是远远不够的，好的人员把好的用户行为场景代码化，然后才能够根据代码化转成要的用户案例。

4.2 某欧洲银行的DevOps转型

就是欧洲某一个大银行的 DevOps 转型，这个相对比较传统一点。从瀑布方法到敏捷到 DevOps 整个一体化的转型，这里面最多的是自动化测试的实施，这个本质是从整个组织架构，从 waterfall 走过来的大的转型。

我们可以看一下这个实现是什么样的：

第一阶段是 waterfall ，开始用SVN，git管理代码库，同时开始使用 jenkins ，目标是提高这个测试自动化率。到开发代言测试、系统测试到集成测试、用户测试和生产间测试，到最后的QA抽测、上线。一开始做的CI，远远做不到CD，所以一个环境团队是指什么？就是这个组织架构它非常关注的就是我的测试，有很多环境，有系统环境，有系统集成环境，关注的就是用了一些工具然后让这些环境可以打通，就是你不需要说我开发测试环境你测QA，或者是UAT在用户环境里测，配置也比较快，用的就是 Puppet 和 Chef。企业中两种都用的其实很多，特别是对于传统的大型企业，银行，电信类的，或者是石油电力的这些IT人员， Puppet 和 Chef 其实是可以共存的。

第二阶段尽可能多的做并行开发测试，从一个单独的大瀑布转成很多小瀑布，就是能够去并行开发的都去并行开发了，这里有一个关键点就是并行开发的时候，做完在UT下一步的系统测试，因为系统测试比较复杂，做完系统测试以后，代码要提交的，并不是说要等到后面SIT结束才提交。所以这个时间段我们引入一个大的工具叫 CA Lisa 它是做服务虚拟化，其实有点微服务的概念在里面，但那个时间不是微服务，其实是打包了比较大的服务化的东西，用的是服务虚拟化的概念。我们来做了转型以后，把每一个单独的 Scrum 团队交付的东西，服务虚拟化，就是可以随时的上线和停线。

转型成功，变成了这样的一个团队的架构，从 desired 到开发单元测试。

整个一开始我们做这个 Sprint
Planning ，大概会做3个到5个 Sprint
Planning 。中间从代码提交变成 Snapshot ， Snapshot 还是基于服务虚拟化的概念，他们现在正在尝试用 docker ，用 docker 把这些服务，或者是一些单独的可执行的包，变成镜像仓库，联合在os的 docker 里面。做了一些 Snapshot ，Snapshot 有几个概念，在不同的模块之间，当前跑的是哪一个，可以非常容易的连调，很容易的去透过代码或者叫脚本的方式来控制，代码注册以后了以后做大规模的连调，做PVT的测试，然后SEC。现在整个团队还在持续的迭代更新当中，他们更关心的是两个部分：一个是刚刚讲的，我们怎么用 docker ，让这个镜像环境部署上线；还有一个就是这边的SEC
这块，不仅仅是SEC的测试，性能怎么样去迭代，是这个组织架构正在做的事情。所以整个来讲，包含PCF做持续交付，到这个阶段已经做到持续交付了，我能够有很好的上线，自动化测试，有相应的UT，基本上80%的都是自动化，可以持续的测试然后交付，同时会比较容易管理镜像仓库。

五、Point of View 质量观点

接下来总结一下，基于这两个案例我们所看到的一些状况，站在凯捷的角度我们对 DevOps 的总结。这个总结我们认为可以叫做关键点，这个关键点大概分七个板块。

• DevOps综合质量方法
• DevOps质量工程团队
• 行为、测试驱动开发
• 持续化、自动化测试
• 环境虚拟化、数据自动化
• DevOps质量度量模型
• 持续质量监控

DevOps 一定要指导方法，这就是我们为什么会有 DevOps Days 。你必须要有一个综合的方法，这个方法是什么就不展开讲了，其次是 DevOps 的质量工程团队，显然你的工程师、测试工程师，特别是测试工程师在 DevOps 的环境下怎么生存？大家会在网上看到架构师的技能术，有没有一个在 DevOps 环境下的技能术？行为驱动、测试驱动，这个是一定要做到的，你这个做不到你连敏捷都做不到，还有零介入的持续自动化测试，环境的虚拟化、数据的自动化，怎么做到数据自动化， docker 是一个方向，整个业界对于数据自动化有一个非常多的探讨，没有所谓的方法论指导这个东西。怎么样节省数据准备的时间和复杂性，特别是大的企业级的应用里面，这是很大的课题。 DevOps 有一个所谓的度量模型，就是到底怎么样我的 DevOps 才能做得好，对于管理层也好，或者测试团队的测试经理来讲，怎么样才能认为我这个团队已经符合了 DevOps 的能力需求了，它能够真正的持续交付、持续集成、持续测试。

六、Solution Detail 方案细节

6.1 综合质量方法

对于综合质量方法，还是以持续集成、持续部署、持续测试、持续质量监控为主。

右边的话是一些 HP CODAR ，都是跟安全性代码扫描有关系的，底下是自动化测试方案、验收，作为BDD来写应用测试的场景，在需求定下来的时候，这些场景就要出来，还有一些服务虚拟化的一些东西。

6.2 质量保证流程

整个测试流程就不一个个详细过了，我们大概分几个层次，整个的SDRC开发的流程如下，底下是基于环境的配置。

我们除了测试还有QA角度，所有测试工程师基本上不会设单独的QA，如果设也是大的团队底下额外抽离一个单独的QA准入准出。每一个测试工程师都要有QA的视角，这个就是BDD，BDD阐述的就是基于代码用户场景的描述，在编译的时候会产生相应的框架，这个框架的输入，简单来讲就是它会产生一些文件，然后会输入到你的UT测试用例。

从客户需求开始一起讨论细化，定义这个业务场景叫何物、何时、后续这些关键字，依据场景开发进行自动化测试，在这个时间段的时候，自动化测试脚本才能出来。如果这个定义不详细，在测试脚本的时候可能比较麻烦，你维护的时候会频繁的更改。开始测试，到最后有些反馈文档。

6.3 自动化核心工具

上面是我们流水线用到的工具，常用的工具和一些核心管理、持续集成、各种测试，测试数据的管理还有一些预测分析，这些东西都做到的情况下或者是大部分都做到。比如说从中级到高级各个演进当中，如果有50%以上，还是有根据的，至少可以尝试总结一部分，可能会作为一些缺陷自动修复，或者是预测。

6.4 环境与虚拟化

我们环境与数据虚拟化，这是我重点强调的部分。今天你光有一条好的流水线，把好的规则集成进去，只能说在组织在流程上的，但是能不能加快整个开发运营的效率？其实好的基础设施，好的服务虚拟化，好的测试虚拟化都是比较重要的。

在上面的图，我们列了一些比较常用的工具，或者是能够帮助你做好集成测试，帮助你做好虚拟化测试的部分。当你做系统集成测试的时候，你的相对应依赖还没有准备，可以用服务虚拟化的方法模拟化，这个是做 DevOps 持续演进重要的一个环节。

6.5 质量指标

最后就是我们讲一下 DevOps 的一些指标，我们分为四个纬度。

从迭代的角度来看，迭代效率，测试执行生产率、速度；从参与度度量，工作差异、计划差异，承诺可能性，我今天做的和实际交付的中间的各种差异，是我们要去追踪的，还有我的承诺的可靠性，为什么要验证这个？从敏捷到整体的转型当中，其实是建立小团队之间互信的，这个互信就是承诺可靠性。从绩效的考量建立互信，只有在互信的基础下，你的团队才有战斗力，才能变成一个特种部队。发布可测试性的度量，其实缺陷是有一个很好的KPI的，每一个缺陷发现，你要花多少钱？这个是可以去度量出来的，如果你能够有这样一个指标度量出来，那今天发现的十个缺陷，你就可以直白的告诉老板你花了多少钱。在这个迭代内，第一部分测试的东西，漏掉的生产环境，要花多少钱去修复它。然后每一个版本交付的特性，底下这些看板，最终还是要反映到监控的实时看板上面，这是我们认为比较有意义和价值的KPI。