测试左移右移-理论篇

---

前言

测试左移右移，很多人说能让测试更拥有主动权，展示出测试岗位也是有很大的价值，说白了就是整体效率与质量保障。其实不然，是测试业界的一种进步，更多的是对系统的整体把控、但我想说：这难道不是一种新的方式卷起来了吗？

在传统测试，我们只需要关注测试相关，没有关注测试前、后的"流水线"。而测试左移右移中，则会让我们更加关注测试的前、后可做把控等，让我们或团队更对"流水线"全局意识。

那什么是测试左移、右移呢？我们可以简单理解为

• 左移：测试前可做的工作项
• 右移：上线后（测试后）可做的工作项

可根据开发流程需要左移、右移能做什么：

软件工程方法：

---

一、浅解左移

1.什么是测试左移？

简单理解为：测试前可做的工作项，能更早地发现问题和预防问题。
那能做的有哪些呢？

1.1对产品

1）需求背景、用户痛点分析、设计是否合理等问题建议提出；
2）资源投入、任务分配和产出预估，风险评估；

1.2对开发

1）代码设计方案评审，要求代码变动影响范围、数据结构变化等，提供相应接口文档；
2）增加单元测试、code review的测试、diff、代码扫描等，建议持续集成的单元测试；
3）根据测试提供高优冒烟用例，开发进行自测、报告，如接口则新增入参样例；

1.3对测试

1）持续集成测试，API、UI、性能自动化测试等。

1.4对运维

1）资源性能评估、服务机器环境稳定性等；
2）流水线的持续构建稳定性；

二、浅解右移

简单理解为：上线后（测试后）可做的工作项，及时发现线上问题、告警，将影响范围降到最小。
那能做的有哪些呢？

1.1对产品

1）通俗易懂的系统使用文档、反馈机制；
2）线上A/B测试、灰度发布；
3）有对应值班运维、开发等，值班机制；

1.2对开发

1）丰富日志系统监控告警，便于问题的快速发现、定位；
2）核心业务功能，需要有降级方案；

1.3对测试

1）自动化测试，巡检线上核心业务功能；
2）定期监控、关注错误日志；
3）及时跟进、处理线上问题，完善问题跟踪机制；

1.4对运维

1）服务资源性能、数据资源监控预警/告警；

---

三、总结

向左移动意味着将更多的测试工作提前到从需求开始到开发阶段，向右移动则是将更多的测试工作推后到项目的后期阶段。

本文是测试左移或右移的个人见解，纯理论，如果有不足，欢迎指出留言、讨论均可；
实战篇可能将会在未来一段时间再介绍我们在做的，效果怎么样等介绍。

另外测试左移与右移本身不互斥，需要制定合理的计划和管理策略。在项目早期，团队应该评估项目风险和时间表，并确定测试策略和资源分配。在项目执行过程中，团队需要根据实际情况进行灵活调整，以确保测试工作的顺利进行和质量的提高。