本文内容选自2021中国DevOps社区峰会 · 深圳站，陈晓鹏老师分享的《基于DevOps的质量左移与右移思考》文字实录和视频回放。
2022中国DevOps社区峰会 · 天津站，定档8月13日，哏都欢迎你~文末可抢购盲鸟票哦~
分享嘉宾：陈晓鹏
某中国著名互联网公司项目管理专家
中国商业联合会互联网应用委员会智库专家、ISO29119软件测试国际标准评审组专家，暨南大学信息科学技术学院校友导师，原埃森哲金牌讲师。拥有MBA，PMP，CSM，SAFe Agilist，LeSS Practitioner及EXIN DevOps Master/DevOps Professional/DevOps Foundation全系列DevOps认证，20年IT领域相关工作经验，超过13年在IBM、埃森哲、德勤等国际顶尖IT咨询及世界五百强公司工作，现为某中国著名互联网大厂项目管理专家。
视频回放：
以下是演讲文字实录：
一、DevOps的孪生兄弟们
在正式开始分享之前，想跟大家介绍一下DevOps的孪生兄弟们。DevOps就是Dev+Ops，Dev是开发，Ops是运维，经过几年发展，出现了很多新词，比如DevSecOps、BizDevOps、DataOps、AIOps等等，我们是否可以类推，如果加入测试，是不是就叫DevQaOps或DevTestOps？答案是否定的。
二、DevOps中的测试究竟在哪里？
那测试在哪里？很多人说测试在Dev里面，因为Dev并不是传统意义上理解的开发人员，而是开发组织，开发组织包含测试，而Ops是运维组织，两者结合起来就是DevOps。
去年我在写《敏捷测试转型》一书时，专门做了研究，看到下图，大受启发，它阐明了测试不仅在Dev里，也包含在Ops里，在无限循环的9个步骤里，都有test的活动。测试融入在DevOps中而不是融入在Dev中。
三、DevOps中的质量左移与右移
如图所示，这是一个传统的研发周期图，从方案到需求、设计，到测试、上线。
所谓的DevOps的质量左移或右移是什么意思呢？图中的测试，不是大家理解的传统意义上的拿着需求说明书去做验证，这部分测试活动用灰色表示，只占整个质量左移或右移体系里非常小的一部分，除此之外，还有黄色和蓝色部分。黄色部分是指除了验证需求和说明书外，还要发现一些系统里不可预料到的问题，这就是真正测试人员提升价值的所在。灰色部分可以用自动化去实现，而黄色部分需要用人的思维去做，这就是我们所说的探索式测试；蓝色部分是在代码还没完成之前的过程，在这个过程中，QA和测试人员更多会从项目需求风险、可测性和假设等方面来判断到底需求和系统有没有问题、有没有风险。
左移和右移的中间点是什么呢？我认为有两点：
从测试人员角度看，左移是单元测试，上线之后就是右移。
从项目的角度来看，coding之前是左移，之后是右移。
这样我们可以用一些比较流行的方法和技术来做支持，比如代码写完后可以用代码扫描工具，可以做自动化单元测试、探索式测试等，其中自动化测试就是前面提到的灰色部分，自动化测试不能代表整个测试的过程，自动化测试永远代替不了人工，探索式测试需要人工完成。
传统的瀑布模式下，需求、设计、开发、测试按顺序进行，这样的流程下，怎么做测试，大家都很清楚。
那Scrum怎么做测试呢？
在开发的时候会有一个版本规划，测试人员应尽早参与，分析理解，看有没有风险、交付时间是否可以，包括资源、环境、数据、DoD等；做sprint时，首先要确保测试的容量，否则你会发现测试的吞吐量不够，再往下走是提升测试的透明度，无论团队成员在哪个地方，本地还是远程，都要参与到每个讨论环节中，要让所有的计划、进度非常清楚，如果有问题，要提早把问题、障碍、风险暴露给团队；执行的时候，需要参与到代码评审，以及开发人员的会议中，可以从测试专业的角度给开发提一些意见。
代码覆盖率与测试覆盖率有什么区别？
代码覆盖率表示测试用例通过手动测试和使用自动化测试所覆盖的代码百分比。比如正在测试的代码总行数是1000行，跑完所有的测试用例，不管是手动还是自动，跑过的代码行数是650，那代码覆盖率就是65%。
测试覆盖率的颗粒度是需求，测试覆盖率是通过测试所覆盖的需求来度量的，是度量有多少的特性/功能被执行。比如现在要做一个web应用程序的兼容性测试，可能会涉及到跨浏览器、跨操作系统，可以把跨浏览器、跨操作系统的最大比例算出来，比如是20个组合，做了15个测试组合之后，测试覆盖率就是75%。
我们需要追求百分百代码覆盖率吗？
如图所示是单元测试的代码段，就是验证一个除法，x/y，测试10除以2是否等于5，很简单。是否代码覆盖率100%？因为它已经覆盖了x/y的语句。但其实它是有问题的，因为它没有验证y等于0的时候，我们都知道，除数是不能为0的。所以百分百的代码覆盖率，并不能代表质量就一定是高的。
有些语句并不需要做代码覆盖，比如getter、setter等语句的逻辑重要程度不是很高，代码覆盖的价值不大。另外，单元测试里，不应该与代码实现有太紧密的耦合，比如在写单元测试的时候，对于私有方法不需要写单元测试。因此你会发现，代码覆盖率并不需要百分百，只要达到百分之七八十就可以了。代码覆盖率的价值，不在于要验证百分百的通过率，而在于帮助你发现代码哪些部分没有被测试，从而提高测试通过性。
四、自动化测试
自动化测试是DevOps的质量保障基石。
下图是一个交付流水线，从需求端到开发到单元测试 、代码分析、合并代码、自动化测试、手工测试、非功能测试、生产运营。标红的是自动化测试领域范畴里的，包括自动化单元测试、自动化代码扫描、代码分析、冒烟测试、自动化部署等，在整个CI/CD流水线里，自动化测试有着非常重要的地位，也就是说，如果没有自动化测试，CI/CD是有问题的。这些工作要在10分钟内搞定，自动化验收阶段要小于2小时。如果做不到，就没有办法敏捷和快速反馈，表示自动化测试执行的效率需要优化。
五、探索式测试
什么是探索式测试？
自动化测试到底能不能完全依赖？前面提到，自动化测试不能解决人的问题，所以一定要有人的参与，人的参与指的就是探索式测试。
探索式测试是一种强调测试人员的自由和责任以不断优化其工作价值的测试方法，它通过将学习、测试设计和测试执行作为互相支持的活动在整个项目过程中并行执行。
传统测试一般分为两个阶段：测试用例编写和测试用例执行，而且两个阶段是不同的人在操作；而探索式测试只有一个步骤，就是学习、思考、写用例、执行，首先对被测的系统做学习研究，去想一些测试点，甚至用例都不用写，只写一些简单的测试点就可以执行，而且它会重复性地执行。
探索式测试的原理是什么呢？为什么能发现bug？
举个形象的例子，扫雷游戏，如图红色的点是雷。传统的测试方法，先写测试用例，然后执行，还是能扫到一些雷的，但是不多；探索式测试，无序或更多维的方向，很明显扫到的雷更多。探索式测试是发散性思维来组织、思考测试点。
生产环境测试分为两种方式：一种是上线后测试、一种是线上巡检。
上线后测试是上线之后部署到生产系统，这时不是马上开放给最终用户去用，而是会有一段时间组织业务人员去做测试，目的是验证应用部署到生产环境会有什么样的问题，这时的测试往往是很短的，比如0点部署，5点截止，超过时间没有测完可能会影响第二天的正常使用。因为有时间的限制，建议大家不要全回归，要找核心重点的业务，还要避免脏数据。
线上巡检是在日常系统里做测试，其核心点是近几年在谈的全功能测试，把测试数据做一个标识，在程序处理的时候，对不同的标识做判断，注意要把测试数据流引到另一个方向，不要跟生产数据混合。
六、混沌工程
混沌工程是怎么来的？亚马逊“灾难大师”在做消防员训练的时候得到启发，在亚马逊推行所谓的游戏日，不断地说要在生产系统里，人为地注入一些故障，看系统能不能覆盖，覆盖的时间是多长。
最出名的是Netflix，在AWS里做了一只捣蛋猴子，杀进程、关服务，看是否能够恢复。
下图是混沌工程的流程。混沌工程有很多开源框架，但真正做混沌工程，最主要还是要覆盖5个流程：稳定状态、假设、设计并运行实验、学习和验证、改进和修正。
稳定状态。要知道现在的正常状态是什么，如果做了混沌工程，不知道恢复的时候是什么状态，就很头疼。一般怎么知道？用指标、KPI，而且要设计跟业务相关的KPI，比如点播率、每个月卖出的数据量等，用业务相关的数据做反馈。
假设。假设停电了、系统宕机了、进程死掉了，做了假设之后要选择哪个假设是你要做的，不能说全部一起做。
设计并运行试验。选择了假设后，要设计并运行试验，看爆炸路径多长、爆炸范围、影响多大，一定要控制好爆炸半径，否则可能整个系统都宕掉了。设计并运行，最好的方式是切一小部分用户做测试，比如先拿1%的用户做工程实验，这是减少风险的很好方式。
学习和验证。学习验证，总结发现漏洞。
改进和修正。发现漏洞要改进，比如单点风险需要扩容，需要做负载均衡等。
往期推荐
2022中国DevOps社区峰会 · 天津
8月13日 天津赛象酒店
扫描海报二维码或点击“阅读原文”
即可抢购盲鸟票
2281
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
