cobertura(覆盖率测试工具) v2.1.1 免费版

cobertura是一款免费的覆盖率测试软件，一款免费的Java开发工具，主要用于识别用户的Java程序是否缺乏测试覆盖，可以快速测试访问的代码百分比，通过标记无用、执行不到的代码来提供优化代码的功能，非常不错。推荐大家下载！

cobertura功能

　　代码覆盖率的统计指标

　　代码覆盖率指的是一种衡量代码覆盖程度的方式，通常会对以下几种方式进行统计分析：

　　行覆盖。它又被称作语句覆盖或基本块覆盖。这是一种较为常用且具有代表性的指标，度量的是被测代码中每个可执行语句是否被执行到。

　　条件覆盖。它度量的是当代码中存在分支时，是否能覆盖进入分支和不进入分支这两种情况。这要求开发人员编写多个测试用例以分别满足进入分支与不进入分支这两种情况。

　　路径覆盖。它度量的是当代码中存在多个分支时，是否覆盖到分支之间不同组合方式所产生的全部路径。这是一种力度最强的覆盖检测，相对而言，条件覆盖只是路径覆盖中的一部分。

　　在这三种覆盖指标中，行覆盖简单，适用性广，但可能会被认为是“最弱的覆盖”，其实不然。行覆盖相对于条件或路径覆盖，可以使开发人员通过尽可能少的测试数据和用例，覆盖尽可能多的代码。通常情况下，是先通过工具检测一遍整个工程单元测试的行覆盖情况，然后针对没有被覆盖到的代码，分析其没有被覆盖到的原因。如果是由于该代码所在分支由于不满足进入该分支的条件而没有被覆盖，那么开发人员才会进一步修改或增加测试代码，完成该部分的条件或路径覆盖。

　　可见，高效高质量的行覆盖是有效进行条件覆盖与路径覆盖的前提。行覆盖率越高，说明没有被覆盖到的代码越少，这样开发人员便会集中精力修改测试用例，覆盖这些数量不多的代码。相反，如果行覆盖率低，开发人员需要逐个检查没有被覆盖到的代码，精力被分散，因此很难提高剩余代码单元测试的质量。

　　代码覆盖率 = 被测代码行数 / 参测代码总行数 * 100%。 从代码覆盖率的计算方式中可以看出，要提高代码覆盖率，可通过提高被测代码行数，或减少参测代码总行数的方式进行。以下将会从这两个角度分别入手，分析如何提高被测代码行数及减少参测代码总行数。

　　使用 Cobertura 统计并提高代码的行覆盖率

　　Cobertura 是一款优秀的开源测试覆盖率统计工具，它与单元测试代码结合，标记并分析在测试包运行时执行了哪些代码和没有执行哪些代码以及所经过的条件分支，来测量测试覆盖率。除了找出未测试到的代码并发现 bug 外，Cobertura 还可以通过标记无用的、执行不到的代码来优化代码，最终生成一份美观详尽的 HTML 覆盖率检测报告。

　　Cobertura 基本工具包里有四个基本过程及对应的工具：cobertura-check, cobertura-instrument, cobertura-merge, cobertura-report; 这个脚本独立使用较为繁琐，不方便也不利于自动化。不过， Cobertura 在 Maven 编译平台上有相应的 cobertura-maven-plugin 插件，使代码编译、检测、集成等各个周期可以流水线式自动化完成。

　　过滤不需进行单元测试的包和类

　　针对项目中不需进行单元测试的包和类，我们可以利用 POM 文件中 Cobertura 的标注 (instrument) 设置，对相应的包和类进行剔除 (exclude) 或筛选 (include)，使之不体现在覆盖率报告中，去除它们对整个覆盖率的影响，从而使报告更具针对性。

　　过滤类中的函数

　　最新版本中的 Cobertura 只能支持到类级别的过滤，而对于类中方法的过滤是不支持的。因此我们需要通过修改 Cobertura 源码，使 Cobertura 支持对类中方法的过滤。

　　对 Cobertura 及其插件改动所依据的主要原理是 : 修改 Cobertura-maven-plugin 项目中的 InstrumentationTask 类，增加 Ignoretrival,IgnoreMethod 等新增 POM 参数。配制正则表达式，修改 Cobertura 核心，在标注(instrumentation) 阶段遍历函数名时，检测函数名是否匹配传入的正则表达式，过滤函数体代码，从而把这些函数代码排除在代码覆盖统计之外，节省开发人员对这类代码的测试精力。

　　利用 Java 反射(Reflection) 机制提高代码的行覆盖率

　　不同的人对反射有不同的理解，大部分人认同的一种观点是：反射使得程序可以检查自身结构以及软件环境，并且根据程序检测到的实际情况改变行为。

　　为了实现自检，一段程序需要有些信息来表示自身，这些信息就称为元数据(metadata)。Java 运行过程中对这些元数据的自检称为内省(introspection)。内省过程之后往往进行行为改变。总的来说，反射 API 利用以下三种技术来实现行为改变：

　　直接修改元数据。

　　利用元数据进行操作。

　　调解(Intercession), 代码被允许在程序各种运行期进行调整。

　　Java 语言反射机制提供一组丰富的 API 函数来操作元数据，且提供了少部分重要的 API 来实现 Intercession 能力。

　　实际项目中，为了保证软件代码的整体质量，单元测试不仅要覆盖类的公有成员，还要覆盖重要的私有成员。而有些私有成员的调用，会被放入到极为复杂的条件分支中。而构造进入这个私有方法的相关条件，可能需要开发人员编写大量测试代码及测试数据。这无疑增加了单元测试的成本。有时为了节省成本，该类私有方法便跳过不测，从而在无形中降低了代码的行覆盖率，影响了软件的整体质量。

　　而利用反射的一系列特性，我们可以在不改变源代码的情况下，直接对复杂的私有方法进行单元测试，无需增加行覆盖检查中被覆盖的代码行数，从而可以在不增加单元测试成本的前提下，提高代码的行覆盖率与单元测试的整体质量。

软件特点

　　阅读 Cobertura 输出

　　我们首先查看生成的 Cobertura 输出。图 1 显示了对 Jaxen 测试包运行 Cobertura 生成的报告(请参阅 参考资料)。从该报告中，可以看到从很好(在 org.jaxen.expr.iter 包中几乎是 100%)到极差(在 org.jaxen.dom.html 中完全没有覆盖)的覆盖率结果。

　　图 1. Jaxen 的包级别覆盖率统计数据

　　Cobertura 通过被测试的行数和被测试的分支数来计算覆盖率。第一次测试时，两种测试方法之间的差别并不是很重要。Cobertura 还为类计算平均 McCabe 复杂度(请参阅 参考资料)。

　　可以深入挖掘 HTML 报告，了解特定包或者类的覆盖率。图 2 显示了 org.jaxen.function 包的覆盖率统计。在这个包中，覆盖率的范围从 SumFunction 类的 100% 到 IdFunction 类的仅为 5%。

　　图 2. org.jaxen.function 包中的代码覆盖率

　　进一步深入到单独的类中，具体查看哪一行代码没有测试到。图 3 显示了 NameFunction 类中的部分覆盖率。最左边一栏显示行号。后一栏显示了执行测试时这一行被执行的次数。可以看出，第 112 行被执行了 100 次，第 114 行被执行了 28 次。用红色突出显示的那些行则根本没有测试到。这个报告表明，虽然从总体上说该方法被测试到了，但实际上还有许多分支没有测试到。

　　图 3. NameFunction 类中的代码覆盖率

　　Cobertura 是 jcoverage 的分支。GPL 版本的 jcoverage 已经有一年没有更新过了，并且有一些长期存在的 bug，Cobertura 修复了这些 bug。原来的那些 jcoverage 开发人员不再继续开发开放源码，他们转向开发 jcoverage 的商业版和 jcoverage+，jcoverage+ 是一个从同一代码基础中发展出来的封闭源代码产品。开放源码的奇妙之处在于：一个产品不会因为原开发人员决定让他们的工作获得相应的报酬而消亡。

确认遗漏的测试

　　利用 Cobertura 报告，可以找出代码中未测试的部分并针对它们编写测试。例如，图 3 显示 Jaxen 需要进行一些测试，运用 name() 函数对文字节点、注释节点、处理指令节点、属性节点和名称空间节点进行测试。

　　如果有许多未覆盖的代码，像 Cobertura 在这里报告的那样，那么添加所有缺少的测试将会非常耗时，但也是值得的。不一定要一次完成它。您可以从被测试的最少的代码开始，比如那些所有没有覆盖的包。在测试所有的包之后，就可以对每一个显示为没有覆盖的类编写一些测试代码。对所有类进行专门测试后，还要为所有未覆盖的方法编写测试代码。在测试所有方法之后，就可以开始分析对未测试的语句进行测试的必要性。

　　(几乎)不留下任何未测试的代码

　　是否有一些可以测试但不应测试的内容?这取决于您问的是谁。在 JUnit FAQ 中，J. B. Rainsberger 写到“一般的看法是：如果 自身 不会出问题，那么它会因为太简单而不会出问题。第一个例子是 getX() 方法。假定 getX() 方法只提供某一实例变量的值。在这种情况下，除非编译器或者解释器出了问题，否则 getX() 是不会出问题的。因此，不用测试 getX()，测试它不会带来任何好处。对于 setX() 方法来说也是如此，不过，如果 setX() 方法确实要进行任何参数验证，或者说确实有副作用，那么还是有必要对其进行测试。”

　　理论上，对未覆盖的代码编写测试代码不一定就会发现 bug。但在实践中，我从来没有碰到没有发现 bug 的情况。未测试的代码充满了 bug。所做的测试越少，在代码中隐藏的、未发现的 bug 就会越多。我不同意。我已经记不清在“简单得不会出问题”的代码中发现的 bug 的数量了。确实，一些 getter 和 setter 很简单，不可能出问题。但是我从来就没有办法区分哪些方法是真的简单得不会出错，哪些方法只是看上去如此。编写覆盖像 setter 和 getter 这样简单方法的测试代码并不难。为此所花的少量时间会因为在这些方法中发现未曾预料到的 bug 而得到补偿。

　　一般来说，开始测量后，达到 90% 的测试覆盖率是很容易的。将覆盖率提高到 95% 或者更高就需要动一下脑筋。例如，可能需要装载不同版本的支持库，以测试没有在所有版本的库中出现的 bug。或者需要重新构建代码，以便测试通常执行不到的部分代码。可以对类进行扩展，让它们的受保护方法变为公共方法，这样就可以对这些方法进行测试。这些技巧看起来像是多此一举，但是它们曾帮助我在一半的时间内发现更多的未发现的 bug。

　　并不总是可以得到完美的、100% 的代码覆盖率。有时您会发现，不管对代码如何改造，仍然有一些行、方法、甚至是整个类是测试不到的。下面是您可能会遇到的挑战的一些例子：

　　只在特定平台上执行的代码。例如，在一个设计良好的 GUI 应用程序中，添加一个 Exit 菜单项的代码可以在 Windows PC 上运行，但它不能在 Mac 机上运行。

　　捕获不会发生的异常的 catch 语句，比如在从 ByteArrayInputStream 进行读取操作时抛出的 IOException。

　　非公共类中的一些方法，它们永远也不会被实际调用，只是为了满足某个接口契约而必须实现。

　　处理虚拟机 bug 的代码块，比如说，不能识别 UTF-8 编码。

　　考虑到上面这些以及类似的情况，我认为一些极限程序员自动删除所有未测试代码的做法是不切实际的，并且可能具有一定的讽刺性。不能总是获得绝对完美的测试覆盖率并不意味着就不会有更好的覆盖率。

　　然而，比执行不到的语句和方法更常见的是残留代码，它不再有任何作用，并且从代码基中去掉这些代码也不会产生任何影响。有时可以通过使用反射来访问私有成员这样的怪招来测试未测试的代码。还可以为未测试的、包保护(package-protected)的代码来编写测试代码，将测试类放到将要测试的类所在那个包中。但最好不要这样做。所有不能通过发布的(公共的和受保护的)接口访问的代码都应删除。执行不到的代码不应当成为代码基的一部分。代码基越小，它就越容易被理解和维护。

　　运行 Cobertura

　　在了解了测量代码覆盖率的好处后，让我们再来讨论一下如何用 Cobertura 测量代码覆盖率的具体细节。Cobertura 被设计成为在 Ant 中运行。现在还没有这方面的 IDE 插件可用，不过一两年内也许就会有了。

　　首先需要在 build.xml 文件中添加一个任务定义。以下这个顶级 taskdef 元素将 cobertura.jar 文件限定在当前工作目录中：

软件说明

　　只在特定平台上执行的代码。例如，在一个设计良好的 GUI 应用程序中，添加一个 Exit 菜单项的代码可以在 Windows PC 上运行，但它不能在 Mac 机上运行。

　　捕获不会发生的异常的 catch 语句，比如在从 ByteArrayInputStream 进行读取操作时抛出的 IOException。

　　非公共类中的一些方法，它们永远也不会被实际调用，只是为了满足某个接口契约而必须实现。

　　处理虚拟机 bug 的代码块，比如说，不能识别 UTF-8 编码。