测试左移及其相关实践

之前在《敏捷测试的核心》、《构建测试的体系化思维（进阶篇）》和《一页纸测试策略》等文章中提到过测试左移，但是没有专门针对这个主题做过系统的介绍，但又总是被社区朋友问到。本文旨在介绍测试左移及其相关实践，希望能够解答朋友们的疑惑。

01 什么是测试左移？

传统软件开发生命周期一般分为如下五个阶段：需求分析、软件设计、程序编码、软件测试和上线发布。其中软件测试是软件编码完成之后的一个独立阶段，通常由测试人员来负责完成测试相关工作。如下图所示，从左到右依次为上述五个阶段：

传统软件开发阶段

测试左移就是针对传统独立测试阶段而言，将测试活动左移到图中测试阶段左边的多个环节，对每个环节所做工作进行测试验证，以确保其正确性，如下图所示：

测试左移

需求分析环节的测试活动是为了保障需求的合理性，确保团队在做正确的事情；
设计环节的测试活动是为了保障设计的合理性，确保易于实现所期待的功能；
编码环节的测试活动是为了保障开发人员所写代码和所开发功能的正确性；
在测试环节还需要有相应的测试活动来对功能和非功能需求进行最后的验证和确认。

图中所示各个活动是从左到右按先后顺序排列的，因此测试左移也被称作测试前移。

注意：上图中的需求分析、软件设计、程序编码和软件测试等可能不再是非常独立的阶段，而是融合成为了整个开发阶段的一个环节而已。

02 为什么要测试左移？

有一条曲线，大家应该都不会陌生，那就是缺陷修复成本曲线：在软件开发生命周期中，越往后发现的缺陷，其修复成本就会越高，甚至到了后期会指数级增长。

缺陷修复成本曲线

而测试左移，主要就是为了获取快速反馈，以实现缺陷预防，降低成本。

1. 快速反馈

关于快速反馈，可以借助于玩游戏的体验来理解。在我们玩游戏的时候，每前进一步就能知道是成功了还是失败了。如果在软件开发中也能如此快速获取反馈，不仅能改善软件开发的体验，增加成就感；还能更及时发现偏离正确轨道的风险，尽早发现可能出现的问题。

因此，我们需要在测试阶段左边的每个环节去开展测试活动，实现测试左移。

2. 缺陷预防

如果能够全面统计一个软件产品的所有可能引起缺陷的地方，我们可以说该软件存在缺陷的总量是一定的。（当然，现实情况是我们不可能全面考虑到所有的因素，缺陷是很难穷尽的。）

如果这一定数量的缺陷中有一部分可以通过某些措施来预防，那么软件在测试或最终用户使用过程中所暴露出来的缺陷数量就会减少，这就是缺陷预防——减少暴露给用户的缺陷。

缺陷预防

软件开发过程是个持续递增的过程，预防缺陷也不是一蹴而就的事情，需要在整个软件开发过程持续地进行。因此，需要持续频繁地开展测试左移相关测试活动，预防缺陷，实现质量内建。

03 测试左移实践有哪些？

所有在测试阶段之前开展的相关测试活动都可以认为是测试左移的实践，它们包括但不限于以下活动：

需求澄清：

需求澄清需要团队多个角色协同参与，包括业务分析人员、测试人员（QA）、开发人员、技术负责人、技术架构师等。在《构建测试的体系化思维（基础篇）》中有关于QA在需求澄清环节所能做事情的详细介绍。

需求评审/用户故事评审（Story Review）：

需要开发和测试跟业务分析人员一起讨论确认需求，可能是正式的会议针对某个特性（大块需求）的评审，也可以是针对单个需求条目或敏捷用户故事进行线下评审。如果前期需求澄清过程中对需求的讨论已经比较透彻，这里的评审就会比较轻量级，由测试人员（开发按需参与）自行安排时间评审即可。

行为驱动开发（BDD, Behavior Driven Development）：

关于BDD，很多人误认为是一种测试方法，但其实BDD主要是为了三方更好地对需求达成一致认识，只不过通过BDD方式产生的需求能够很好地指导自动化测试的开展。更多详情，请参考我之前的文章《说起BDD，你会想到什么？》。

实例化需求（SbE, Specification by Example）：

SbE的核心思想跟BDD类似，但强调了一点要将需求描述通过实例来说明，以更好地发现漏掉的需求，让需求更完整、更容易被多方理解和澄清。

测试左移典型实践

QA/测试人员参与技术方案讨论：

主要基于两个方面原因：一方面，测试基于自己对系统的了解，可以给技术方案的讨论提供输入，比如系统重点需要考虑和关注的问题等，以帮助验证技术方案的可行性；另一方面，QA清楚了解技术方案，才能更好地设计相应的测试策略，更完备的进行测试。

用户故事启动（Story kickoff）：

在不同的语境下，也叫需求条目启动、开卡等。对于单个用户故事，在开发人员要开始编码前进行的再次澄清和确认，主要是确认其中的验收标准是否不够完备、是否大家都理解一致了。形式要求尽量轻量级，在开发人员电脑前完成即可，需要业务分析、开发和测试共同参与，时间一般不要超过15分钟。

用户故事桌面检查（Desk check/Shoulder check）：

跟启动是配对的，也叫需求条目验收、结卡/验卡等。同样在开发机器前面完成，一般由开发将功能演示给业务分析和测试人员，大家确认需求中的正向路径是否都已经开发实现了。更多详情可参考文章《高效用户故事验收》。

测试驱动开发：

TDD，常见的有单元测试驱动开发（UTDD）和验收测试驱动开发（ATDD），通过先写测试的方式驱动设计的完备性。Thoughtworks同事刘冉老师有多篇关于TDD的文章，请移步他的网站「刘冉的思辨悟」查阅参考。

代码评审：

Code review，也叫代码回顾。有团队成员聚集在一起做回顾的，也有独立线下评审的模式。伍斌道长的文章《Code Review: 超越“审、查、评”的代码回顾》有关于code review非常详细的讲解，请移步参考。

编写单元测试和接口测试等自动化测试：

根据测试分层理论，自动化测试可能包括单元测试、接口测试和端到端测试。通常单元测试是开发人员编写，而接口测试和端到端测试可以开发和测试协作完成。其中，通常建议单元测试和接口测试在用户故事开发环节完成，应该属于用户故事开发DoD的一部分。

测试评审：

测试评审一般发生在Desk Check环节，主要针对开发所编写的单元测试和接口测试等。详情参考文章《QA评审底层测试的价值》。

持续集成：

持续集成（CI）概念大家并不陌生，但是有效实施却不是那么容易。推荐参考Thoughtworks洞见文章《持续集成理论和实践的新进展》和《对于持续集成实践的常见问题的解答》。持续集成常见的反例有：
1. 光有持续集成流水线，但是流水线上啥也没有，没有代码扫描、没有自动化测试、没有质量门禁；
2. 流水线有接入代码扫描，但是扫描出问题没有及时修复；
3. 自动化测试没有在流水线上频繁执行，或者执行失败不能及时修复；
4. 代码没有频繁提交；
5. ……