测试左移右移-理论篇
前言
测试左移右移，很多人说能让测试更拥有主动权，展示出测试岗位也是有很大的价值，说白了就是整体效率与质量保障。其实不然，是测试业界的一种进步，更多的是对系统的整体把控、但我想说：这难道不是一种新的方式卷起来了吗？
在传统测试，我们只需要关注测试相关，没有关注测试前、后的"流水线"。而测试左移右移中，则会让我们更加关注测试的前、后可做把控等，让我们或团队更对"流水线"全局意识。
那什么是测试左移、右移呢？我们可以简单理解为
- 左移：测试前可做的工作项
- 右移：上线后（测试后）可做的工作项
可根据开发流程需要左移、右移能做什么：
软件工程方法：
一、浅解左移
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）服务资源性能、数据资源监控预警/告警；
三、总结
向左移动意味着将更多的测试工作提前到从需求开始到开发阶段，向右移动则是将更多的测试工作推后到项目的后期阶段。
本文是测试左移或右移的个人见解，纯理论，如果有不足，欢迎指出留言、讨论均可；
实战篇可能将会在未来一段时间再介绍我们在做的，效果怎么样等介绍。
另外测试左移与右移本身不互斥，需要制定合理的计划和管理策略。在项目早期，团队应该评估项目风险和时间表，并确定测试策略和资源分配。在项目执行过程中，团队需要根据实际情况进行灵活调整，以确保测试工作的顺利进行和质量的提高。
