什么是测试左移（Shift-Left testing）？
在《从测试左移到精准测试浅析》中提到了测试左移，本文从方法论层面借助Parasoft的实践总结介绍一下测试左移。
对于需求，代码，质量，效率，《代码大全》很早就从软件工程实践角度说明了一个bu*生的不同阶段，修复一个bug的成本从需求阶段，设计阶段，测试机阶段有着天壤差别。不仅从成本上，从修复难度，引入新问题的可能性，沟通成本，团队状态也会有很大的影响。
测试左移本质上是要尽早的发现，预防问题，使用必要的测试手段在软件开发周期的早些阶段发现问题。
01
为什么要左移？
Capters Jones 有个Global的效能和质量分析图，列出了常见的软件开发过程中defect发现的阶段，可以看到，大部分的问题在编码阶段引入。
编码阶段引入问题的原因可能是代码问题，需求理解问题，异常处理cover不到，集成阶段，多团队合作对接过程等。
然而，这些问题在生产过程中，都是在什么时候发现的呢？
在编码阶段发现的问题，几乎很少在编码阶段发现。
Bug的修复成本如何呢？
在集成阶段发现问题的修复成本是编码阶段修复成本的40倍！
造成修复成本高的原因有几类：
a. 出现一个线上问题，如何定位，多团队如何配合，如何确定根因？
b. 线上问题，集成问题，牵扯到多个模块，如何复现？如何模拟真实环境？多线程的场景？
c. 如何确定修复方案，谁来修，临时方案还是长久，是否是架构问题，多个模块都需要修复会增加再一次间接引入问题成本，修复会不会引入其他问题？
从不重视代码质量的第一天开始，就埋下了问题修复，定位的成本和修复问题再次引入问题的成本。
测试左移，测试early，often！
左移，需要一个重要的基础，工程习惯，SDLC成熟度，测试分层，持续集成，链路上延展发布的节奏，纵深上需要贴合业务的专精领域的深度探索，代码扫描（规范，问题，安全，异常等），CR， 代码提交行为分析，test double（mock ， fake， stub，dummy）， UT， 自动化，验收测试等。
左移需要工程效率具备不亚于研发的代码能力。
最近各公司都在探索在白盒扫描的实践，基于业务的规则定制，成本低，易于发现，容易定位。
需要注意的问题？左移不是要加重研发的工作量！
更早的发现问题是一方面，更重要的减少问题的数量，提升研发工程质量意识。
02
如何左移？
a. 代码扫描，单元测试，发现问题不是关键，关联是在质量意识的生态闭环中，不断减少存量问题，进而不断减少问题的发生。
b. 编码规范，工程标准（git 提交规范，上线规范，研发模式等），对于减少线上问题非常重要，在去年的一个bug分析专项中，通过bug分析，代码提交行为分析反推业务改进的专项中，在现版本迭代中，减少了56%的问题，有兴趣的可以单钉交流。
c. 引入test double，进而Continuous Testing， 上下游依赖，第三方服务，数据构造，做隔离，Mock（如阿里的doom）， Stub（常见的搜索回放），能够有效模拟场景，提升稳定性，降低数据准备的成本，方便模拟异常场景，简化问题定位。
在面临转型的时候，测试左移，夯实研发能力是一条重要的角度和突破，前路慢慢，需要共建，配合，不管是什么角色，只把问题留给合作方的都是耍流氓。
参考：
https://blog.parasoft.com/what-is-the-shift-left-approach-to-software-testingblog.parasoft.com