覆盖率--是度量
测试完整性的一个手段， 其实就是度量软件的质量，从设计质量方面考虑覆盖率
测试覆盖是由测试需求和
测试用例的覆盖或已执行代码的覆盖表示的。
质量是对测试对象（系统或测试的
应用程序）的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上。
两种评测方法
基于需求的和代码的测试覆盖
两种评测都可以手工得到（公式如下所示）或通过测试自动化工具计算得到。
1）基于需求的测试覆盖
基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。
在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。
2）基于代码的测试覆盖
基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或
软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。
几种常见的逻辑测试覆盖率
1 语句覆盖（statement coverage)
简言之，语句覆盖，就是设计若干个
测试用例，运行被测程序，使得每一可执行语句至少执行一次。这里的“若干个”，意味着使用测试用例越少越好。语句覆盖率的公式可以表示如下：
语句覆盖率=被评价到的语句数量/可执行的语句总数 x 100%
语句覆盖率达到了所谓的100%，但是却没有发现最简单的逻辑判断的错误
2 分支（判定）覆盖（Branch /Decision coverage）
也称加强语句覆盖，所谓判定覆盖，就是设计若干个测试用例，运行被测程序，使得程序中每判定的取真分支和取假分支至少评价一次。又称为分支覆盖。
使设计的
测试用例保证程序中每个判断的每个取值分支（t or f）至少经历一次
【优点】 判定覆盖具有比语句覆盖更强的测试能力，而且具有和语句覆盖一样的简单性，无需细分每个判定就可以得到测试用例。
【缺点】 往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。
3 条件覆盖（condition coverage）
条件覆盖是指选择足够的
测试用例，使得运行这些测试用例后，要使每个判断中每个条件的可能取值至少满足一次，但未必能覆盖全部分支
4 判定条件覆盖（Branch condition coverage）
判定-条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行，即要求各个判断的所有可能的条件取值组合至少执行一次。
缺点：主要对整个表达式的最终取值进行度量，忽略了表达式的内部取值
5 路径覆盖（path coverage）
我们主要执行基本的路径覆盖测试
路径覆盖要求设计足够多的测试用例，覆盖程序中所有可能的路径
对于比较简单的小程序来说，实现路径覆盖是可能的，但是如果程序中出现了多个判断和多个循环，可能的路径数目将会急剧增长，以致实现路径覆盖是不可能的。
其他的覆盖：
1 功能覆盖:
2 面向对象的覆盖
主要考虑接口之间的覆盖
3 函数覆盖
4 指令块覆盖（instruction coverage）
5 判定路径覆盖（decision to decision path coverage)
