埃森哲顾宇：DevOps的交付质量从需求质量开始

2019年10月26日，第二届NCTS中国云测试行业峰会在京召开，此次峰会以“AI+未来”为主题，汇聚来自国内外测试领域的知名专家学者、领先企业决策者、高层技术管理者、媒体从业者等，共同探讨高端云测试技术，帮助测试从业者了解最前沿行业趋势，及最新的行业实践。

会上，埃森哲通信、媒体和高科技事业部咨询经理顾宇做《DevOps的交付质量从需求质量开始》主题演讲。顾宇介绍了企业DevOps转型的经验，并说道，“我不推荐企业在 DevOps 能力不足的情况下做微服务改造。微服务应当是 DevOps 成熟度高之后的必然结果。否则很多质量问题会大幅增加人力成本和时间成本。在质量标准较低的情况下，缩短发布周期，提升部署频率是没有意义的。”

以下为顾宇演讲实录：

大家下午好！做开发工程师的同学请举手，做测试的同学，有没有做运维的？在之前的大会上，我都发现没有运维的同学，DevOps有开发，有测试，有运维，但是运维的同学一般不会来。我今天做DevOps的交付质量从需求质量开始的主题演讲，我来自埃森哲咨询，我们面向高科技、互联网和传统的电信企业做DevOps方面的咨询。

我做DevOps的转型和咨询已经有五年的时间了，也参与制订过一些DevOps的标准并为企业做辅导。我曾经做过测试，做过开发，也做过运维，我在这讲DevOps，上一个讲师讲OverMind，我四年前也开发了一个开源工具，OverMind这个单词的意思是《星际争霸》的虫族的首脑——主宰。

我今天讲的内容有三点，先讲一下案例，在咨询公司的好处就是可以碰到不同的企业，不同的人，在案例中，我给不同企业做DevOps转型的时候，发现测试的同学对测试的很多概念的理解都是不一样的。然后再讲一下经常碰到的技术性问题，最后讲一下DevOps的质量观，最重要的是提升需求质量的实践。

先说案例，客户的领导对我说，产品刚刚完成微服务改造，需要做DevOps。其实DevOps是什么一点不重要，关键是DevOps能帮你解决什么问题。他们想解决的问题是发布，两个月发布一次版本，产品节奏是这样的：用两周时间做分析，两周时间做开发，两周时间做SIT，两周时间做UAT。一般来说都不会达到这样的情况。他们的需求分析到5周，开发到4周，给SIT留出充足的时间进行测试，最后UAT，用户验收的部门。这导致测试时Bug越来越多，因为UAT的时间不够，增加了4倍的人集中在一周里做UAT，天天要去解决一堆Bug，每次版本都是这样发布的。

我们发现，很多企业完成微服务改造之后，其测试成本都增加了。因为，从前是单体应用，后面改成分布式应用，需要测试的点多了，服务和服务之间各种功能测试和非功能性测试都要测试，特别是在SIT这部分，这部分增加成本会带来延缓交付周期的结果。我做微服务架构，也做DevOps架构转型，我不推荐企业在 DevOps 能力不足的情况下做微服务改造。微服务应当是 DevOps 成熟度高之后的必然结果。否则很多质量问题会大幅增加人力成本和时间成本。在质量标准较低的情况下，缩短发布周期，提升部署频率是没有意义的。

DevOps解决两个问题，第一是软件交付效率，另外是提升软件交付质量。质量和效率两个都想要，两个都重要。如何提升软件质量呢？是不是要增加测试人员和测试时间？增加质量就会增加测试的时间，导致更多频次的测试。那么在我们刚才的例子里，用了交付周期的70%来做测试，也增加人了，为什么Bug还是那么多？这是他们当时抛给我的问题。

Bug少就是质量高吗？首先第一个问题，Bug是什么？第一个Bug是来自于爱迪生的信，最早的计算机Bug是一个日志，那时的计算机是电子管的，大概有会场这么大，通过灯泡电子管来进行计算。很多灯泡在一个房间里面发光发热，飞蛾飞上去被高压击穿了，就形成了短路，运算结果就出错了，这是机房管理的失误，不是软件开发人员造成的问题。当谈到Bug的时候，我们会用不同的词，Bug在国际标准里是没有定义的。我们现在能找到的定义来自维基百科，就是软件Bug。

那么，当我和客户谈到什么是Bug的时候，他就愣了一下，他说我们的Bug就是指问题单，我们就区分一下这三个词。当谈到问题的时候，你的反应是哪个词？谷歌在中国唯一能用的就是翻译，这里有这么多问题，用户一般都是遇到了问题，一个问题在不同人中，因为单词内容是不一样的，早上我们做自动化测试的时候，中文这个东西没有办法表达词性。用户使用中出现的障碍叫做问题。另外，什么是缺陷？是与生俱来的不符合常理的东西，这取决于怎么定义正常。缺陷是在开发过程中，逻辑不完备产生的意外结果。

什么是故障？这是《黑客帝国》里面的截图，就是系统失败，故障是应用程序在运行时出现的不符合期望的结果。出现的原因很复杂，有可能是开发引入的，有可能是设备引入的，有可能是网络引入的，也有可能是用户自己引入的。维基百科是这样定义Bug的，Bug是计算机或者系统中的一个错误、瑕疵、失败或者故障，导致了非预期的结果和行为。我们明确Bug定义是为了找到形成的原因，我们这样定义Bug的原因，是为了找到质量低下的问题，然后去解决。

准确定义Bug，就是质量改进的开始，当然用户不关心是哪一种原因。软件开发是对用户预期的一种承诺，不符合这种预期就是质量差。我们之前做过一个改进项目，改进质量的原因不是增加测试，是改变这个程序在交互界面上的用词，用户对行为预期就是一致的，否则大家对这个词的理解是不一样的，质量就会下降，这是没有增加测试而提升质量的例子。

什么是软件质量？这是ISO在1999年对软件质量的定义，翻译过来就是软件产品符合需求的能力。一般的需求，那边可能是客户，发现质量问题出现在每个环节过程中，因为我们在做沟通的时候会出现一个问题，那就是真正对方表达出来的想要的内容有多少，不想要的内容有没有表达出来，有没有记录下来，他没有表达出来的东西你是不是想到了？还有非功能性的部分，有没有表达出来，要求不能慢，怎么定义这个慢？一秒钟之内还是三秒钟之内？还有安全性、稳定性都没有表达出来。遗失的需求到哪里去了？语言文字的表达能力是有限的，包括我们之前说的文字，不同的人理解有不同的意思，我们在这个过程中一定会忘记一些问题，我们怎么把没有想到的问题，在需求阶段提出来。

通常的办法是增加需求文档。发现质量问题是需求原因导致的，原来只写三句话，现在要交另外PPT，Word文章，还有Excel表格，业务部门，包括提需求的部门是非常强势的，他们经常说的是给我一套模板，这些人就变成了模板僵尸。我们在这个时候只关注做需求结果的质量，并没有分析需求活动的质量。DevOps不仅关注结构的质量，更关注的每个活动的质量。需求文档是不是能解决质量问题？

在我们的例子里是这样的，第一个对接客户和用户是业务设计环节，业务BA，中间是产品BA，负责产品的研发，架构概要的设计，然后是开发进行详细设计，再给产品做评审，评审通过之后，这个方案没有问题了，把测试拉上开发，开发讲一遍，测试讲一遍，相互确认一下。这个过程就是需求的过程，这个过程就是我们前面说的花费五周时间在做的事情。每个环节会有四种不同的文档，到了开发的手上，包括后面用户测试的手上，又拿不到这些文档。

DevOps要打破组织墙，在这个过程中，软件质量有两种，一种叫客观质量，符合质量度量标准，比如接口覆盖率，各种指标，比如之前做的项目，单元测试里全都是百分之百，用户就一定会觉得质量好吗？不一定，产品一定没问题吗？也不一定。另外是主观质量，每个人对软件的结果和过程的体验，不光包含最终使用这个软件的用户，也包含参与所有环节的人，他们体验也算作质量，分为内部质量和外部质量。如果团队之间，开发觉得需求不够详细，测试觉得代码不够好，没有人改进，内部质量就已经先垮了，就不说外部质量了。

来讲讲DevOps测试观。每次测试听到DevOps的时候，内心都是崩溃的。这里讲的不是测试人员和开发人员，而是包括运维人员的开发团队。因为在国外的很多组织里，测试人员已经被整合到开发团队里了，所以讲的是开发团队，或者产品团队，以及运维团队。这会导致一个问题，DevOps引入中国的时候，大家的理解不统一，大家不知道该怎么办。

回顾一下DevOps的发展，比利时人Patrick是DevOps的创始人，他是一个独立的质量顾问，通俗的讲，他就是一个外包测试，在比利时做数据迁移的时候，他白天和开发人员用敏捷的开发方式去开发，得到一个软件，下午去机房和运维工程师去上线进行测试，这是他的工作。他发现这两个团队，白天和下午工作的方式有些问题，因为上午测得好好的，下午就完全不一样了，为什么不把两个团队拉到一起？后面就有了DevOps这个运动。

从一开始，DevOps本质上就是一个端到端的质量改进运动，关注的是质量，把质量提升之后再去提升速度。DevOps的质量观是每个人都对质量负责，测试是验证需求的手段，当你的需求没有提出来的时候，质量是没有办法保证的。测试在整个团队里面是一项任务，不是一个角色，每个人都可以做测试这件事，有测试前、测试中、测试后，每个人都可以做不同的事情，非功能测试和功能测试同等重要，还有很多生产环境的问题，特别是微服务架构，除了功能性都正常了，每个服务都拼起来之后仍然正常吗？做测试这件事情越早越好，越频繁越好，于是有了自动测试开发。事事可测，时时可测。

从需求的开始，我之前在敏捷团队，每天讨论一件事情，我们问两个问题，第一，这个东西怎么测？第二，这个东西怎么自动化的测？这已经形成了我们团队的文化，这就是测试的文化。所以，在一个研发团队里面，要问的问题是怎么测，怎么自动化的测试，要想办法提升自动化的效率和自动化的覆盖度。在设计时就偏向测试，我们在做自动化测试的时候，前端都不好测试，那是因为前端没有按照测试驱动开发的方式去设计，在设计时没有把自动化测试的应用性放到前端的工程和项目里考虑，所以就变得很难测。我们选了一个折中的方法，用MVVM模型把中间的ViewModel层简单的测一下，把发布的内容拆分到几乎没有发布风险的程度，就随时可以上线了。

发布风险的技术有几点，第一是减少代码提交内容，每次发布的内容很少，要快速的知道是哪行代码出现了问题。然后是TDD，持续集成和部署，还有是金丝雀发布，灰度发布，蓝绿部署。微服务就是在测试周期长的情况下，把应用拆小来进行测试。自动化测试能够纹理运行，就一定能独立部署，通过拆分自动化测试对应的代码来进行服务的拆分，拆分出来的服务一般都没有问题，因为有测试做一层保护。

提升需求质量的实践，第一是用户故事地图，用好的方式记录需求，我们把用户的一句话，比如“我想要定外卖的软件”拆分，直到每个测试的代码，把所有用户故事全部讲完，用户故事的概念，给别人介绍特别好软件的时候，会用讲故事的方法，这种方法能描述我们的软件，让我们知道软件是做什么的。推荐一本书，《用户故事地图》，里面有很多关于需求和质量的金句。我们不仅关注写需求的结果，也关注如何实现需求的过程，以及参与人的体验。如果你的团队没有在一起对用户故事进行充分的讨论，就说明方式不对。我们用了比较小但是比较有效的，用“需要”替代“需求”，用户提需求的时候是求着你，而需要的时候，态度和想法，包括问的问题都是不一样的，产生的结果也是不一样的，大家可以试一试，我们不再问用户的需求是什么，我们问的是他们的需要是什么。

好的用户故事有3C原则和INVEST原则，3C原则，Card、Conversation、Confirmation，一定是很少的记录，很多的讨论，要把你的解决方案跟用户达成一致，始终由你来引导整个软件的开发。INVEST原则，首先是可独立的，我们希望故事之间的开发顺序不影响最终结果，是在一个迭代周期内，不影响最终结果，这是故事的力度。可协商的，如果用户直接告诉你怎么做，就是不可协商的，所以要反客为主，来引导这个需求的方向。有价值的，设两到三个高优先的，越迫切的就表示价值是越高的。小的，可估计的，可测试的，这是可相关的，如果过大就没有办法估计，没有办法给出准确的时间，所以要做得小。我们对需求的可测试是这个要求，如果不能自动化测试，就不是可测试的。因为只有可以自动化测试的那些规格，才是清晰的，不能自动化测试的规格都是模糊的。

如何产生用户故事？通过用户故事工作坊，在一个工作坊里大家一起讨论。这个人是下议院的院长，他经常说的一个词就是“保持秩序”，在这个工作坊里，一定要先让用户说，不要打断，否则很快会导致争论。先让用户充分的表达，因为他是质量最后的决策者。用户故事，要做到“5W1H”，确认用户（Who），确认功能（What），确认价值（Why），确认场景（When & Where），确认规格（How），我们勾画的时候都会产生新的问题，产生新的Bug，在原因回溯的时候，找到这些原因，放到需求阶段，去提出这些问题，在这个阶段去解答。当把没有问到的问题积累到列表的时候，软件交付的质量会越来越高。还有，一定不要让用户告诉你怎么做，如果导航员乱指挥，开车的人就要走错方向，还是应该让专业的司机去开车。

还有实例化需求，要让客户举例子，有清晰的规格。先确认规格和结果，不要先确认形式，从输入到输出，中间有很多种形式，先确认结果是什么，输入是什么，后面再进行设计。语言的表达一般来说是很有限的，我们构建纸片小人，去讨论，去设计，把故事讲给用户听，讲清楚，大家确认之后再做开发。还有一点，用户故事一定要讲出来，和所有人都确认一遍，自己讲完再让用户讲一遍，作确认。

用一句话描述原则，如果一句话表达不完，这个内容就很大，需求就很大。我们使用需求规格成熟度，好的需求规格有用户故事，有验收条件，有测试场景分析，按格式写作用户故事，每个故事都有验收条件，有BDD风格的验收条件，有基于验收条件的测试场景和测试用例分析，能够自动化验收用户故事。我们要求所有团队要达到第三级和第四级之间。我们不用文档，用思维导图，我们的需求到测试，到结果之间都是一一对应的，当思维导图再大的时候就知道怎么去拆。

介绍TDD的时候，发现大家的了解不一样。TDD有三种，第一种是测试用例驱动开发，测试人员驱动开发人员，最后是测试计划驱动开发计划。测试人员在需求阶段要分析明确测试用例，一开始大家对TDD都是抗拒的，因为增加了工作时间，后续用了一段时间TDD，所有开发人员都说不要停。而且，当自动化测试的覆盖率不到76%以上的时候，不会减少测试人员的工作量。还有要尽量采用自动化的方式实现测试用例，如果不好实现，需要进行评估和评审。开发人员以完成测试用例为验收条件，自己没有测过是不能交给测试的，这是一个起码的要求。

测试人员驱动开发人员，就是测试人员不再做重复的测试工作，而是作为一个用户来验收交付的软件，测试的工作是一个任务，让开发人员去完成。测试人员有两种转型，一种是向后做DevOps，一种是向QA，向业务的方向去做前项，在这个过程中QA和BA是可以轮换的。我做一段时间需求分析，再做一段质量验收，都是作为用户的角度，要求开发人员去开发出符合测试质量要求的产品。大部分的QA或者测试人员最后都在团队里面晋升了，变成一个团队的leader。测试计划驱动开发计划，第一点好处是能够分摊测试压力，最后一周的UAT测试分散到每一天，每天的测试量都比较平均，根据测试计划倒排开发计划，采用拉动的方式，而非推动。

落地DevOps的关键是让用户的发布和测试拆分到每次发布风险可以高度可控的程度，如果能拆到两周，两周就能开发，如果能拆到一天，每天都能发布，我们最快的是15分钟发布一次，力度就是一行代码。当把要求做得很高的时候，我们发现一个问题，我们两个人讨论了一天，写了很多测试代码，测试用例，结束的时候只写了一行代码，就是高度讨论，经过了充分测试的结果，这个结果是我们场景中最优化的，让每个提交变得更小，风险更可控。

我的演讲到这里就结束了，谢谢大家！