使用 Contest 分析测试用例的代码覆盖率

解决什么问题

问题的提出时这样的：对于测试人员来说，首先面临的问题就是无法度量测试用例的质量，如果测试工程师花费大量时间写的测试用例不能有效地覆盖重要的实现代码，那么可以表明这样的测试用例不是优良的。同时可以根据测试覆盖了的报表来分析为什么没有覆盖到重要的代码，接着需要进行改进测试用例的代码覆盖率达到满意的结果。代码覆盖率高低根据产品的不同而不同：70%，80% 甚至 100% 都是可能的。对于测试工程师来讲，可以遵循这样的流程 : 获取覆盖率 – > 发现未覆盖的代码 – > 添加新测试用例来改良测试用例，保证产品质量。

代码覆盖率基本介绍

在 CMMI4 体系的测试过程中定义了四个度量指标：代码覆盖率、测试执行率、测试执行通过率、测试缺陷解决率。其中代码覆盖率就是描述了程序的源代码在功能测试中的覆盖率，即反映测试用例对被测软件的实现代码覆盖程度的重要指标，它也是对测试工作进行量化的重要指标之一。测试工作往往不如开发那样可以用图表数据表示结果，一个重要原因之一就是测试难于量化，而代码覆盖率恰恰是解决这一问题的重要指标。同时一个角度来讲，软件的风险很可能就存在于代码覆盖率没有涉及的地方，代码覆盖率可以发现其中未覆盖的场景（Test Hole）, 测试工程师根据这个 Test Hole 来分析测试用例，以此来优化测试用例，这个过程能显著提高测试的生产效率，并提高软件产品质量。代码覆盖率是个白盒测试的概念，毕竟最后要跟踪到源代码。一般来说，代码覆盖率的测试应该是在产品的中后期引入，不过对于使用敏捷技术开发的产品，可以在开始开发的迭代周期就引入。笔者所在的团队就在项目的中后期使用，主要用于测试回归测试的代码覆盖率。

代码覆盖率基本的指标

语句覆盖 Statement coverage (line coverage): 用于评测产品代码独立代码行在测试活动中执行的行覆盖率，优点是简单，缺点是无法包含代码的逻辑分支。

基本语句块覆盖 Basic block coverage: 把非分支的代码区域做为一个计量单位，用于一个 if/else 中的某个分支行数远大于另一个分支，所以可能会出现这项指标比较高的情况。

条件覆盖 Decision coverage (branch coverage): 用于评价代码分支地代码覆盖率。
功能覆盖 Function coverage (Method Function): 评测产品代码在测试活动中执行方法的覆盖率。

代码覆盖率的实现方式

对于 Java 作为开发语言的产品，分析代码覆盖率时候使用 Instrumentation 技术，本质就是在产品代码的关键位置插入统计代码，即在代码的每个方法的开始加入统计计数器和序列号，当方法被执行之后，根据序列号以计算改方法被测试用例测试到。一般来说，Instrumentation 技术可以分为两种方式：Class Instrumentation 和 Source Instrumentation。前者把统计代码插入编译好的 .class 文件，而后者则把统计代码插入源代码 (.java 文件 ) 并编译成新的 .class 文件。大多数代码覆盖率工具采用这两种 Instrumentation 技术。其中用 Class Instrumentation 使用最广，因为在产品开发的每个阶段，采用持续集成的方式来开发产品，测试工程师面对的不是产品的源代码，而是交付给测试的产品版本，所以考虑到避免修改源代码，而直接注入统计代码到生成的 class, 对于本文中也用第一种 Class Instrumentation 技术。

 

Contest 介绍

Contest 是功能强大的易用的工具，在测试的前期用以发现并行系统的 bug, 而不用建立复杂的测试多处理器和多应用的测试环境。Contest 对开发人员可测试工程师都很非常有帮助，它可以作为独立运行的工具或者一个 Eclipse 插件，开发人员去运行可以得到单元测试的代码覆盖率。Contest 可以用最小的成本来度量代码覆盖率，在调试期间，可以发现死锁信息，Contest 还有很多其他功能，代码覆盖率是我们在本文中用到的一个功能。有兴趣的读者可以在这里下载