什么是测试左移

在传统的软件研发周期中，有个比较著名的模式叫“瀑布模式”，在这个模式中，项目周期被清晰的分为“制定计划->需求分析->软件设计->程序编码->软件测试->运行维护”等六个基本活动。

并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。如果我们看上面从左到右的顺序，测试阶段就是软件生命周期中的一个特定阶段，并且这个阶段处于比较靠右的一个阶段（如上图软件测试在第五个阶段）。

随着时代的进步，人们慢慢意识到软件测试的重要性，并且“靠右”的软件测试阶段发现的缺陷修复成本会非常高，戴明曾提出“问题发现得越早，修复的成本越低”，有数据指出85%的缺陷都是在代码编码阶段引入的，然而大部分的缺陷并不是在编码的时候发现的，而是在之后的测试阶段发现的，甚至是已经上线后。而且随着越往后发现缺陷，修复的成本也越高。

在《The Shift-Left Approach to Software Testing》中提出，假如在编码阶段发现的缺陷只需要1分钟就能解决，那么单元测试阶段需要4分钟，功能测试阶段需要10分钟，系统测试阶段需要40分钟，而到了上线之后再发现可能就需要640分钟来修复，这可以说是很难让人接受的。

于是，软件行业出现了变革，从研发完成后测试才介入的方式，变成从制定计划，需求分析的阶段测试就开始参与进入，从“链条”上看，测试的工作“左移”了。测试左移也就意味着不是在最后阶段进行测试，而是一直持续测试。

如何做到测试左移

要将传统的测试阶段，移至左端的制定计划、需求分析、软件设计、程序编码阶段中，然后相关人员参与相应活动，这里的相关人员主要指测试人员和开发人员（因多数公司组织情况和篇幅等其他原因，仅指出这两种角色）。

对于测试人员而言，需要在项目初始阶段尽早参与，了解项目的需求并和业务人员进行沟通彼此达成共识，也为测试策略及工具等提前准备。测试人员需要参加设计评审会议，需求分析等会议，理解产品设计和结构，识别设计缺陷，建议不同的设计选项，相应的分解设计创建测试场景，要和开发人员紧密合作，除了口头上的及时共同澄清，还需要指导开发人员编写单元测试，也可在用户故事上提供测试场景、意见和反馈等供所有相干人了解查看，预防缺陷，达到预防效果。

对于开发人员而言，要提高自测意识，借助单元测试或者质量分析工具等提升质量，在编码阶段应开展相关活动，如TDD、结对编程，以及长期和坚持开展代码的review活动等，代码的监视活动不单是可以提升代码质量预防缺陷的产生，还可以提升开发人员的编码能力及意识。

总之，测试左移的原则就是测试活动在软件开发周期早期的各个阶段都开展进行，以保障各个阶段的活动都是“安全可靠”的。

实践方法

基于上面的分析，测试左移的具体实践活动和方法大致如下，每个组织也可需要根据实践情况进行裁剪和调整。

制定计划

在项目的规划设计上，建议测试和开发人员都参与，并共同输出设计规划。以软件开发平台 DevCloud 为例，可以通过项目管理中的规划进行需求的计划和设计。项目管理根据常用的规划方式提供了甘特图、思维导图两种。

需求分析

在澄清需求时，测试人员、开发人员和产品负责人等干系人应共同进行需求分析，彼此达成共识。以软件开发平台DevCloud 为例，在描述信息和评论中进行需求的澄清和记录。

设计测试用例

需求分析澄清后，测试人员在测试用例设计开发工作上，设计测试用例，完成测试代码的开发、测试数据的准备，并及时与开发人员沟通软件接口，确保测试代码能够成功驱动业务代码。以软件开发平台DevCloud 为例，可以在User Story下关联相关的用例。

并在用例中填写前置条件、测试步骤、预期结果等相关信息。

编码提交

需求分析澄清后，开发人员根据分析后的功能、验收标准等，以TDD的方式开始开发工作，当代码开发完成或以其他原则结束后，提交代码到代码仓库，由相关人员对代码进行评审，以DevCloud为例，代码提交采用合并请求的方式，可由一人或多人参与代码的评审，根据情况给出评审意见，最后完成代码的合并提交。

软件测试

当开发人员完成功能开发后，测试人员开始功能测试活动，若发现bug，及时沟通，并协助定位bug。以DevCloud为例，可以通过创建Bug的工作项和User Story关联，以完成测试的执行和分析工作。

当开发修复完bug后，可以对所有代码进行完整的回归测试。在DevCloud中，可以通过单独运行测试套件完成回归测试，或者流水线完成全量的接口测试以实现回归测试。

此外，DevCloud作为一套完整的DevOps工具链，当代码进行集成时，可以通过流水线的能力实现持续集成和测试的能力。当代码提交后，触发流水线中的集成阶段，完成集成的测试工作，集成测试以接口测试为主，可以通过DevCloud中的接口测试得以实现。具体如下：

写在最后

有句话说道：“质量是设计出来的，而不是测出来的。”这其实就是在追根溯源bug的产生，因为只有知道了其根源才可以行之有效的解决这一问题。因此要将测试左移到软件最初的设计阶段，并贯穿整个研发活动的始终。