测试覆盖率的分类：

测试覆盖率通常被用来衡量测试的充分性和完整性，从广义的角度来讲，测试覆盖率主要分为两大类，一类是面向项目的需求覆盖率，另一类是更偏向技术的代码覆盖率。

现在人们口中的测试覆盖率，通常默认指代码覆盖率，而不是需求覆盖率。

代码覆盖率：

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

** 代码覆盖率的局限性 **
即使所设计的测试用例已经达到 100% 的代码覆盖率，软件产品的质量也做不到万无一失。其根本原因在于代码覆盖率的计算是基于现有代码的，并不能发现那些 “未考虑某些输入” 以及 “未处理某些情况” 形成的缺陷。
例如，如果一个被测函数里面只有一行代码，只要这个函数被调用过了，那么衡量这一行代码质量的所有覆盖率指标都会是 100%，但是这个函数是否真正实现了应该需要实现的功能呢？
显然，代码覆盖率反映的仅仅是已有代码的哪些逻辑被执行过了，哪些逻辑还没有被执行过。以此为依据，你可以补充测试用例，可以去测试那些还没有覆盖到的执行路径。但也是仅此而已，对于那些压根还没有代码实现的部分，基于代码覆盖率的统计指标就无能为力了。

总结来讲，高的代码覆盖率不一定能保证软件的质量，但是低的代码覆盖率一定不能能保证软件的质量。

代码覆盖率工具

JaCoCo 是一款 Java 代码的主流开源覆盖率工具，可以很方便地嵌入到 Ant、Maven 中，并且和很多主流的持续集成工具以及代码静态检查工具，比如 Jekins 和 Sonar 等，都有很好的集成。

** 代码覆盖率工具的实现原理 **

第一，On-The-Fly 模式的特点在于无需修改源代码，也无需提前进行字节码插桩。它适用于支持 Java Agent 的运行环境。优点是，可以在系统不停机的情况下，实时收集代码覆盖率信息。缺点是运行环境必须允许使用 Java Agent。
第二，Offline 注入模式也无需修改源代码，但是需要在测试开始之前先对文件进行插桩，并事先生成插过桩的 class 文件。它适用于不支持 Java Agent 的运行环境，以及无法使用自定义类装载器的场景。优点是，JVM 启动时不再需要使用 Java Agent 额外开启代理，缺点是无法实时获取代码覆盖率信息，只能在系统停机时下获取。

安全产品嵌入式Ｃ的单元测试对覆盖率要求很高，语句，分支，MCDC 都要达到 100% 的覆盖率要求，单元测试工具一般会有统计要求，比如 RTRT 能统计一部分覆盖率，但 MCDC 没法统计；遇到的问题其实还是一个业界普遍的问题，就是覆盖率达到了，问题却发现的少，没有代码走查发现的多，但为完成覆盖率却耗时很多，所以包括公司领导在内的很多同事都认为覆盖率意义不大，觉得单元测试没有意义，这种局面貌似国内普遍现象。代码走查的确是个不错的时间，尤其是敏捷模式推崇的结对编程，但是走查往往只能发现静态或者一部分动态问题，而且走查的效果很大程度取决于个人的能力，不能系统化和体系化，代码覆盖率的局限性主要是不能发现有需求但是代码没有实现的场景，但是对于已有代码还是具有很高参考价值的，至少知道你那些分支和语句覆盖到了，另外 mcdc 现在只是在人生命相关的软件和系统中才会采用，很才有其它企业会用这个指标。