在开发一个系统或者说软件，需求分析、软件设计、程序编码、软件测试、运行维护，这些阶段必不可少。整个周期中，作为测试人员，不是只在测试阶段才能发挥作用，也不是仅有测试对软件质量负责，一个项目团队，常有的五种角色，产品、UI、开发、测试、运维，只有整个项目团队所有成员有对质量负责的意识，才能形成良性循环，不然就是一个甩锅的团队！

测试左移和右移的图示：

一、测试左移

1. 需求评审 

提前阅读PRD，在理解本次需求内容的同时，要检查是否存在以下问题：

• 本次需求是否有不合理的地方
• 表述的是否清晰，不存在模糊不清的表述内容，如过滤掉不符合质量的商品
• 不存在有歧义的表述内容
• 文档中是否标注需求的优先级
• 本次需求是否对原有功能有影响，便于进行回归

如果比较明细的错误可以直接反馈给产品进行修改，如果存在有争议的问题，可以正式评审会上拿出来大家一起讨论给出解决方法

2. 技术评审

对于中小型需求，参会人员为涉及到的产品、开发、测试即可

提前阅读技术方案文档，主要关注以下几点：

• 方案设计是否有遗漏需求点
• 方案设计是否合理
• 方案设计是否满足本次需求点
• 方案设计尽量做到功能点和代码的映射关系，哪个功能点需要改动或者新增哪个接口，需要修改哪个文件内容和或新增哪个文件内容
• 对于修改原来已有的接口要及时同步给接口开发的负责人
• 方案设计设计到哪些功能模块，是否存在关联功能模块的影响
• 方案设计是否有新建数据库或者对原有数据库字段的更新，数据库字段类型设置是否合理
• 提醒开发要进行异常情况的逻辑开发，保证代码的健壮性

3.开发阶段

• 编写单元测试
• 开发完成后有经验的开发人员进行code review

4.用例评审

• 检查用例是否存在有遗漏的，如果有及时补充测试用例
• 用例评审完，提供冒烟用例给开发进行自测

5.设置提测准入的卡点

• 静态代码扫描通过
• 单测执行通过
• 冒烟用例执行通过
• 接口自动化回归通过（技术评审完后，可以提前添加接口自动化了）

以上几点通过以后才能发起提测。

6.日常建设

• 需要不断地培养产品、开发同学的质量意识，同时提供必要的技术支持，协助产品、开发更好的进行测试，比如测试工具、测试脚本
• 定期组内进行技术分享，项目复盘，讲解测试过程中可优化的点，沉淀业务文档

二、测试右移

测试右移就是项目发布上线后建立完善的反馈、发现、定位问题机制。

• 可以进行灰度发布，确定灰度期间没有发布到，在继续全量发布
• 通过线上监控和预警，及时发现问题并跟进解决；系统层（如cpu、内存问题）、应用层（如响应时间）、业务层（通过率）等出现异常的时候通过邮件或者钉钉等方式发出预警，并且针对预警做出快速响应。
• 添加的监控和报警要进行分级，且配置要合理，避免出现报警泛滥的问题，导致真正的报警无人关注。
• 监控或者人工发现问题进行分类沉淀为静态代码分析规则。

测试右移的实践步骤

对于测试右移，线上监控可以是突破点，：

闭环的线上问题反馈-检查-解决-更新流程

更便捷的日志查看、回传服务

丰富有效的log，便于问题的快速定位

丰富的监控指标（例如业务异常点指标）

成本监控（例如短信发送等）

关键指标每日监控（服务器指标）

生产数据监控（警报）（通过sql语句实现生产数据监控，例如是否有多个订单号一样的订单出现等）

因此对于测试右移，可以围绕问题反馈、发现、定位、监控展开，参与人员则不仅仅局限于运维人员

测试右移还需改进的实践

一样的，实践起来也是存在问题，除了技术问题之外，还有例如：

线上监控搭建后使用率不高

线上问题反馈机制，业务人员不配合等等

监控指标不合理，反而被认为增加服务器负载

测试右移的落实，除了质量服务的培养，更加重要的反而可能是：完善的反馈、发现、定位，在监控- 架构完善后，怎么更好的与项目工作(流程)结合，不要让其成为累赘

参考：

【面试系列】如何保障质量之测试左移右移 - 千君君 - 博客园

软件测试人员在软件生命周期内能做哪些事？ - 千君君 - 博客园

测试如何发挥更大的价值？聊聊测试左移和右移 - 知乎