背景
接口测试过程中，我们使用 Jacoco 采集了执行 case 过程中的代码覆盖率。但是在实际工作过程中，依然会遇到某次修改代码变动的代码覆盖率已达 100%（行覆盖率、分支覆盖率均达到 100%），测试用例通过率也完美的达到 100%，但是依然产生了严重的线上 bug。
过程介绍
在敏捷开发过程中，为了进行快速、精准地进行测试，简单介绍我们工作方式：
- 开发提测后我们通常都会快速检查开发代码变动；
- 根据代码变更评估开发代码变动影响范围，针对性的设计测试用例；
- 执行用例，检查用例覆盖率。
- 当代码变更较大时，我们会在 master 分支回归测试一遍；
- 上线过程中检查代码代码是否包括未经测试的代码；
- 线上验证
为什么会这样？
虽然我们关注了代码变更、代码覆盖率、case 通过率，测试用例通过率 100%、变更代码的代码覆盖率甚至达到 100%。但是由于测试人员、开发人员疏忽，依然可能导致验证的线上问题。
简要分析一下问题原因：
（1）测试用例执行后的测试结果准确率不是 100%
借用下图解释问题产生的部分原因：
根据上图我们可以发现，对于一个用例通过率 100% 的测试用例集，用例执行结果的准确率可能并不等于 100%，这是问题产生的一个重要原因。
（2）变更的代码潜在影响其他未变动的代码
某次代码变更缩略图如上所示，图中开发新增了一个 sql 片段，与相邻代码的 sql 片段字段相同，仅 where 条件有细微差异（图中标红的两部分），以便快速满足一个业务需求，但是上线后却产生了严重 bug。
最终分析原因是开发 copy 的 sql 语句缺少一个字段造成的，不影响任何变更的代码逻辑，而是开发同学将 sql 结果传给其他方法导致的问题。
（3）原来代码潜藏 bug（遗留 bug）
部分遗留代码中潜藏一些严重 bug，虽然开发代码变更没有引入新的 bug，但是某些情况下提高了原来遗留严重 bug 出现的概率，进而导致严重的线上 bug。
res = rpc.getData(req);
String total = res.getDataTotal();
......
String average = res.getDataTotal();
某需求调用了第 3 方接口，接口返回数据中包括多个金额字段。开发同学 copy 的代码中将 avarage 字段取值为 total，由于测试过程中本部分代码为遗留代码，测试过程中上述代码未变更，导致上线后将平均金额弄错了。
（4）问题原因不仅仅限于上述方面，虽然测试用例 100%+ 代码覆盖率 100%，依然可能产生严重的线上问题。
写在后面
测试覆盖率、测试用例通过率可以用来衡量测试过程与代码质量，测试过程中即便测试用例通过率 100%、代码覆盖率达到 100% 覆盖，依然需要坚守细心、耐心。
这个观点同意，测试覆盖率性价比最高是在 70% 左右，再多了其实差别不大，然后需要更多 code review 去发现问题。
你好牛逼哦
看到这个标题,我想到的是
不要迷信测试用例通过率 100%
- 无法证明某组用例的覆盖率是 100%
一个需求，张三写了 100 个用例，李四写了 50 个。 经过评审，张三的 100 个无冗余，均有效。李四的 50 个无冗余，均有效；李四的 50 个用例包含于张三的。李四要挨批评了，因为写少了不全面；那张三就一定写全了么？用什么方法可以科学的证明确实写全了？对于简单的问题，似乎全面是可以达到；如果是复杂情况，需要数学出手了，但是建模真不是容易的事情。
- 用例本身有问题，或者没有很好的被执行
不要指望评审过的用例就一定是对的；临时改需求/执行人员的粗心/随机 bug 等等。
人把路走完了，不一定是人的问题，可能路本身就是弯的
不要迷信代码覆盖率 100%
没做过白盒，白盒有白盒统计覆盖率的方法，应该可以到 100%
但是，没被很好只执行，或是方向是错的，也不会得到什么好的测试效果
白盒要跟黑盒放在一起使用；只关注代码不关注业务，就算测试覆盖率 确实是 100%，大家认真测试无差错；只开源不截流，难免最后还是受穷；
我只是感觉楼主的帖子写的逻辑有段混乱了，（1）其实相当于论点，在 (1) 的下面，需要具体举例； 可以和 (1) 并列的，也就是（2）（3），也该是论点，
但确是具体例子；（2）（3）可以认为是 覆盖率 100%，但是没有被很好执行的具体例子；或者是 测试人员认为该部分不需要测试，主观 100% 判断失误；
给我的感觉的是 (2)(3) 是脱离文章标题的东西；