测试左移与右移方案

测试左移目的

通过将测试左移的方式将当前的测试状态转变到理想的测试状态

测试当前工作量

仅有部分工作量在测试阶段以外，主要工作量都在测试阶段，导致测试人员在其他阶段无工作量，测试阶段工作量又过高，导致测试成为整个迭代过程的瓶颈。

测试理想工作量

测试在测试阶段的工作量仍占主要，但是相对比例比现状小很多，将部分工作量转移到其他阶段，平均测试人员的各阶段工作量，避免测试阶段成为整个迭代过程的瓶颈。

如何落地

在各种关于持续测试、测试左移的书籍里面，讲了非常多的概念和理念，但是没有一本书能告诉你如何落地。因为世界上没有相同的两片叶子，也不可能有相同两个团队，测试左移更多的偏理念，和 OKR 一样，它提供的是一种思维，一种改变团队测试去适应敏捷开发的思维。

回归主题，先抛开各种理念，测试左移归根到底是要将测试阶段所要测试的部分东西转移到其他阶段来进行，所以落地之前要先清楚，我们测试阶段到底在测些什么，而其中又有那些部分可以转移到其他阶段来进行。

现有测试范围分配

如上图所示，现阶段测试的测试范围主要落在了测试阶段的功能测试环节上，并且耗时最大的并不是覆盖这些测试范围，而是在验收阶段。由于代码质量等问题导致的反复验收会打断整个测试环节，以及由于修复一个问题而导致出现另外一个问题的情况常有发生，这都是导致测试阶段耗时过长的原因。

目标测试范围分配

目标的测试范围分配，把功能测试的大部分验证工作都前移到开发阶段，需求一致性验证的工作全部转移到概要设计评审阶段。

落地措施

将概要设计评审定位硬性要求

其实现阶段是有概要设计评审的，但是一来并不是强制性要求，二来开发人员对编写概要设计的动力和能力有欠缺，导致本应在概要设计阶段就解决的需求不一致拖后到测试阶段才解决。本应在概要设计评审阶段花几十分钟就解决的问题，拖后到测试阶段需要花费十个甚至几十个的几十分钟。

所以非常有必要把概要设计评审作为每一个版本迭代必备执行环节，并且对环节执行的质量要有所要求。

将功能测试大部分转移到开发阶段完成

开发阶段的功能测试主要用程序实现，可分为以下三种：

• 单元测试，由开发人员完成
• 集成测试，由开发内的测试开发人员完成
• 冒烟测试，由测试内的测试开发人员完成

单元测试，即对于单一模块单元进行的测试，现阶段开发人员有进行编写，但编写的单元测试质量参差不齐，并且整体的覆盖率非常堪忧，需要进一步提升整体单元测试质量，并且对整体测试覆盖率有一个硬性的要求。

集成测试，即将各模块各系统集成起来，完成测试人员编写的测试用例的测试。现阶段这方面处于刚起步，没有任何组织和管理，对于集成测试的边界以及包括范围以及规范等都没有任何的规定。一个理想的集成测试，应该是开发内的测试开发人员编写，基于模块的直接调用，不用涉及 k8s 环境的，从系统内部对系统进行满足测试人员编写的测试用例的测试。

冒烟测试，冒烟测试通过是确保提测系统可用的最低要求，但现阶段更多的是测试人员手动进行冒烟测试，无论是效率还是效果上都有所欠缺，需要转换到开发阶段对提测系统进行自动化的冒烟测试。

除了上面这三种层次的测试以外，对代码质量的检查，以及对分支管理的约束都在测试左移落地时所需要优化的方面内。

具体计划

1、左移的核心要点是，针对每个UserStory，要开发（测试开发）给出全流程的自动化测试方案，工作量要在版本规划的考虑，开发、测开都要参与
2、右移的核心要点是开发和使用监控工具，对生产的状况一目了然

测试左移和右移，不单是指测试人员工作量转移到各个阶段，更准确说是 将测试的概念提高到软件质量控制，涉及整个软件周期，这就需要产品、开发、测试、运维人员均参与进来。

• 在需求阶段，就需要对用户提的需求做测试，发现其中不合理处及时反馈。
  （在泰州时了解到，业务方很多需求是可以灵活变通的，但是如果没有得到反馈，他们就会默认需求是合理的）

• 在设计阶段，需要重视设计评审，除了考虑功能设计外，也应考虑代码的可测性等。
  （例如接口设计中，如果响应结果应包含足够多的信息，编写自动化接口测试时就不在需要再从数据库中去查询相关信息。这样只关注接口的请求与响应，而无需了解底层数据库表的设计，有助于搭建一个简洁通用的接口测试平台）

• 在开发阶段，开发完善单元测试的同时，测试、测开已经可以根据接口文档进行接口测试代码及用例的编写工作。在完成开发后，可以直接用已经编写好的接口测试来跑冒烟。
  （如果有测试平台，则直接在平台填写用例，不用编写代码，甚至可以考虑由接口文档自动生成测试用例）

• 发布上线后，监控线上数据，及时发现生产环境暴露出的问题。

测试右移

如下图所示，当持续测试真正的落实下去之后，测试这一阶段会从我们的产品开发流程中隐去，因为我们不再在一个特定的时间段对产品进行测试，而是在每一个阶段都会对产品进行测试。

本质上，测试左移和测试右移都是为了达到在每一个阶段进行测试这一目的，但是两者的落地方式和方向以及造成的影响完全不同。

测试左移通过将原测试阶段部分工作（检验版本与需求的一致性，功能的完整性等）左移到前面的阶段来完成，也更符合 TDD 的思想，在设计和开发之前，先有测试。最后的直接影响是提测版本的完成度提高（一个工作只有经过测试才算真正完成），原测试阶段所花费的时间变少。而测试右移则不同

测试右移的横轴

测试右移的横轴和测试左移不同，测试左移的横轴是 [ 计划 -> 设计 -> 开发 -> 测试 -> 上线 -> 运营 ] 这一系列围绕工作目的不同的阶段，而测试右移则不一样，测试右移聚焦的是版本的完成度，通过把测试工作转移到更高完成度的版本，能够获取到开发阶段无法获取到的信息（真实用户反馈、真实数据统计、真实环境状态），使得测试工作更全面更深入。

测试右移的目标

通过将测试动作在完成度更高的产品版本（聚焦点是版本的完成度，不限定于真实环境）上执行，能够做很多之前原测试阶段无法完成的测试

• 真实的用户监控，以提高用户体验和性能（数据统计、数据分析）
• 非功能性需求测试（性能测试、压力测试、安全测试等）
• 监控及告警
• 真实环境过山车测试-- 蓝绿部署
• A / B 测试 （视觉测试、响应式测试等）
• 金丝雀发布

如何落地

事实上上面所说的一系列需要做的测试，最大的问题是缺乏一个统一且循序渐进的落地计划，所以在落地计划中，如何“循序渐进”是一个很重要的问题。

落地措施

所以落地计划会根据具体工作的优先级、难易度和当前团队的积累情况来进行排序和计划。具体顺序如下：

• 生产环境监控及告警
• 真实环境过山车测试（蓝绿部署）
• 非功能性需求测试（性能测试、压力测试、安全测试等）
• 真实的用户监控、A / B 测试、金丝雀测试