概念

1. 代码覆盖率（Code Coverage）是反映测试用例对被测软件覆盖程度的重要指标，也是衡量测试工作进展情况的重要指标。
2. 代码覆盖率的分类：语句覆盖、判定覆盖、条件覆盖、路径覆盖以及循环覆盖等等

分析

代码覆盖率是一个白盒概念，毕竟它最终还是要落实到代码。既然代码覆盖率如此重要，那么什么时候该用它？该如何用它？
有人认为代码覆盖率重要，所以从项目的一开始就要进行代码覆盖率的检查和分析，即 获取覆盖率 –> 发现未覆盖的代码 –> 添加新测试用例。这样的使用方式，我把它命名为“代码覆盖率驱动的测试（CCDT，Code Coverage Driven Test）”。CCDT看起来很美，理论上无懈可击，但实际操作则完全不是那么回事儿。先不说这种方式是否正确，单就由此引入的开销来说，就够项目组喝一壶的，呵呵！之所这样说，是因为CCDT需要经历：获取覆盖率、分析覆盖率和添加测试用例这三步，每一步都存在着很多潜在“副产品”开销，尤其是前两步。要获取覆盖率，需要执行所有的测试用例，而你知道现在业界70%的测试仍然是手动的，仅为了覆盖率就频繁的执行测试用例，显然是不现实的；频繁分析覆盖率结果也是一件耗时的工作，无论开发人员还是测试人员做都是如此，尤其是对于采用敏捷开发方法的团队，短迭代不允许引入如此劳神的工作内容。

测试覆盖率仅仅能够告诉团队什么没有被测试，根本就回答不了软件是否经过了有效测试！

测试的过程应该是用户场景覆盖驱动的测试（USCDT，User Scenario Coverage Driven Test） ，即测试人员应该从用户真实使用场景出发，思考要测试的内容和设计测试用例。代码覆盖率是对USCDT的必要补充，以发现其中未覆盖的场景（Test Hole）。代码覆盖应该是在项目/迭代的中后期引入，不用很频繁，点到为止，例如对一个3-4周的迭代，3次的覆盖率检查就已经足够了。