如果你想在工作中推广自动化测试，哪些落地场景更容易出业绩呢？除了之前说过的回归测试领域，我们不妨把眼光从测试工作放宽到更多的领域，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。
这个机制一旦建立起来，会大大锻炼你的测试人员队伍，因为你每天会收到各种告警，需要去处理，直到你真的把自动化测试的健壮性和稳定性，提升到一个“可信”的程度。
小结
这块不局限于 Dev 和 Ops 团队，甚至可以是 Product Manager 团队，自动化测试代码调用是一个非常好的服务模式，一旦他们开始使用，就相当于你的服务有了客户，可以通过客户的反馈，持续打磨你的服务，这个服务的最后结果就是自动化测试持续输出“有用”和“可信”的结果。在“有用”和“可信”基础上，如果再加上一个要素的话，我认为应该是“快速”，自动化测试服务的输出是当前的被测系统是否 OK，没有人愿意忍受等几十分钟才能获得服务的结果。在 Devops 理念横行的今天，人们的耐心越来越低，你应该让自动化测试运行得精准、快速、高效。这给自动化测试提出了更大的挑战。
