一、测试左移与测试右移的定义
通俗的讲：左移是往开发阶段移，右移是往发布之后移。
正常测试：提测后的测试工作——到——发布验证完成阶段。
测试左移：提测之前的测试。如：代码单元测试，代码质量检测，代码接口持续测试 等。
测试右移：发布验证之后的测试。如：灰度发布测试的问题，生产服务监测处理，用户反馈问题处理，对客户的技术支持等。
1、什么是测试左移？
测试左移的思想本质是越早的发现不合理的地方，出问题的几率就越低。
测试左移的原则支持测试团队在软件开发周期早期和所有干系人合作，因此他们能清晰地理解需求以及设计测试用例去帮助软件“快速失败”，促使团队更早的修改所有的bug。
参与和理解会使测试人员获取产品完整的知识，彻底想清楚各种场景，根据软件行为设计实时的场景，这些都会帮助团队在编码完成之前识别出一些缺陷。
2、什么是测试右移？
测试右移是产品上线了之后也可以进行一些测试活动。当然在生产环境直接做测试是不推荐的，但是我们可以在生产环境做监控，监控线上性能和可用率，一旦线上发生任何问题，尽快反应，提前反应，给用户良好的体验。尽量做到技术人员要比业务方先发现问题。
测试右移其实还可以理解为如果线上发生任何问题，我们有没有能力第一时间发现问题并解决问题，并保证线上数据的一致性或尽可能少的影响线上用户，以及并且实时获取用户反馈。
■ 测试左移：测试左移，本质上是借助工具和测试手段更早地发现问题和预防问题。
需求：对需求、架构和设计模型的测试；
开发：着重增加对单元、组件和服务层的测试；
持续测试：自动化测试。
■ 测试右移：对测试同学来说，版本上线后需要持续关注线上监控和预警，及时发现问题并跟进解决，将影响范围降到最低。
灰度发布：新版本线上测试；
监控：合理的性能监测、数据监控和预警机制；
用户反馈：线上问题处理、跟踪机制。
二、测试左移内容
2.1 PRD评审
这一点相信很多测试同学都有参与过，需求的PRD评审，但是很多时候可能只是局限于听需求，而缺少了分析or测试需求的部分。测试一方面是熟悉需求的内容，另一方面也是找出需求的问题，确认需求的合理性，判断需求是否全面、正确，上下文具备不二性。
2.2 研发设计评审
这一点当我们测试在做测试方案、用例设计的时候，研发也在做研发设计，做好了之后通常会有研发设计的评审。测试在这个阶段是非常有必要参与研发设计的评审的。
有的同学可能会觉得，研发设计评审说的都是研发如何实现整个需求，自己去听也听不太懂，浪费时间。其实不然，虽然不一定我们能全部听懂所有的研发技术，但是至少我们能听到研发去开发整个需求的整体设计思路，听完对于我们熟悉整个需求的架构图非常有帮助，也就能帮助测试更好的去设计对应的测试用例，提高测试用例的覆盖率。
避免纯粹从黑盒的角度去设计测试用例，导致有一些个别情况下的缺失测试用例覆盖的情况。当然，如果测试具备走读研发代码的能力，参与研发的设计评审，对于提升测试用例覆盖率，会更加的事半功倍！
2.3 单元测试
这一点现在应该只有一些大厂会执行得好一些，很多中小公司都没有严格要求研发必须做单元测试。一方面是中小公司流程上要求普遍不会那么严格，另一方面也是需求开发时间越来越短，导致研发们普遍都没有很多的时间去执行单元测试的工作，为保障按时交货，都直接开发完成就扔给测试去做相应的测试。
在这一点上我依然坚持研发为主、测试为辅的思路。测试辅助研发更好的完成单元测试。为什么不是测试直接去做单元测试呢？因为这一方面需要测试具备白盒测试
2.4 模块集成联调测试
这一点我们测试可以做一个mock平台或者mock服务提供给研发，帮助研发可以快速mock接口内容，提高联调测试的效率。
2.5 代码规范检查
这一点也是提高研发提测质量的手段，可以通过各类代码检查工具来规范提高研发的代码质量。比如Java系比较流行的SonarQube, 可以结合进CICD的流程，作为代码提测的必查项。
2.6 代码复杂度检查
这一点也一样，只是很多公司目前不太在意这一点。其实越复杂的代码，也就意味着其存在bug的可能性越高。同样代码越复杂，也意味着编码质量可能不高或者后期代码维护成本的升高。SonarQube目前也能扫描代码的复杂度，编译器Idea的也有类似的插件提供该项检查，因此这一点也可以列为流程中的必查项。
2.7 自动化测试
这一点就是测试最熟悉的了，自动化测试，目前主要包括UI自动化和接口自动化，实现的方式也是多种多样，编写脚本的方式、录制回放的方式，用平台、不用平台都OK。重点在于选择适合自身组织的方式，以及如何自动化是否真的提升了测试的效率，避免为了自动化而自动化。
三、测试右移内容
3.1 灰度发布
又称为“金丝雀发布”，本质就是另外构造一套环境，先把代码发布到这套环境中，只放少量指定的流量进来试用一段时间，通常为试用一周或两周，达到以实际的线上流量检测代码是否存在问题的目的，减少上线后大量流量运行下出问题的概率。引入这样的一个过程，那么测试就会先在灰度环境上做验证，也是目前大厂都必有的一个环节。
3.2 线上监控
项目上线后仍然需要关注服务的运行情况，以便在出现系统问题时能够快速做出反应。这一点主要是测试可以右移参与线上环境监控工具的部署，让整个线上的监控体系更加完善。
即使部署的工作都是运维在做，监控体系已经非常完善，测试也可以接入告警，当业务接口出错或者调用量超过阈值时，测试可以接收到对应的告警信息，和研发一起定位解决问题。
3.3 用户反馈
测试参与到线上用户反馈的问题中去，帮助复现和定位各类线上用户反馈的问题，既可以解决问题，也可以更多的了解用户实际使用过程中的问题和需求，帮助后续更好的做好需求评审和测试覆盖工作。
3.4 混沌工程
类似于“故障演练”，通过构造各类异常，验证系统在碰到这些异常时是否有做好对应的监控告警、预案处理，针对性地进行加固，防范，从而避免故障发生时所带来的严重后果。通过对各类异常提前做好监控告警和预案处理，增强系统的健壮性，增强分布式系统的信心。目前已经成为各大厂测试右移
3.5 A/B测试
ABTest 实验，其实本质上就是把平台的流量均匀分为几个组，每个组添加不同的策略，然后根据这几个组的用户数据指标，例如：留存、人均观看时长、基础互动率等等核心指标，最终选择一个最好的组上线。常用于验证不同的方案设计、算法设计的效果。
四、我们可以做什么
1，测试左移，我们可以做什么
- 在需求评审时不只是了解需求，更是要去评估需求的质量，分析需求的合理性以及完整性。
- 代码扫描，代码质量检查，进行单元测试，测试驱动开发，这些都是在开发阶段就引入测试的手段。
- 测试人员尽早介入测试，参加需求分析，评审。
- 持续测试：自动化测试。
对于测试左移其实我们还有很多东西要做，就好像一开始说到的都是为产品质量服务，那么在研发流程中的任何角色、人员都要为质量服务。
有哪些活动可以提高质量上限（举例）？
健康的项目流程（合理并且严格遵守的项目流程）
合理的需求分析（评估需求的质量，分析需求的合理性以及完整性）
出色的系统架构
完整的系统设计（评估设计的质量，分析需求的合理性以及完整性）
充分利用静态代码扫描
进行研发标准的定义
更早的测试分析（先于开发完成需求的分析，做好各种评审的准备）
尽早的测试执行（提早参与测试执行，在集成前就发现一些问题）
有哪些活动可以提高质量下限（举例）？
健康的测试流程
优秀的测试用例
合理的测试计划
合适的自动化
适当的探索式测试
开发自测（TDD、BDD，测试提供更好的用例、技术支持）
团队质量意识的培养
对于测试左移，也需要一个重要的基础，工程习惯，SDLC成熟度，测试分层，持续集成，链路上延展发布的节奏，纵深上需要贴合业务的专精领域的深度探索，代码扫描（规范，问题，安全，异常等），CR， 代码提交行为分析，test double（mock ， fake， stub，dummy）， UT， 自动化，验收测试等。左移需要工程效率具备不亚于研发的代码能力。
因此对于测试左移，笔者认为可以围绕质量服务思想展开，参与人员则不仅仅局限于测试人员
当然实践起来会存在一些问题，例如笔者团队实践起来，就出现了
测试要求提供概要设计、接口文档！！！
测试要求单元测试必须通过！！！
测试干预需求设计！！！
很多人都认为是测试在要求完成一些没必要的事情，测试在干预我的工作。
其实问题的矛盾点在于前面说过的一句话：不管是测试左移还是测试右移，都是为产品质量服务。不要把提测认为是测试活动的开始，上线是测试活动的结束，更不要认为质量只是测试同学需要关注的。对于测试左移的落实，最重要的就是全员质量服务意识的培养
2，测试右移，我们可以做什么
测试上线及时验证，有问题，开发快速回滚代码
上线后开发监控服务日志，日志报错，代码回滚
监控服务流量，出现流量报警快速定位问题
闭环的线上问题反馈-检查-解决-更新流程
更便捷的日志查看、回传服务
丰富有效的log，便于问题的快速定位
丰富的监控指标（例如业务异常点指标）
成本监控（例如短信发送等）
关键指标每日监控（服务器指标）
生产数据监控（警报）（通过sql语句实现生产数据监控，例如是否有多个订单号一样的订单出现等）
用户反馈问题及时跟进，针对缺陷，通知开发尽快解决，针对体验，通知产品打磨细节。
因此对于测试右移，我认为可以围绕问题反馈、发现、定位、监控展开，参与人员则不仅仅局限于运维人员
当然一样的，实践起来也是存在问题，除了技术问题之外，还有例如：
线上监控搭建后无人使用
线上问题反馈机制，业务人员不配合等等
监控指标不合理，反而被认为增加服务器负载
测试右移的落实，除了质量服务的培养，更加重要的反而可能是：完善的反馈、发现、定位，在监控架构完善后，怎么更好的与项目流程结合，不要让其成为累赘。