目前准备在持续集成系统中引入代码覆盖率工具（jacoco），在运行接口自动化后看代码覆盖率。
但坦白的说，这个功能引入就是为了完成点 KPI，因为对 “代码覆盖率” 的作用其实还是不太明白的（尤其对测试来说）
最能想到的是未覆盖的部分可以去分析下是否测试遗漏，但对于维护项目来说，测试覆盖点都是增量或修改需求点，那未覆盖的处会很多，那分析测试遗漏就不好搞了。
另外，就算代码已经覆盖，不代表这块代码就 OK，只是表示测试和开发都完成相同的需求点，都遗漏的需求点是不能靠代码覆盖率的。
来说下开发，这个可能对开发优化代码结构有些帮助，但对于我们的维护项目来说，有些老功能旧代码，覆盖不到的情况下，开发依然不敢去动...
其实担心代码覆盖率功能上去以后，最后只是测试报告中的一项展示型指标而已。
不知道，大家有没有这方面的落地实践及对应产出效果，可供参考?
同样存在疑问，求大神解答
理论上可以帮助完善用例质量，实际操作比较困难。
"但对于维护项目来说，测试覆盖点都是增量或修改需求点，那未覆盖的处会很多，那分析测试遗漏就不好搞了"
- 可以考虑采用增量的方案，只关注本次的变更是否都覆盖到了，虽然 “覆盖率高” 和 “质量好” 画不了等号，但增量（或者说变动代码）的覆盖率低可能说明确实存在遗漏的场景没有执行到，可以进行分析并决定要不要补充。
- 给测试人员及相关人员提供信心，有时候信心也是一个关键的要素，覆盖率高比覆盖率低总是要多一些信心，多一点信心总是好的。
个人拙见：
基于应用的覆盖率数据更多只是给了我们一个宏观的概念，比起没有覆盖率而言价值还是有，至少告诉了项目组经过这么多轮各种方法的测试哪些代码被有效执行过，但确实从最终质量保障出发，光这一点还是不够的。
我们的做法，可供参考
1、相同阶段的覆盖率结果进行 Merge，这样可以得出分阶段的覆盖率，比如冒烟阶段和功能阶段，关注点在增量代码覆盖上，回归阶段覆盖率关注点在全局覆盖上
2、针对未覆盖部分进行论证：是用例设计不足导致无法覆盖？那就补对应用例；是代码实现了一段永远都不可能执行到的逻辑？那就提醒开发人员需要考虑这段冗余代码是否有必要；
3、针对已覆盖的部分进行测试有效性评估，需要将每个 test case 和代码片段进行关联，因为我们是同城多活的双机房，所以我们选择了凌晨定时任务来执行自动化，并把每个自动化所覆盖的代码片段进行了关联，这样未来在新的版本中如果改到某部分代码时，会主动将历史上跟这段代码相关的用例进行触发，做到相对精准的测试回归
4、覆盖率分析是个长期且持久的工作，需要测试人员对特定应用有深刻的系统结构、业务的理解，需要一定的技术功底和入门门槛
5、清楚的知道覆盖率的弊端，因为真正上比较大的问题是出在开发压根没写的逻辑代码上。。。哈哈
蹲一个有这方面具体落地的最佳实践方案，上家公司也存在这种情况
听起来似有 B 格，实无卵用
好处：
１、 查漏补缺用例：通过分支覆盖率信息，获取测试的盲区，即一直以来没有测试用例覆盖到的地方。理论上这种情况应不多，如果发现大片业务代码未覆盖到，需反思测试过程哪里出了问题。据我们的实践案例，大部分情况下，是比较难摸拟的边界情况或比较偏的路径覆盖不到，此时，依需补充用例。
２、 找到适合组织的测试充分性评价：覆盖率客观数据。通过全遍历用例，得到代码覆盖率数据，如 75%，80%，90%，结合上市实际质量，找到团队做到多少的覆盖率是比合适的，即找到团队的参照值（标准值），为新项目的测试充分性判断找到一个合适的客观数据；
３、 识别可能的废代码。通过分析覆盖率数据，我们可以识别存在的废代码，如一些函数，已没有人调用（明显的代码孤岛）。曾推动开发人员优化掉，但开发人员一般情况不会去删除，原因怕删除后出问题，即使很明显的一些函数，也是觉得放着无误，这也导致越是时间长的项目越无人敢动，经过长时间的累积，代码行越来越多（冗肿），越难读。
不足：
１、 覆盖率高，并不代表质量好，但质量好定是覆盖率高；
２、 覆盖率的计算是单点的（某分支语句是否穿过的统计值），并没有上下文逻辑的串起来的场景数据，这是导致覆盖率高并不代表质量好的主要原因；
３、 分析覆盖率数据需分析代码，需耗测试人员大量时间，投入与产出比并不高；
建议：
找到团队的测试覆盖率标准值（测试充分性客观判断数据）后，有针对性地使用。
核心目标我觉得楼上已经说得比较清晰了，补充一个个人观点：
要用好代码覆盖率，前提是对代码的变更内容以及被测系统有比较高的熟悉度，最好是结合 code review 进行，便于测试人员在熟悉代码的基础上，确认自己有哪些部分的代码还没有运行到，辅助补充用例场景。覆盖率本身最强大的不是这个，而是建立起用例和代码的有效关联关系，作为后面进一步的 基于变更内容推荐所需的回归用例集 的基石。
如果团队对代码熟悉度还不高，还没有深入到技术方案评审 + 开发变更代码 review 的程度，或者周期短时间紧对质量要求没那么高，那其实都不大适合引入覆盖率。容易只解读覆盖率指标，而不去实际看代码，而且还额外增加了熟悉代码的负担。
“建立起用例和代码的有效关联关系，作为后面进一步的 基于变更内容推荐所需的回归用例集 的基石”，这个思路是很好的，目前业界经常讲的 “精准测试” 便是如此，这需要另外的工具支持，不知大家是否有这方面的实践，类以精准测试中的 “数字滤波器”，如果能有一个系统（软件工具）当遇到代码变更，及时提示影响到的用例，会是一个好的方式。这个没试过。有实践过的同学，可分享一下哈。
谢谢大家的分享：
我看下，代码覆盖率使用的可操作确实不是很强，但以下部分可以尝试：
1-各个版本增（变）量的的代码可以尝试代码覆盖率，测试可以进行用例的对应逻辑的查漏
2-染色代码和对应接口进行关联（需要找到可用工具或方案），可以进行后续代码变动自动关联测试接口脚本测试
JoyMao
回复
for (i=0;i<testcase.max;i++){
"夜深人静之时，exec autotest case，每执行 pass 一条通过 jacoco cli 获取一次报告数据，insert db“
}
看了一下大家的讨论，感觉对覆盖率的理解不够全，或者比较片面。代码覆盖率只是一个基础，反映你的测试用例执行到了哪些代码。以这个为基础，可以做调用链路分析，自动化和手工用例与代码的关联，代码和用例之间的追溯关系，用例智能推荐，diff 代码的自动化回归，测试质量评估等一套东西，对应的就是精准测试体系。
爱偷懒的QA
回复
感谢大佬的补充。
但目前的现实是：道理都懂，但实践上无所适从。
所以想先听听大家的想法和经验，先从一些好实践的地方入手来看看。
JoyMao
回复
15 楼提到的基于覆盖率的精准测试建设，网上有很多来自大厂的成熟经验，搜一下就有了，甚至很多具体的技术思路也有一些呈现。
搜着去看一看，应该就能对 “覆盖率” 这个东西新的理解，当然技术归技术，其实后续的运营会更重要（个人感觉）。
