代码覆盖是一种用来度量已执行的软件测试水平的方法。收集覆盖度量数据的过程很简单：监测您的代码，并对所监测的版本运行测试。这样就可以生成相关数据，展示已执行哪些代码，或者更重要的是，未执行哪些代码。覆盖测试是对单元测试的完美补充：单元测试可以显示出是否代码按预期执行，而代码覆盖可以表明还需要对哪些代码进行测试。
大多数开发人员都能理解这一过程，也赞同其价值主张，他们通常追求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） 的度量来减少需要测试的路径数量。
一种方法的圈复杂度是数字1加上该方法中的独特决策数量。圈复杂度可以帮助您定义方法的线性无关路径的数量，即基组。线性无关的定义不在本文讨论范围之内，但总体来说基组就是一个最小的路径组，它可以通过组合来创建方法中的其他可能路径。
像分支覆盖一样，路径基组测试确保了您可以测试每个决策结果，但是与分支覆盖不同，基本路径覆盖可以确保对所有相互独立的决策结果进行测试。也就是说每个新的基本路径都可以准确地“浏览”前一个执行决策，而不改变其他执行分支。这是基本路径覆盖比分支覆盖更健壮的重要原因，它使您能够了解如何通过改变一个决策来影响方法的行为。
我将使用同一个示例进行说明。
图4. 代码示例
要获得100%的基本路径覆盖，您需要定义基组。这种方法的圈复杂度为四（1加决策数量），需要定义四个线性无关路径。为此，可以将任何第一个路径定为基线，并且逐个浏览决策，直至完成基组。
路径1：任何路径都可以作为基线，因此将决策结果选定为真（由 TTT 表示）。这是基组中的第一个路径。
路径2：要找到下一个基本路径，浏览（仅限于）基线路径中的第一个决策，显示 FTT 表示您期望的决策结果。
路径3：浏览基线路径中的第二个决策，显示第三个基本路径为 TFT 。这样，第一个基线决策就可以保持为结果“真”不变。
路径4：最后，浏览基线路径中的第三个决策，显示第四个基本路径为 TTF 。这样，第一个基线决策就可以保持为结果“真”不变。
因此，四个基本路径为 TTT、 FTT、 TFT、和 TTF。现在，进行测试并查看结果。
在所附的代码中，您可以看到 testReturnInputIntBooleanBooleanBooleanTFT() 和 testReturnInputIntBooleanBooleanBooleanFTT() 找到了语句和分支覆盖中未发现的bug。此外，基本路径数量随着决策数据呈线性增长，而非指数增长，使需要进行测试的数量与实现全面分支覆盖所需的数量相等。事实上，基本路径测试覆盖了一个方法中的所有语句和分支，因而有效包含了分支和语句覆盖。
但是，为何不对其他潜在路径进行测试呢？记住，基本路径测试的目的在于测试所有相对独立的决策结果。通过对四个基本路径的测试可达到这个目的，而这与其他的路径没有关系。如果在开始时选择 FFF 作为基线路径，您将得到（FFF、 TFF、 FTF、 FFT）基组，与 TTT 路径无关。两个基组都同样有效，任何一个都可以满足您的独立决策结果标准。
创建测试数据
在本示例中获得100%的基本路径覆盖率非常容易，但是对现实生活中的路径基组进行全面测试将更具挑战性，甚至不可能实现。由于基本路径覆盖测试一个方法中各个决策之间的交互情况，因此您需要使用促使指定路径执行的测试数据，而不能仅仅使用单一的决策结果，这对分支覆盖来说也很有必要。通过注入数据来强行按指定路径执行非常困难，但是您可以记住简化测试过程的几种编码实践。
- 使您的代码保持简单。圈复杂度越低越好。在能够减小数值时进行重构。数值越高，就越难测试，这个数值一旦超过10，测试就根本无法实现。这样不仅能减少需要测试的基本路径数量，而且还能减少每个路径中的决策数量。
- 避免重复决策
- 避免数据依赖性
考虑以下示例：
图5. 基本路径测试
x 变量间接依赖于 object1 参数，但其中插入的代码却使查看关系变得尤为困难。随着方法变得越来越复杂，查看方法的输入值和决策表达式之间的关系几乎是不可能的。
结束语
尽管语句和分支覆盖度量值易于计算和获得，但都可能留下未知的重大缺陷，只能为开发人员和管理员带来虚假的安全感。基本路径覆盖可以提供更为健壮和全面的方法，从而发现这些未被觉察的缺陷，而且可以避免所需测试的数量呈指数增长。