JAVA代码覆盖率工具JaCoCo-实践篇

上周 JAVA代码覆盖率工具JaCoCo-原理篇 简单介绍了JaCoCo其生成覆盖率的基本原理，这周的实践篇的主要内容就是将原理应用到实践中，本篇内容全部都是具体的项目使用实战经验，这里分享给大家，共勉~

一、覆盖率项目中使用介绍

本节开始详细介绍下项目中的JaCoCo实战经验。

下图是覆盖率在实际在项目中的主要实施点:

分别详细介绍下：

1.1 确定插桩方式

Android项目只能使用JaCoCo的离线插桩方式。

为什么？主要是因为Android覆盖率的特殊性：

一般运行在服务器java程序的插桩可以在加载class文件进行，运用java Agent的机制，可以理解成"实时插桩"。JaCoCo提供了自己的Agent，完成插桩的同时，还提供了丰富的dump输出机制，如File,Tcp Server,Tcp Client。覆盖率信息可以通过文件或是Tcp的形式输出。这样外部程序可很方便随时拿到被测程序的覆盖率。

但是Android系统破坏了JaCoCo这种便利性，原因有两个:

(1)Android虚拟机不同与服务器上的JVM，它所支持的字节码必须经过处理支持Android Dalvik等专用虚拟机，所以插桩必须在处理之前完成，即离线插桩模式。

(2)Android虚拟机没有配置JVM 配置项的机制，所以应用启动时没有机会直接配置dump输出方式。

1.2 分析项目打包流程

项目目前还是已build方式打包，属于Apache Ant方式。

插桩前先熟悉下项目build内容。

项目主要有几个build文件：

存放在根目录下的build.xml文件，这个是项目构建的组织文件

.ant目录下的build_common.xml，这个是构建时target内容。

.ant目录下的build_option.xml，定义的属性文件。

.ant目录下的build_plugins.xml，插件文件。

在插桩前，应该对项目构建过程做一个总体的熟悉，了解下每个target的作用，这样才能确定不会影响各个插桩点，不会遗漏，否则会在打包的过程中出现各种各样的问题。

1.3 代码插桩

http://eclemma.org/jacoco/trunk/doc/ant.html，这个地址是JaCoCo的ant的说明文档。

里面简单介绍了其支持的task类型，包括：

Task coverage、Task agent、Task merge、Task report、Task instrument、Task dump

具体怎么使用可以参考里面的例子。

各Task实际调用的类，看一下JaCoCo的antlib.xml就知道了

项目根据自己的情况暂时只用到了Task instrument，其他dump、merge、report是通过其他方式使用的，具体后面有说明。

为什么没有用到dump、merge、report？

这种情况比较适合一个带有自动化测试的构建：打包、自动化测试、dump、merge、report。

项目部分功能需要手工测试，因此，上述几个步骤需要后面再另外处理。

OK，简单了解了JaCoCo的ant方式，下面开始对项目进行插桩打包。

项目的插桩修改步骤如下：

主要修改了build_common.xml和build_plugins.xml两个文件：

以下是build_common.xml的修改，build_plugins.xml的修改就不累述了，原理一样。

(1) 文件开头的命名空间加入

(2) 引入 JaCoCo 的 jar 和相关定义

(3) 重新定义 class 文件生成路径

(4) 修改compile编译节点，插桩注入

(5) 修改打包package节点，主要是指定 JaCoCo 编译后的类路径

(6) 修改混淆obfuscate节点，增加混淆所需要的

将delete、mkdir、unzip操作指向classes_instr

(7) 修改分包splitClasses节点，指向classes_instr

(8) 修改热补丁注入injectPatchCode节点，指向classes_instr

(9) 修改dex节点，指向classes_instr

(10) 修改dex_sub节点，指向classes_instr，同时在excludes中加入jacocoagent.jar

将上面的操作，做成全自动修改，打包成autoinsertxml.jar，放到打包服务器后台指定的目录下。

Jar包里详细内容如下：

• 修改AndroidManifest.xml文件，增加一个覆盖率生成服务（这个后续的覆盖率生成工具用到）
• 修改build_common.xml文件，实现主干代码插桩修改
• 修改build_plugins.xml文件，实现插件代码的插桩修改

1.4 打覆盖率包

Jekin上已经配置好了jacoco_package任务

按描述输入后，直接点击开始构建就行了，打包后的结果：

包括：未插桩的主干类文件、未插桩的插件类文件、三种方式的覆盖率包、mapping文件等等。

jacoco_package任务里面的具体内容做了什么？一起看看吧。

(1) 配置了参数化构建的内容

(2) 配置了构建描述

(3) 配置了项目ID和创建精准入库任务

(4) Check out代码

(5) 插桩

(6) 编译打包

(7) 备份class

(8)保存存档文件

1.5 执行测试，收集覆盖率结果文件

覆盖率文件生成现在支持两种方式：

(1)覆盖率生成工具：一个专门用来生成覆盖率文件的APK。

(2)定时器的方式：在项目里新建一个定时器JOB任务，定时去收集生成覆盖率文件。

目前我们主要用第一种方式，下面都详细介绍下。

1.5.1 AndroidManifest文件的修改

增加了两个服务：

ResultManagerService：执行生成覆盖率数据。

ReSetManagerService：执行清理覆盖率数据。

1.5.2 生成覆盖率的apk工具和jacoco-cov-sdk.jar包

工具总共有三个功能：

(1)生成ec文件

(2)启动定时器，按指定的时间生成ec文件

(3)清除覆盖率，会清除内存记录并且会删除sd卡存在的ec文件

工具原理：

(1) 生成ec文件

当触发这个操作的时候，其实会去启动项目中我们添加的ResultManagerService服务，它具体做的事情就是dump覆盖率数据，如下：

在ResultManagerService启动时调用jacoco-cov-sdk.jar包中的

ResultManager.dumpCoverageJacoco(true,filename)方法：

其主要功能就是反射调用jaCoCo的dump方法，来生成覆盖率数据，核心代码如下：

(2) 启动定时器，按指定的时间生成ec文件

这个就是一个Timer，按指定的时间周期去dump覆盖率数据

(3) 清除覆盖率，会清除内存记录并且会删除sd卡存在的ec文件

当触发这个操作的时候，其实会去启动项目中我们添加的ReSetManagerService服务，它具体做的事情就是reset覆盖率数据，如下：

在ReSetManagerService启动时调用jacoco-cov-sdk.jar包中的

ResultManager.reSetCoverageJacoco()方法：

其主要功能就是反射调用jaCoCo的reset方法，来清理覆盖率数据，核心代码如下：

1.6 生成覆盖率报告

通过编写report的build方式来生成报告结果。

这里写了一个生成报告的模版，使用者只需要copy到 本机上，按下面的说明修改、生成报告即可，下面详细介绍下这个模版的使用方法。

1.6.1 模版目录介绍

(1) libs存放几个jar包，分别为ant-contrib.jar、jacocoagent.jar、jacocoant.jar。

(2) result_xml目录会自动生成xml格式的报告。

(3) src目录是存放源码的，如果没这个，生成的覆盖率只有数据，看不到代码实际覆盖的内容。

(4) build文件，ant的执行内容为build_group或者是build_only。

说明：这个build文件需要根据实际的项目修改，修改一次以后基本不用变动。

(1) build_group文件，指定组生成的build文件，适合结果按组显示。

(2) build_only文件，没组的概念。

(3) build_property文件，存放的是ec列表文件名称。

build文件内容可以根据官方的demo参考。

1.6.2 实际操作举例

1、安装Apache Ant

网上下载或直接copy其他人机器上的就OK，设置下环境变量ANT_HOME和把bin目录放到path中，我用的是apache-ant-1.9.6-bin，有需要可以直接找我要。

2、取上面的模版目录放到你本机上(PC)，有需要可以直接找我要。

3、生成报告，按以下步骤操作

比如拿到测试结果的ec文件有三个，分别是yyb1.ec、yyb2.ec、yyb3.ec

(1) 将覆盖率打包结果中的classes.zip丢到模版根目录中并解压。

(2) 根据打包时的svn地址和版本号，取下源码放如到src目录。

(3) 将ec文件(yyb1.ec、yyb2.ec、yyb3.ec)全部丢到模版根目录中

(4) 修改build_property文件，名称写如到value中（去掉ec后缀的）

(5) build文件，如无路径变化，基本不用修改

省电管理除了主干代码，还有插件部分，因此build文件取的build_group，分别为<group name="YYB">、<group name="plugin_power_save">

(6) 执行ant，report目录就会生成。

(7) report目录生成后，进去执行index就看到覆盖率报告。

省电管理的覆盖率生成结果：

打开index后的结果，按build文件指定的分组生成了：

点击链接进入到实际代码中就可以实际覆盖的结果了。

这里有个注意的地方，如果想看到实际代码的覆盖率，编译的时候debug="true" 这个一定要设置。

1.7 分析覆盖率结果

网上关于JaCoCo覆盖率报告的分析有不少的文章可以学习。

这里阐明几个自己的观点：

根据项目的不同，在分析结果前先应该明确几个事情，包括

(1) 确定改动点的范围，根据这个范围才会有针对性的做分析。

(2) 改动点是否影响功能逻辑，如果不影响可以忽略。

(3) 改动点和其他功能是否存在耦合，如果存在，耦合的部分也要做分析。

我们主要从上面几点来分析覆盖率，查漏补缺，这些改动点大部分已经覆盖到了，基本认为应用的主要功能覆盖完全，当然也不是完全绝对，在测试过程中结合FreeTest、探索性测试等手段也是一种不错的选择，切记不要盲目的为了覆盖率而覆盖，覆盖率高不代表你真的覆盖完全了。

分析过程很多人觉得是比较痛苦的，不妨可以把这个过程当作是一种锻炼，前面的一切都只是一个铺垫，最最关键的在于分析阶段，一个出色的分析结果可以达到事半功倍的效果。

我们的方法是任务已tapd提单的方式创建，按照模版，附上需求链接地址、svn地址和改动范围、附件接受未插桩的class文件、测试后的ec文件等，分析出结果需要有分析过程、测试补充建议、分析耗时等等。

主要列出未覆盖场景、冗余方法、测试补充建议等等。

举个分析的例子：

需求： 消息盒子增量测试完成，进行覆盖率分析。

1.7.1 熟悉需求用例

(1) 确认代码范围

根据需求，确定开发修改的代码范围

(2) 覆盖率报告分析

根据开发修改的代码范围，对覆盖率报告结果进行分析

(3) 确认未覆盖原因

找出未覆盖的部分，判断是否需要覆盖

(4) 输出测试策略

根据分析后的结果输出再次出测试策略

(5) 补充测试验证

根据策略补充相应的测试，再生成覆盖率，和前一次做对比，最终达到功能大部分覆盖。

二、覆盖率与BVT测试结合

通过两者的结合，可以得到每个BVT的用例的覆盖率数据，可以得出几个纬度的结果：

(1)用例和代码的对应关系

用例和代码的动态映射关系，可能会存在映射到的函数比较多，作者建议根据功能有针对的筛选出重点函数来做映射。

(2)上面映射关系汇总后，可以按方法的调用频繁度来优化我们的代码，优化调用频繁度高的代码，找出冗余代码等等。

下面介绍下整个过程：

2.1 在BVT用例框架中插入覆盖率方法

核心：找出关键点插入我们的覆盖率方法

(1) 在每个用例执行前，插入清理覆盖率数据的方法

在BVT基类的setUp()方法最后插入清理覆盖率数据的方法。

这样每个用例开始执行前，就会把以前遗留的覆盖率数据清除掉，保证每次覆盖率都是一条用例的执行结果。

(2) 在每个用例执行后，tearDown()方法中调用dump出覆盖率数据。

dump出来的数据用例执行过程中真实的覆盖率情况。

2.2 执行BVT用例，得到覆盖率

运行BVN的用例，用例执行成后输出覆盖率文件，一条用例对应一个覆盖率文件

2.3 批量生成覆盖率报告，解析入库

批量生成覆盖率报告，根据用例和报告对应关系做批量入库。

2.4 分析覆盖率结果，得出用例和代码映射关系

上面我们已经得出每一个BVT用例的覆盖率数据，对每一个覆盖率数据结果进行分析，得出几个纬度的数据，用例->包->类->方法的覆盖数据，这样每个用例和代码的映射关系就出来了。

然后根据用例对应功能的特点，再筛选出重点方法，形成一个比较精简的用例和代码映射关系出来，方便我们后续的改动点定位。

三、差异覆盖率和全量覆盖率

测试完后，根据覆盖率结果衡量测试覆盖程度，主要分为两种：

(1) 差异覆盖率：改动点的代码执行覆盖率情况

(2) 全量覆盖率：本次测试代码执行全部覆盖率情况

使用哪种覆盖率是由测试阶段的内容决定，比如上线前测试、集成或合流阶段，主要关注的是改动点的变化，使用差异覆盖率效果比较理想。如果是新增功能，使用全量覆盖率比较理想。

3.1 差异覆盖率

差异覆盖率主要是根据开发代码变更的diff差异，得出改动代码的范围，然后根据这个范围有针对性的只生成这部分改动的代码覆盖率结果。

通过覆盖率结果反向衡量测试的充分性，更好的和精准评估的测试范围去做比较。

3.2 全量覆盖率

全量覆盖率即全部代码的覆盖结果，不一定要全部去分析，只需关注改动部分及其耦合功能的覆盖情况即可，这里结合精准耦合分析结果一起分析。

四、衡量覆盖率结果

代码覆盖是一种状态指示器，而不是衡量性能或正确性的单元。

代码覆盖率是给程序员参考的，是给我们发现代码中问题的一种手段，可以发现过时的，未测试的类，还可以发现未经测试执行可能导致问题的路径。在实际项目中，代码覆盖率总是低于100%。取得完全覆盖是不可能的，如果取得，那也是非常罕见的。分析前一定要确定那些为必须覆盖，那些为可以或不覆盖，不要为了覆盖而覆盖，代码逻辑的熟练程度对分析覆盖率会有很大的帮助，一定要先梳理清楚。

五、本章小结

代码覆盖率是软件测试中的一种度量手段，主要用来描述程序中源代码被测试的比例和程度。

在单元和系统测试过程中，其常常被拿来作为衡量测试好坏的指标，甚至很多情况下用代码覆盖率来考核测试任务完成情况，经常会被要求代码覆盖率必须达到XX%以上，才算测试充分，于是乎测试人员或者开发人员费尽心思设计案例来覆盖代码，这种用代码覆盖率来衡量，有利也有弊。

给伙伴们的一些忠告：

(1) 覆盖率数据只能代表你测试过哪些代码，不能代表你测好这些代码。

(2) 不要过于相信覆盖率数据。

(3) 不要只拿语句/行覆盖来衡量。

(4) 路径覆盖率>判断覆盖>语句覆盖。

(5) 不要盲目的为了提供覆盖率而补充用例，应该想办法设计更好的用例，哪怕多设计的用例对覆盖率提升没有效果。

转自：https://cloud.tencent.com/developer/article/1038206