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的copy。
文件内容如下:
说明:指定xmlns:jacoco、name和缺省的执行task`
`
说明:引入了ant的jar包,放入到classpath中
说明:import了属性文件
`
`
说明:定义了一下属性:源码路径、类路径、报告目录、xml目录
`
`
说明:引入jacocoant.jar,指定了ant的操作映射文件
`
`
说明:build_all任务的内容,循环遍历ec_list,作为report的输入
`
`
说明:report任务的内容,指定merge、指定ec文件、结果已YYB组显示、指定classes文件、指定src文件列表、指定html、csv、xml属性。
说明:这个build文件需要根据实际的项目修改,修改一次以后基本不用变动。
(1)build_group文件,指定组生成的build文件,适合结果按组显示。
(2)build_only文件,没组的概念。
(3)build_property文件,存放的是ec列表文件名称。
1.6.2 实际操作举例
一、安装Apache Ant
网上下载或直接copy其他人机器上的就OK,设置下环境变量ANT_HOME和把bin目录放到path中,我用的是apache-ant-1.9.6-bin,有需要可以直接找我要。
二、取上面的模版目录放到你本机上(PC),有需要可以直接找我要。
三、生成报告,按以下步骤操作
比如拿到测试结果的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,分别为
、
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()方法最后插入清理覆盖率数据的方法。
`@Override
protected void setUp() throws Exception {
super.setUp();
//反射调用JaCoCo api的reset方法
...
Method methodDump = classAgent.getMethod("reset");
methodDump.invoke(objAgent,null)
}`
这样每个用例开始执行前,就会把以前遗留的覆盖率数据清除掉,保证每次覆盖率都是一条用例的执行结果。
(2)在每个用例执行后,dump出覆盖率数据。
`@Override
protected void tearDown() throws Exception {
//反射调用JaCoCo api的dump方法
...
Method methodDump = classAgent.getMethod("dump",boolean.class);
methodDump.invoke(objAgent,reset);
}`
dump出来的数据用例执行过程中真实的覆盖率情况。
Method methodDump = classAgent.getMethod("reset");
methodDump.invoke(objAgent,null)
2.2 执行BVT用例,得到覆盖率
运行BVN的用例,用例执行成后输出覆盖率文件,一条用例对应一个覆盖率文件。
2.3 批量生成覆盖率报告,解析入库
批量生成覆盖率报告,根据用例和报告对应关系做批量入库。
2.4 分析覆盖率结果,得出用例和代码映射关系
上面我们已经得出每一个BVT用例的覆盖率数据,对每一个覆盖率数据结果进行分析,得出几个纬度的数据,用例->包->类->方法的覆盖数据,这样每个用例和代码的映射关系就出来了。
然后根据用例对应功能的特点,再筛选出重点方法,形成一个比较精简的用例和代码映射关系出来,方便我们后续的改动点定位。
三、差异覆盖率和全量覆盖率
测试完后,根据覆盖率结果衡量测试覆盖程度,主要分为两种:
(1)差异覆盖率:改动点的代码执行覆盖率情况
(2)全量覆盖率:本次测试代码执行全部覆盖率情况
使用哪种覆盖率是由测试阶段的内容决定,比如上线前测试、集成或合流阶段,主要关注的是改动点的变化,使用差异覆盖率效果比较理想。如果是新增功能,使用全量覆盖率比较理想。
3.1 差异覆盖率
差异覆盖率主要是根据开发代码变更的diff差异,得出改动代码的范围,然后根据这个范围有针对性的只生成这部分改动的代码覆盖率结果。
通过覆盖率结果反向衡量测试的充分性,更好的和精准评估的测试范围去做比较。
3.2 全量覆盖率
全量覆盖率即全部代码的覆盖结果,不一定要全部去分析,只需关注改动部分及其耦合功能的覆盖情况即可,这里结合精准耦合分析结果一起分析。
四、衡量覆盖率结果
代码覆盖是一种状态指示器,而不是衡量性能或正确性的单元。
代码覆盖率是给程序员参考的,是给我们发现代码中问题的一种手段,可以发现过时的,未测试的类,还可以发现未经测试执行可能导致问题的路径。在实际项目中,代码覆盖率总是低于100%。取得完全覆盖是不可能的,如果取得,那也是非常罕见的。分析前一定要确定那些为必须覆盖,那些为可以或不覆盖,不要为了覆盖而覆盖,代码逻辑的熟练程度对分析覆盖率会有很大的帮助,一定要先梳理清楚。
五、本章小结
代码覆盖率是软件测试中的一种度量手段,主要用来描述程序中源代码被测试的比例和程度。
在单元和系统测试过程中,其常常被拿来作为衡量测试好坏的指标,甚至很多情况下用代码覆盖率来考核测试任务完成情况,经常会被要求代码覆盖率必须达到XX%以上,才算测试充分,于是乎测试人员或者开发人员费尽心思设计案例来覆盖代码,这种用代码覆盖率来衡量,有利也有弊。
给读者的一些忠告:
1、覆盖率数据只能代表你测试过哪些代码,不能代表你测好这些代码。
2、不要过于相信覆盖率数据。
3、不要只拿语句/行覆盖来衡量
4、路径覆盖率>判断覆盖>语句覆盖
5、不要盲目的为了提供覆盖率而补充用例,应该想办法设计更好的用例,哪怕多设计的用例对覆盖率提升没有效果。
本章完~
22/2<12