简介
代码覆盖是一种用来度量已执行的软件测试水平的方法。收集覆盖度量数据的过程很简单：监测您的代码，并对所监测的版本运行测试。这样就可以生成相关数据，展示已执行哪些代码，或者更重要的是，未执行哪些代码。
覆盖测试是对单元测试的完美补充：单元测试可以显示出是否代码按预期执行，而代码覆盖可以表明还需要对哪些代码进行测试。
大多数开发人员都能理解这一过程，也赞同其价值主张，他们通常追求100%的覆盖率。尽管100%的覆盖率是个极好的目标，但类型不当的100%覆盖率依然会留下未知的问题。典型的软件开发是根据要测试的语句或分支的数量来度量覆盖率的。即便有着100%的语句或分支覆盖率，代码逻辑依然可能存在严重的逻辑bug，只能为开发人员和治理员带来虚假的安全感。
为何100%的覆盖率还不够？这是因为语句和分支覆盖率无法表明代码中的逻辑是否已执行。语句和分支覆盖对于未执行代码块中出现的明显问题来说很有用，但它们经常会错过与决策结构和决策交互相关的bug。而另一方面，路径覆盖则是一种有助于及早发现缺陷的更为健壮和全面的技术。
在了解路径覆盖之前，先关注一下语句和分支覆盖率方面的一些问题：
语句覆盖
语句覆盖可以识别在一个方法或类中执行了哪些语句。这是一种计算起来比较简单的量规，现在有许多 开源产品 都可以评测这种覆盖级别。最终，语句覆盖的获益在于其能够识别未执行代码块。然而语句覆盖也存在问题，其无法识别源代码中控制流结构导致的bug，例如复合条件或者连续开关标签。这意味着在您可以轻松获得100%覆盖率的同时，未发现的明显bug依然存在。
下例中显示了这种问题。此处，returnInput()方法由七条语句组成，它有一个简单的需求：输出应等于输入。
图1. 代码示例
接下来，您可以创建一个满足需求并且具有100%语句覆盖率的JUnit测试用例。
图2. 语句覆盖
在 returnInput() 中有一个明显的bug。假如第一个或第二个决策计算为真而其他的计算为假，返回值则不等于该方法的输入值。精明的软件开发人员会立即注重到这个问题，但语句覆盖报告却显示为100%的覆盖率。假如治理员发现覆盖率为100%，他/她可能会受到虚假的安全感的影响，判定测试已经完成，继而发布错误百出的代码，将之投入生产。
仅仅熟悉语句覆盖是不够的，开发人员必须进一步使用更为完善的测试技术：分支覆盖。
分支覆盖
分支是指决策的结果，因而分支覆盖可以评测已测试的决策结果。这听起来不错，因为这样可以比语句覆盖更深入地查看源代码，但分支覆盖也会提出更多的要求。
确定方法中的分支数量非常轻易。布尔决策无疑只有两种结果：真和假，而开关对于每种情况来说都只有一种结果——别忘了默认情况！方法中的决策结果总数等同于方法中需要覆盖的分支与输入分支的总和。（究竟，使用直线代码的方法也有一个分支）。
在以上示例中， returnInput() 具有七个分支——三个是真，三个是假，还有一个是用于方法输入的隐藏分支。您可以用两个测试用例来覆盖六个真和假的分支：
图3. 分支覆盖
两个测试都验证了（输出等于输入）需求并且达到了100%的分支覆盖率。但是，尽管实现了100%的分支覆盖率，测试却未发现bug。治理员可能会再次认为测试已完成，该方法可进入生产阶段。
聪明的开发人员将熟悉到您可能错过了被测试方法中的一些可能路径。以上示例已经测试了 真-假-真或假-真-真 路径，您可以通过添加两个额外测试来进行检验。
该方法中只有三个决策，因此测试所有八种可能路径是非常轻易的。但对于包含更多决策的方法来说，可能路径数量将呈指数增长。例如，一个包含十个布尔决策的方法会有1024种可能路径。这样只有祝您好运了！
因此，获得100%的语句和100%的分支覆盖率是远远不够的，但费力地测试一个复杂方法包含的所有可能路径也是不可行的。有没有其他选择呢？让我们看看基本路径覆盖。
基本路径覆盖
路径代表着从开始执行方法到退出方法的执行流程。一个有着N个决策的方法会有 2^N 种可能路径，假如方法中包含一个循环，则会产生无限数量的路径。幸运的是，您可以使用称为 圈复杂度（cyclomatic complexity） 的度量来减少需要测试的路径数量。
