Martin Fowler（重构那本书的作者）曾经写过一篇博客来讨论这个问题，他指出：把测试覆盖作为质量目标没有任何意义，而我们应该把它作为一种发现未被测试覆盖的代码的手段。
代码覆盖率的意义
1.分析未覆盖部分的代码，从而反推在前期测试设计是否充分，没有覆盖到的代码是否是测试设计的盲点，为什么没有考虑到？需求/设计不够清晰，测试设计的理解有误，工程方法应用后的造成的策略性放弃等等，之后进行补充测试用例设计。
2.检测出程序中的废代码，可以逆向反推在代码设计中思维混乱点，提醒设计/开发人员理清代码逻辑关系，提升代码质量。
3.代码覆盖率高不能说明代码质量高，但是反过来看，代码覆盖率低，代码质量不会高到哪里去，可以作为测试自我审视的重要工具之一。
黑盒系统测试的困境
测试的工作产出相对于研发并没有那么直观，测试过程中经常会有一些针对质量与效率的灵魂拷问，作为测试如何才能把工作做的又快捷，又精准，剥开这个黑盒的掩盖，我们在做功能测试的时候如果能看清楚哪些代码是走到的，哪些代码是没有走到，这样不但可以减少重复无用的盲目测试，而且也可以提升测试精准性。
聊到这里有的同学可能会想到自动化测试，为什么不通过自动化测试来增加业务覆盖呢，自动化测试作为一把双刃剑，当脚本数量达到一定程度一定会带来维护成本的增加，反而会拖累整个测试团队的效率，自动化测试我们会优先考虑核心业务场景的覆盖，让自动化测试成为一个防弹马甲，而不是一个全身防护的装备。
系统测试应用增量代码覆盖率
谈到代码覆盖率我们一般会想到单元测试，覆盖率一般会从包、文件、类、代码行的维度去监控。按照测试分层的理论，集成测试属于UI这边层面的，这一层处在塔尖，覆盖率是最小的，如果想在一个版本测试中实现全量的覆盖率监控，那无疑是一个实现不了的愿景。
既然实现不了全量，那能否实现增量的，我们假设master的分支（生产线上运行的分支）是全部覆盖过的，可不可以把焦点放在增量代码上呢，我们只关注release分支跟master分支git diff之后的代码变更呢？
由于我们增量代码覆盖率监控依赖的开源项目jacoco，覆盖率是只针对java问题才有的，所以我们按照如下的策略来对代码进行增量的对比。
增量代码对比出来之后我们只需要在覆盖率解析环节只显示增量代码的覆盖率，我们就可以轻松的监控到系统测试过程中的代码覆盖情况。如下是基于jenkins pipline的实践案例。
基于jenkins的实现相对来说还是比较粗糙的，感兴趣的小伙伴可以按照如下思路在测试平台来实现代码的实时染色。
