测试如何左移
之前一直听人提起“测试左移”这个概念，不过我对这个词的理解一直停留在字面意思：早一点介入测试。但是我的这个理解对不对，为什么要“测试左移”，测试如何左移，我一直没有搞明白。
最近业余时间比较多，所以今天打算彻底搞清楚这个概念。本文从以下3个方面尝试阐述这个问题：
什么是测试左移？
为什么要测试左移？
测试如何左移？
如果你对这三个问题比较感兴趣，可以继续往下看：
01
什么是测试左移
传统的软件开发方法（又称瀑布式）是一种阶段门限式的开发流程，测试一般都是靠近流程的右侧，下面的2张图是我在网上随便找的，测试都在倒数第二个阶段：
测试左移顾名思义，就是将测试实践向左移至软件开发生命周期的早期，尽早测试。
02
为什么要测试左移？
1、绝大部分缺陷都是在编码阶段引入的
《Applied Software Measurement》一书曾经做过统计，编码阶段大概会引入85%的缺陷：
编码阶段引入缺陷的原因可能是代码问题，需求理解问题，异常处理cover不到，集成问题，多团队合作对接问题等。
2、传统的开发方式，缺陷要等到测试阶段才能被发现
传统的瀑布式的开发方式，测试一般都是在软件开发流程靠后的位置才开始的，所以在编码阶段引入的问题，几乎很少在编码阶段发现，大部分都是在测试阶段才被发现：
3、缺陷发现时间越晚，修复成本越高
《Applied Software Measurement》一书指出，在系统测试和发布阶段出现的缺陷，修复成本是编码阶段的40和640倍：
Ponemon Institute 2017年的一份研究报告也指出，在测试和生产阶段发现问题的修复成本是编码阶段修复成本的12和95倍：
虽然这两份资料给出的数据有一些差别，但是我们依然可以看到，越靠近流程的右侧，修复成本就越高。造成越往右侧修复成本越高的的原因有这么几种：
定位困难（尤其是需要多团队配合的问题）。
复现困难（模拟真实环境，多线程场景等）。
修复困难（谁来修，使用临时还是长久方案，修复会不会引入其他问题）。
等等……
题外话：虽然越靠近右侧修复成本越高，但是出于某些原因（如获取真实用户反馈、在真实环境中测试稳定性和性能等），我们也还是需要刻意在生产环境做一些测试的，这可以通过A/B测试、在线监控、数据埋点、流量回放、全链路压测等方式来实现。
既然越往后修复成本越高，那我们要怎样让我们的测试左移，尽早地发现缺陷呢？
03
测试如何左移？
关于测试如何左移，我们可以通过以下4种方式来实现：
1、改串行工作方式为并行工作方式
1986年竹内弘高、野中郁次郎发表了一篇论文《The New New Product Development Game（新新产品开发游戏）》，这篇文章第一次提到了Scrum这种管理方法，后续的Scrum敏捷方法借鉴了这个名词，但是这篇文章中的Scrum，和后续Scrum敏捷方法的Scrum还不是一个概念，这里需要注意下。
下面是论文节选：
旧的开发方式中，产品开发过程如同接力赛一样，一组功能开发专家将接力棒传给下一组。项目从一个阶段到另一个阶段一次完成：概念开发、可行性测试、产品设计、开发过程、试生产和最终生产。在这种方法下，职能是专业化和分阶段的：营销人员在开发产品概念时审查顾客的需要和看法；研发工程师选择合适的设计方案；生产工程师实现这个设计；其他专家会在比赛的不同阶段，传递这个接力棒。
在Scrum方法下，产品开发过程中多学科团队不断互动，从始至终一直在一起工作。该过程不是在定义好的、高度结构化的阶段中进行的，而是在团队成员的相互作用下产生的（如上图）。例如，一组工程师可能会在可行性评估（阶段2）的所有结果出现之前就开始设计产品（阶段3）；或者团队可能会因为后续阶段的因素而被迫重新考虑某个决定。然而，团队的工作并未停滞，而是会持续进行迭代实验。这个过程甚至会持续到开发过程的最终阶段。
所以要想把测试左移，一个简单的方法是把瀑布式的、串行的工作，改为并行的、交叠的过程，这样测试人员就可以更早的介入测试工作了。
2、增加单元测试的投入
相信大家都看过类似这样的“测试金字塔”：
单元测试是一种投资回报率更高，且消耗时间精力更少的一种测试方法，并且在下述流程中，单元测试也是在功能测试和系统测试的左侧，它可以更早地进行测试：
根据上图中的统计信息，单元测试时发现缺陷的修复成本依然是比较小的，并且由于单元测试的执行成本非常低，不仅可以做到“尽早测试”，还能做到“经常测试”。
如果我们按照“测试金字塔”的方式建设好单元测试的能力以后，我们发现缺陷的时间就会左移：
3、编码阶段发现错误
一些公司可能做到第2步就结束了。但是如果当我们进一步向左推进，去寻求优化编码本身时，我们将获得更大的价值：因为这里是引入缺陷的地方，同时也是修复缺陷成本最低的地方。
在测试开始之前发现并修复缺陷不仅是成本最低，而且也是最省时的，因为这时开发人员可能刚刚写完相关代码，他们不需要花时间去回忆代码的逻辑。他们往往能够将缺陷修复周期从几天或几周缩短到几小时甚至几分钟。
那我们怎样做到在编码阶段就能发现错误呢？具体实践有：静态代码扫描、代码评审等。
4、编码之前避免错误
以上的方法，都是强调要提早发现缺陷，其实我们可以更追根溯源地思考一下，我们有没有办法减少缺陷？
使用静态代码扫描、单元测试等实践，可以帮助我们在流程的早期识别和预防缺陷。但是我们的终极目标不是发现缺陷，而是减少缺陷的发生：
帮助我们减少缺陷的实践有：TDD、ATDD、BDD、实例化需求等。
好了，测试左移的知识就介绍到这里了，如果你有什么疑问，欢迎留言讨论！
参考资料：
https://hbr.org/1986/01/the-new-new-product-development-game
《Applied Software Measurement》，CAPERS JONES
https://www.bmc.com/blogs/what-is-shift-left-shift-left-testing-explained/
https://www.stickyminds.com/article/shift-left-approach-software-testing
https://cloud.tencent.com/developer/article/1872001