测试左移一词（shift-left testing）可能最早出现在测试行业大佬Arthur Hicken的博客里，在他的博客中提到了测试左移的看法。他提到bug的产生，其中85%的缺陷产生于编码阶段，这是可以预期的：
无论是开发编码错误，或者对需求理解有误，或者没有遵守特别的代码规范等等，各种原因，无可否认都会在编码阶段引入缺陷。
尤其是如果将各个应用组合在一起时，缺陷也会被引入到应用中，尤其在涉及到多团队配合时。（譬如目前流行的微服务架构）。
那么这些缺陷什么时候能被发现呢？请观察下面一张图中橙色的折线：
看起来就很因吹思婷了，因为在第一阶段（coding）时几乎很难发现缺陷，当然，这在目前研发流程中也是常见的，因为一般测试都是从单元测试阶段（unit test）甚至功能测试（functional test）才开始介入的。两张折线对比就能很明显发现，缺陷大部分在编码阶段被引入，却几乎没有被发现！！！
那么解决缺陷的成本是多少呢？下面这张图会让人们非常惊讶：
编码阶段修复缺陷的成本与编码本身成本相当，这很容易理解。但是在研发迭代周期中，缺陷发现的越晚，修复的成本将会急剧增加。譬如功能测试阶段修复缺陷的成本是10倍，系统测试阶段则是40倍，实际部署阶段剧增到640倍的成本，真的是可笑又可怕。举一个真实案例，当年微软的windows系统某版本发布时，因为一个ui bug在oem阶段才被发现导致数百万张光盘被迫收回并销毁，损失至少千万美元，而这个ui bug如果在coding阶段发现的话，可能只需要几秒钟就能修复！！！
大佬Arthur Hicken认为有以下原因导致成本上升：
跟踪问题所需的时间和精力。 测试用例越复杂（越大），就越难确定哪个部分是真正的缺陷原因。
由于引入了诸如数据库或第三方API之类的相关系统，在开发人员的电脑上则很难将缺陷复现。（在这种情况下，组织在缺陷检测和缺陷修复之间通常会经历数周的延迟。）
修复缺陷所需的更改的影响。 如果是简单的错误，那就没关系了。 但是，如果您在很多地方都做过此事，或者使用了错误的框架，或者所构建的代码的可伸缩性不足以承受预期的负载，或者无法确保代码的安全性...
笔者理解，其实不需要罗列很多成本上升的原因。因为在长久的研发过程中，所有it从业者或多或少都会有自己的心得体会。
因此Arthur Hicken大佬提出了一种测试左移的方法论，尽早尽可能多的介入测试。这样做的好处就是将尽可能多的缺陷提早发现，基于缺陷修复成本曲线，这些缺陷发现的越早组织消耗的成本越少。实践这些的前提是，组织具有成熟的研发体系，比如完善的单元测试架构。
有些组织左移到了单元测试就停止了，但是如果可以进一步左移到编码阶段，其实能够获得更高价值， 毕竟，这是引入错误的地方。因此，如果组织能让在开发仍在进行的同时就开始寻找它们（缺陷），这就是组织从静态代码分析中受益的地方：通过查找最左侧的缺陷来修复缺陷。
通过静态分析，可以在实际的编码阶段开始寻找错误，这时发现错误的成本将尽可能降低。可以清楚地看到的那样，在“测试”开始之前先找到东西是最具成本效益的。 这也是最省时的方法，因为它不会使开发人员在尝试重现错误或理解故障方面有任何问题。 能够将缺陷修复周期从数天或数周缩短到数小时或数分钟。
看完点个赞呗，难道想白嫖不成？更多内容请访问微信公众号 ：三国测，扫码关注哟！
