以前面试的时候，两次被问到同一个问题，“你是如何计算测试覆盖率的？”，但每次回答都不好，直到最近看了一些文章，有所感悟，总结如下：

1 定义
测试覆盖率通常被用来衡量测试的充分性和完整性。从广义角度讲，测试覆盖率分为：一、面向项目的的需求覆盖率；二、偏向技术的代码覆盖率；

需求覆盖率：指测试对需求的覆盖程度，通常的做法是将软件需求分解成多个测试任务，通过计算完成的测试任务，来得出需求覆盖率；

需求覆盖率统计方法适用于传统瀑布模型下的软件工程实践，传统瀑布模型追求自上而下的制定计划、分析需求、设计软件等等阶段，但是越来越多的互联网项目采用敏捷开发或者快速迭代；因此越来越少的项目直接计算基于需求的测试覆盖率

2 代码覆盖率
现在人们口中的测试覆盖率，通常默认指代码覆盖率，而不是需求覆盖率
一般来说，代码覆盖率是指，至少被执行了一次的条目数占整个条目数的百分比。
如果“条目数”是语句，对应的就是代码行的覆盖率；如果“条目数”是函数，对应的就是函数覆盖率；如果“条目数”是路径，那么对应的就是路径覆盖率。
那这里，我们来看看最常用的三种代码覆盖率指标。
1、行覆盖率，又称为语句覆盖率，指已经被执行的语句占总可执行语句（不包含代码注释、空行、头文件声明等）的百分比。这是最常用也是要求最低的覆盖率指标；

2、判定覆盖，又称分支覆盖，用以度量程序中每一个判定的分支是否都被测试到了，即代码中每个判断的取真分支和取假分支是否个被覆盖至少各一次。e.g. 对于 if（a>0 && b>0），需要覆盖a>0 && b>0为Ture和False各一次；

3、条件覆盖，是指判定中的每个条件的可能值都取一次。e.g. 对于 if（a>0 && b>0），需要“a>0”取TRUE和FALSE各一次，同时要求“b>0”取TRUE和FALSE各一次。

代码覆盖率的价值
1、现在很多项目都在单元测试或集成测试阶段统计代码覆盖率，但是需要指出的是，统计代码覆盖率的目的是检查当前测试的覆盖面，帮助我们补充用例，来覆盖更多必要的场景，从而保证软件的质量。

统计代码覆盖率的根本目的是找出潜在的遗漏测试用例，并有针对性的进行补充，同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码。

通常我们希望代码覆盖越高越好，因为这意味着测试用例设计充分，覆盖面足够广，但是测试成本会随着代码覆盖率的提高迅速增加。

因为需要大量的桩代码、Mock代码和全局变量的配合来控制执行路径，所以提升代码测试覆盖率需要很大的成本。

代码覆盖率的局限性
是不是代码覆盖率到了100%，软件质量就真的OK了？结论并非如此，其根本原因在于，代码覆盖率的计算是基于现有代码的，并不是那些未考虑的输入或者未处理的情况形成的缺陷。举个例子来说，产品设计了一个需求，该需要被剖析成3个研发点，由于某些原因，开发忘掉了一个（代码没写），那即便代码覆盖率到了100%，是不是还是有缺陷？（功能都没有实现完整）
总结来说，高的代码覆盖率不一定能保证软件的质量，但是低的代码覆盖率一定不能保证软件的质量

前面说了，代码覆盖率一般在单元测试或集成测试阶段做，笔者未从事过单元测试和集成测试，因此并未实际使用过代码覆盖率工具。所以后续简单记录，以便后续学习。

代码覆盖率工具
jacoco，Java代码主流开源覆盖率工具。

代码覆盖率工具的实现原理
实现代码覆盖率的统计，最基本的方法就是注入。简单的说，注入就是在被测代码中自动插入用于覆盖率统计的探针代码，并保证插入的探针代码不会给原代码带来任何影响。

总结
测试覆盖率通常被用来衡量测试的充分性和完整性，包括面向项目的需求覆盖率和更偏向技术的代码覆盖率。而需求覆盖率的统计方式不再适用于现在的敏捷开发模式，所以现在谈到测试覆盖率，大多是指代码覆盖率。
但是，高的代码覆盖率不一定能保证软件的质量，因为代码覆盖率是基于现有代码，无法发现那些“未考虑某些输入”以及“未处理某些情况”形成的缺陷。
另外，对于代码覆盖率的统计工具，我希望你不仅仅是会用的层次，而是能够理解它们的原
理，知其然知其所以然，才能更好地利用这些工具完成你的测试工作。