|
|
|
|
|
# 06｜左移&右移：测试如何在Dev和Ops领域大展身手？
|
|
|
|
|
|
|
|
|
|
|
|
你好，我是柳胜。
|
|
|
|
|
|
|
|
|
|
|
|
前面的几讲，你已经学习了ROI模型，它开始于一颗带有ROI DNA的种子，不断生长，直到长成一棵大树。从树根到枝干、从规律到原则，它贯穿了一个自动化测试项目，从生到死的完整生命周期：设立目标，制定策略，选择框架到代码的实现，上线的度量，再到衰竭退出。
|
|
|
|
|
|
|
|
|
|
|
|
我把价值篇讲过的内容加以整理，得到了下面的树结构。上面的绿色部分是收益，下面的红色部分是成本。ROI模型树从左到右，是从根到枝干，从ROI理论到实践的延伸和具象化。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ROI模型展开的这棵大树，告诉了我们健康的自动化测试项目长什么样子。但是还有一个现实的问题，我们怎么从这里到那里？换句话说，咱们怎么把自动化测试项目的节奏带起来，让它进入到一个不断提升ROI的轨道上去。
|
|
|
|
|
|
|
|
|
|
|
|
这里有一个很朴素的道理，好马是跑出来的，好钢是炼出来的。首先，要让自动化测试跑起来，增加它的运行次数，这是前提条件。在这个过程中，再修复它的问题，调整它的集合，提高它的可诊断性，整个项目就激活了。
|
|
|
|
|
|
|
|
|
|
|
|
所以，你要找到更多的土壤让自动化测试落地生长。如果你想在工作中推广自动化测试，哪些落地场景更容易出业绩呢？除了之前说过的回归测试领域，我们不妨把眼光从测试工作放宽到更多的领域，Dev和Ops领域，自动化测试在这些领域里一样可以发挥价值，我叫它自动化测试左移和自动化测试右移。
|
|
|
|
|
|
|
|
|
|
|
|
## 自动化测试左移
|
|
|
|
|
|
|
|
|
|
|
|
如果把软件的生命周期的一个个阶段，软件需求分析、软件设计、软件开发、单元测试、集成测试、系统测试，从左向右排列，开发活动在左侧，测试在后面也就是右侧。如下图：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
测试左移，就是说本来在生命周期后期的测试活动提前，在软件开发阶段就参与进来，能让软件质量内建到开发阶段，而不是在后期通过软件测试去发现。比如在需求分析阶段参与需求评审和规范制定，在软件设计阶段就开始测试案例设计。形象地看，是测试活动从右侧向左侧移动，即测试左移。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
测试左移后，当然也会带动自动化测试的变化。在传统模式下，按照软件生命周期顺序，自动化测试是这么安排的：编码完成之后运行单元测试，集成阶段运行接口测试，系统阶段运行UI自动化测试。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这种流水线做法只能说中规中矩，那还有优化提升空间么？从图上看到，我们如果在编码阶段引入了bug，影响接口的bug要等到集成测试阶段才能发现，影响UI的bug要等到系统阶段才能发现。我们既然已经有了接口和UI自动化测试，可不可以把它们利用起来，尽早测试呢？
|
|
|
|
|
|
|
|
|
|
|
|
现在我提出一个新概念，自动化测试左移，在构建阶段建立一个冒烟测试集合的概念，包括单元测试和部分接口测试，甚至部分UI自动化测试，它们一起运行，来验证版本的每一次构建甚至代码的每一次提交。只要这个冒烟测试集合足够快和稳定，就可以被开发人员接受。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
自动化测试左移都有哪些好处呢？
|
|
|
|
|
|
|
|
|
|
|
|
最直观的好处是提早确认代码的变更，满足最终需求，尽早发现回归bug。软件测试领域有一个理论，叫做**验证**和**确认，**在每个软件阶段，都要做两种测试工作：第一是验证当前阶段做好了本阶段要求的事情。比如，编码阶段要把详细设计实现；第二是确认当前阶段实现的功能，可以满足最终的用户需求。
|
|
|
|
|
|
|
|
|
|
|
|
应用到具体场景里，在编码阶段做单元测试这叫验证，在编码阶段运行接口测试和UI自动化测试则是确认，都是有价值的测试活动。
|
|
|
|
|
|
|
|
|
|
|
|
此外，自动化测试就像一辆赛车，需要运行调试、持续保养维护，才能调整到最佳状态。
|
|
|
|
|
|
|
|
|
|
|
|
我见过一些团队，只在软件产品发布的时候，才把开发出来的UI自动化测试作为验收测试运行一次。这样UI自动化测试大概率会失败，测试人员不得不花时间一一解决。不难猜到，在整个发布周期里，UI功能都变化了很多，相应的漏洞更是不可胜数。久而久之，测试人员就对自动化测试产生了厌烦，把它看成摆设、负担，又重归手工测试的状态。
|
|
|
|
|
|
|
|
|
|
|
|
而自动化测试左移到开发的日常活动中，开发人员每天做一次code commit，做一次版本构建就会触发自动化测试，运行频率随之提高。一旦自动化测试运行失败，要么是发现了回归bug，要么是自动化测试需要维护了，问题发现得越早，修复越快，自动化测试就越健康，越稳定可用。在磨合调试的动态过程里，自动化测试越跑越稳定高效，团队也能实实在在体会到它的用处。
|
|
|
|
|
|
|
|
|
|
|
|
所以，自动化测试左移在结果上提高了ROI，丰富了运行场景，也锻炼了自动化测试项目和人马。火炼真金，大浪淘沙，方能走向成功。
|
|
|
|
|
|
|
|
|
|
|
|
## 自动化测试右移
|
|
|
|
|
|
|
|
|
|
|
|
既然有左移，那也存在右移。测试的右移是什么？测试阶段结束，产品就会上线，也就进入了线上运维阶段。所以测试右移是指**测试活动介入线上运维，用户画像等工作**。这里我说的自动化测试右移，意思是自动化测试也可以在生产环境里运行，起到一个自动检查监测的作用。
|
|
|
|
|
|
|
|
|
|
|
|
你可能会问，线上观测已经有了一套Ops流程和工具了，比如Newrelic和Splunk等，都能监测Web服务、API网关，数据库等全栈环境了。自动化测试线上运行的价值在哪里？
|
|
|
|
|
|
|
|
|
|
|
|
这是一个很好的问题。如果你想到了这一层面，说明离我们的右移的落地场景很近了。我们不可能把所有的自动化测试都搬到生产环境里，这样会造成和Ops团队的重叠浪费。
|
|
|
|
|
|
|
|
|
|
|
|
### 部署后验证测试
|
|
|
|
|
|
|
|
|
|
|
|
Ops工具看似很强大，能输出一堆软件服务的各种度量指标，告诉我们软件服务在生产环境里是健康运行的，但是有一个关键的事情，我们无法从Ops那里得知：那就是**服务是不是按照客户的期望运行的，这对产品价值非常重要，但只有运行测试才能知道**。
|
|
|
|
|
|
|
|
|
|
|
|
结合具体场景，我们分析一下这个问题是怎么产生和解决的。
|
|
|
|
|
|
|
|
|
|
|
|
线上升级常用的做法是红绿部署（也叫蓝绿部署）。红绿部署的机制是这样的，当准备升级软件服务时，保持原有的服务红色环境不变，部署一套新的服务绿色环境。在路由层面，把流量切换到绿色环境，完成软件的升级。这样做的好处是，软件升级对用户影响微小，风险也可控。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在这个红绿部署机制里，红环境代表是即将退役环境，绿色环境是健康即将上线环境，那么一个关键问题是，怎么确定环境是红的还是绿的？
|
|
|
|
|
|
|
|
|
|
|
|
环境是绿的，意味着对于用户来说一切正常。这个“正常”的标准，有2个含义，一是Ops的服务健康指标都正常，二是测试的结果也正常，这个测试集合在业内英文名叫Post Deployment Test，中文叫部署后验证测试。意思是在生产环境完成部署或升级后，需要验证业务功能正常运行。
|
|
|
|
|
|
|
|
|
|
|
|
通过Post Deployment Test的通过与否，来设定环境是绿色还是红色。像下图：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这样，Post Deployment Test结合部署的红绿机制，可以形成一个发布升级，环境切换的决策流程。我们又一次丰富了自动化测试运行的场景，让它变得“有用”。
|
|
|
|
|
|
|
|
|
|
|
|
### 生产环境定时监测
|
|
|
|
|
|
|
|
|
|
|
|
部署升级后，生产环境就开始运行了，直到下一次升级为止。在这段线上运行的时间里，是不是就不再需要测试了呢？
|
|
|
|
|
|
|
|
|
|
|
|
按照传统测试理论，测试的生命周期到正式发布为止，也有的到Beta测试为止，而部署到生产环境后，就进入了运维阶段，就是Ops工程师的事了，测试人员就不需要关注了。
|
|
|
|
|
|
|
|
|
|
|
|
但在云时代情况发生了变化。软件开发方不仅交付软件服务，而且也控制着服务器的运行环境。因此测试人员的责任从“在软件发布之前发现bug”变成了“在客户之前发现bug”。
|
|
|
|
|
|
|
|
|
|
|
|
有很多bug，在测试环境里是发现不了的，只有生产环境才能暴露。这些跟客户的行为、生产环境的数据、特定的错误扩散模式都有关系。只要我们在客户遇到bug之前发现它，测试工作仍然是有价值的。
|
|
|
|
|
|
|
|
|
|
|
|
这时我们可以建立一个机制，通过自动化测试来定时监测生产环境。每天定时触发自动化测试任务的运行，去检测生产环境的业务功能是否正常，然后生成测试报告。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
对于自动化测试生成的结果报告，我们还可以把它集成到Ops的Oncall流程里去。当自动化测试任务出了错误，触发Event时，就会进入到Oncall系统。Oncall系统会找出值守的测试人员，发送通知，让测试人员来处理测试错误，判断是不是线上出了bug。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这个机制一旦建立起来，会大大锻炼你的测试人员队伍，因为你每天会收到各种告警，需要去处理，直到你真的把自动化测试的健壮性和稳定性，提升到一个“可信”的程度。
|
|
|
|
|
|
|
|
|
|
|
|
## 小结
|
|
|
|
|
|
|
|
|
|
|
|
这一讲，我们一起总结了自动化测试的ROI模型树，还有种种可以提高自动化测试收益的落地场景。从业界来说，有左移和右移这两个大领域，使得测试的工作不再局限于原先的那个圈圈里，而是向Dev和Ops方向延伸，并和它们融合。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这个左移和右移已经不是在理念阶段了，而是业界正在发生的事情，参看[2022世界软件质量报告](https://lp.katalon.com/hubfs/download-content/report/The-State-of-Quality-2022.pdf)，有38%的公司已经在Ops领域开展测试了，而且这个数字还在增长。但是，要完成左移和右移并不容易。据我了解，很多公司还没有做好准备，一个重要的方面是意识上还没有转变。
|
|
|
|
|
|
|
|
|
|
|
|
今天，你学习了本模块的ROI模型之后，知道ROI是我们自动化测试工作成败的命脉，那你不妨换个思维角度，像做销售一样，向团队向公司积极布道你的自动化测试成果，让更多的角色来使用你的服务。
|
|
|
|
|
|
|
|
|
|
|
|
这块不局限于Dev和Ops团队，甚至可以是Product Manager团队，自动化测试代码调用是一个非常好的服务模式，一旦他们开始使用，就相当于你的服务有了客户，可以通过客户的反馈，持续打磨你的服务，**这个服务的最后结果就是自动化测试持续输出“有用”和“可信”的结果**。
|
|
|
|
|
|
|
|
|
|
|
|
在“有用”和“可信”基础上，如果再加上一个要素的话，我认为应该是“快速”，自动化测试服务的输出是当前的被测系统是否OK，没有人愿意忍受等几十分钟才能获得服务的结果。在Devops理念横行的今天，人们的耐心越来越低，你应该让自动化测试运行得精准、快速、高效。这给自动化测试提出了更大的挑战。
|
|
|
|
|
|
|
|
|
|
|
|
如何应对挑战，我们后续课程还会提出更有针对性的解决方案。是不是很期待下面的内容？那就准备好进入下一模块吧。
|
|
|
|
|
|
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
|
|
|
|
|
|
今天留两个题目，你可以任选一个有兴趣的聊聊想法。
|
|
|
|
|
|
|
|
|
|
|
|
1.什么是蓝绿部署？蓝代表什么？什么条件下变成绿？
|
|
|
|
|
|
|
|
|
|
|
|
2.学完这讲内容，你觉得自己手里负责的工作有没有左移或右移的空间呢，具体你想怎么做？
|
|
|
|
|
|
|
|
|
|
|
|
期待你在留言区跟我交流互动，如果这一讲对你有启发，也推荐你把它转发给更多同事、朋友。
|
|
|
|
|
|
|
