测试左移

在 2001 年,Larry Smith 在他文章《Shift-Left Testing》中正式提出了测试左移的概念和相应的实践，但其实早在V模型建立的时候，就已经体现了测试左移的理念，V模型正是基于该理念对传统的瀑布模型进行的改善。

根据Capers Jones在《Applied Software Measurement : Global Analysis of Productivity and Quality》中提出的软件缺陷引入时机、发现时机和修复成本的统计图可以看出:

发现和修复缺陷的时机越早，修复缺陷所付出的成本越低。

由此可见，把测试活动左移，尽早的测试介入是有现实意义的。

在整个软件生命周期都可以使用该理念来指导测试的介入时机

从广义来看，所有提早进入测试阶段的操作都可以被称之为测试左移，包括测试参与的各项评审，但从现有的实践来看，推进比较成功的有以下两类：

1. UTDD（Unit Test Driven Development，单元测试驱动开发）

- 可以看成是单元测试的左移，在编写业务代码之前完成单元测试代码的编写

- 可以参看相关词条“测试驱动开发”

2. ATDD（Acceptance Test DrivenDevelopment，验收测试驱动开发）

- 与此相似的实践包含BDD（Behavior Driven Development，行为驱动开发）和RBE（Requirements By Example，需求实例化）

- 可以看成是验收测试的左移，把验收测试的用例逻辑提前到需求阶段完成

- 可以查看相关词条“行为驱动开发”

从实践来看，不管是UTDD还是ATDD，一方面帮助开发工程师提前理清代码逻辑，避免了部分缺陷的产生，另一方面也可以在缺陷产生后快速、精准的修复缺陷，有效的降低了修复成本。

同时，测试左移后会积累一定的自动化用例，同时也更容易构建持续集成/持续测试，可以有效节省测试工程师投入在基础功能上的测试时间，让测试工程师可以投入更多的时间到探索性测试中。

Q:测试左移是不是意味着测试工程师左移，以后的单元测试可以由测试工程师来编写了？

A:测试左移一定会带来测试人员的左移，相关测试工程师会在团队中成为更加重要的一环，尤其是在需求分析阶段，但作用主要体现在深入分析和拆解需求、保证验证准则和用例设计的正确性上，不管是从成本还是效果上考虑，单元测试代码还是建议由开发工程师进行编写。

Q:测试左移后是否可以不再需要原有的测试阶段？

A:测试左移后并不能取代原有的测试阶段，需求阶段和单元测试的用例并不能覆盖所有的测试路径，但测试工程师可以把精力更多的投入到探索性测试中。

Q:公司没有TDD/BDD等实践，作为测试工程师，如何贯行测试左移的理念？

A:测试左移的核心思想其实是测试更早的进入软件生命周期的各个环节，作为测试工程师，即使在公司不存在TDD/BDD等实践，也可以通过积极介入需求分析，概要和详细设计评审，单元和集成测试用例评审等方式更早的把测试逻辑提前体现到各个环节中，消弭缺陷于无形。

1. Shift-Left Testing Larry, Smith，2001

2. The Shift-Left Approach to Software Testing Arthur Hicken，2018