用来衡量测试的充分性和完整性，从广义的角度来讲，测试覆盖率主要分为两大类
- 面向项目的需求覆盖率
- 偏向技术的代码覆盖率
需求覆盖率
定义：指测试对需求的覆盖程度，通常的做法是将每一条分解后的软件需求和对应的测试用例建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求
现状：需求覆盖率统计方法属于传统瀑布模型下的软件工程实践，已经很难适应当下的敏捷开发实践了
应对：所以现在很少直接基于需求来衡量测试覆盖率，而是将软件需求转换成测试需求，然后基于测试需求再来设计测试点
now：现在人们口中的测试覆盖率，通常默认指代码覆盖率，而不是需求覆盖率
代码覆盖率
定义：简单来说，是指至少被执行了一次的条目数占整个条目数的百分比
语句覆盖：已经 被执行到的语句 占 总可执行语句 的百分比，要求最低的覆盖率指标
判定覆盖：又称 分支覆盖 ，度量程序中每一个判定的分支是否都被测试到，即每个判断的 取真分支 和 取假分支 都要覆盖一次；比如，对于 if(a>0 && b>0)，就要求覆盖“a>0 && b>0”为 TURE 和 FALSE 各一次。
条件覆盖：判定中的每个条件的结果TRUE和FALSE是否都被测试到了；比如，对于 if(a>0 && b>0)，就要求“a>0”取 TRUE 和 FALSE 各一次，同时要求“b>0”取 TRUE 和 FALSE 各一次。
代码覆盖率的价值
统计代码覆盖率的根本目的是找出潜在的遗漏测试用例，并有针对性的进行补充，同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码。
通常我们希望代码覆盖率越高越好，说明测试用例设计时充分且完备的；
但实际情况是，随着代码覆盖率提高，测试成本也会迅速增加；所以在企业中，一般只有单元测试阶段对代码覆盖率有较高的要求
代码覆盖率的局限性
即使设计的测试用例已达到100%的代码覆盖率，软件产品的质量也是做不到万无一失的
根本原因是：代码覆盖率的计算是基于现有代码的，并不能发现那些 未考虑某些输入 以及 未处理某些情况 形成的缺陷
显然，代码覆盖率反映的仅仅是已有代码的哪些逻辑被执行过，哪些逻辑未被执行；依此依据去补充用例测试那些还未被覆盖到的执行路径
总的来说：高的代码覆盖率不一定能保证软件质量，但是低的代码覆盖率一定不能保证软件质量