测试左移和测试右移的 Why-How-What

经常遇到测试同学提问，测试左移和测试右移到底是什么？本文就简要总结并阐述下测试左移和测试右移的 Why-How-What。

Why

软件测试技术应当贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其核心目标是尽快尽早地发现软件产品中所存在的各种问题 bug—— 与用户需求、预先定义的不一致性。

然而，传统的软件测试流程是：

接到项目后参与需求评审，然后根据需求文档写写用例和准备脚本，等开发提测之后正式开始测试、提 Bug、回归测试，测试通过后就结束了。然后，项目交给运维上线，之后测试人员再投入下一个项目，继续重复这样的流程。

这样的流程看似没什么问题，但缺点是：测试过程是在一定时间间隔之内发生的，测试人员必须等待产品完全构建才能找到错误和故障。不可否认，花费的时间超过了可以商定的时间，测试人员就非常被动，因为等待代码成为测试人员的瓶颈。

而在移动互联网和 DT 时代，互联网产品迭代周期短、速度快、频次高，促进了敏捷开发和持续交付等研发模式的全面流行，这也给传统软件测试方式带来了更大的时间压力。

而测试左移以及测试右移的意义就在于能够让测试拥有更多的主动权，有更充足的时间进行测试，同时不会像之前因为质量差风险高每次都延期上线，并且产品的线上质量也能有保证。

不管是测试左移还是测试右移，都是为产品质量服务。测试人应该秉持这样的理念：不要把提测认为是测试活动的开始，上线是测试活动的结束，更不要认为质量只是测试同学需要关注的。

How

测试左移（Testing Shift Left）

测试左移是向测试之前的开发阶段移动。

测试左移的原则支持测试团队在软件开发周期早期和所有干系人合作。因此他们能清晰地理解需求以及设计测试用例去帮助软件“快速失败”，促使团队更早的修改所有的 Bug。更深入的参与和理解会促进测试人员获取产品完整的知识，彻底想清楚各种场景，并根据软件行为设计实时的场景，这些都会帮助团队在编码完成之前识别出一些缺陷。

测试左移聚焦在使测试人员在全部和最重要的项目阶段参与进来。这就是测试人员把焦点从发现 Bug 转移到 Bug 的预防上，同时也驱动项目的商业目标。

随着测试团队的责任的提高，团队不在仅仅聚焦在“测试软件去发现 Bug”，而是积极团队合作，参与项目初始阶段的计划和建立强壮有效的测试策略，而测试策略又为团队提供好的测试领导力和指导，使团队聚焦在产品的长远的视角，而不仅仅是测试工作。

测试左移首先为测试人员提供了设计测试的机会，无论这些测试是被聚焦在客户的体验还是期望，也促使开发人员根据这些测试去开发软件以满足客户需求。

测试右移（Testing Shift Right）

测试右移是测试活动向产品发布之后的步骤移动。

测试右移是产品上线了之后也可以进行一些测试活动。主要关注的是产品性能及可用性监控，以及新功能的测试。通过测试右移可以在生产环境做监控，监控线上性能和可用率，一旦线上发生任何问题，尽快反应，提前反应，给用户良好的体验。

What

测试左移和测试右移的流行技术

在霍格沃兹测试学院的测试开发课程教学体系，已经整理了当下最流行最实用的测试左右移技术栈，这里供参考：

• 代码审计系统 SonarQube 实战
• 测试用例与 JaCoCo 代码覆盖率数据分析实战
• ASM 插桩技术与 JVM-SandBox 项目实战
• 精准化测试平台构建实战（可参考之前文章）
• ELK 深度解读与最佳应用实践
• 测试数据采集、同步、存储与分析实战
• 线上质量监控与数据分析实战
• 测试平台开发实战（SpringBoot+Vuejs+Bootstrap）

总结

以上，测试左移和测试右移是现代互联网研发和测试技术体系的必然趋势，也是大厂对中高级测试开发工程师的必备技能要求。

测试开发工程师会通过测试左移，更深入介入开发工作，提前与开发人员一起制定测试计划，推动代码评审、代码审计、单元测试、自动化冒烟测试、测试精准化分析以及研发自测等来保证研发阶段的质量。

另外，也会通过测试右移，参与配置部署，将自动化测试用例配置到持续交付链中，并全流程监控发布后的应用质量。