Jacoco代码覆盖率报告详解

一、JaCoCo

        Jacoco从多种角度对代码进行了分析,包括指令(Instructions,C0 Coverage),分支(Branches,C1 Coverage),圈复杂度(Cyclomatic Complexity),行(Lines),方法(Methods),类(Classes)。

二、springboot工程,jacoco单元测试报告获取

注意:想要获取覆盖率结果,工程里必须写单测代码,否则不会有结果

1. 在pom中添加jacoco插件

<plugin>
	<groupId>org.jacoco</groupId>
	<artifactId>jacoco-maven-plugin</artifactId>
	<version>0.8.6</version>
	<configuration>
		<!--指定生成 .exec 文件的存放位置-->
		<destFile>target/coverage-reports/jacoco-unit.exec</destFile>
		<!--Jacoco 是根据 .exec 文件生成最终的报告,所以需指定 .exec 的存放路径-->
		<dataFile>target/coverage-reports/jacoco-unit.exec</dataFile>
	</configuration>
	<executions>
		<execution>
			<id>jacoco-initialize</id>
			<goals>
				<goal>prepare-agent</goal>
			</goals>
		</execution>
		<execution>
			<id>jacoco-site</id>
			<phase>test</phase>
			<goals>
				<goal>report</goal>
			</goals>
		</execution>
	</executions>
</plugin>

2. 执行mvn test命令

在target目录下生成site目录,里面有index.html文件,就是生成的jacoco报告,打开就可以查看覆盖率报告

3. 浏览器打开index.html页面

三、jacoco报告详解

1. Instructions

        Jacoco计算的最小单位就是字节码指令。指令覆盖率表明了在所有的指令中,哪些被执行过以及哪些没有被执行。这项指数完全独立于源码格式并且在任何情况下有效,不需要类文件的调试信息。

2. Branches

        Jacoco对所有的if和switch指令计算了分支覆盖率。这项指标会统计所有的分支数量,并同时指出哪些分支被执行,哪些分支没有被执行。这项指标也在任何情况都有效。异常处理不考虑在分支范围内。
在有调试信息的情况下,分支点可以被映射到源码中的每一行,并且被高亮表示。

红色背景:无覆盖,该行的所有指令均无执行。
黄色背景:部分覆盖,该行部分指令被执行。
绿色背景:全覆盖,该行所有指令被执行。

3. Cyclomatic Complexity

        Jacoco为每个非抽象方法计算圈复杂度,并也会计算每个类,包,组的复杂度。根据McCabe1996的定义,圈复杂度可以理解为覆盖所有的可能情况最少使用的测试用例数。这项参数也在任何情况下有效。

        根据由McCabe1996圈复杂度的定义是,在(线性)组合中,计算在一个方法里面所有可能路径的最小数目。所以复杂度可以作为度量单元测试是否有完全覆盖所有场景的一个依据。复杂度即使是在没有调试信息的情况下也可以计算。

圈复杂度V(G)的正式定义是基于方法的控制流图的有向图表示:

v(G) = E – N + 2

E是边界的数量,N是节点的数量。Jacoco 基于下面的方程来计算复杂度,B是分支的数量,D是决策点的数量:

v(G) = B – D + 1

基于每个分支的被覆盖情况,Jacoco也为每个方法计算覆盖和缺失的复杂度。缺失的复杂度同样表示测试案例没有完全覆盖到这个模块。注意Jacoco不将异常处理作为分支,try/catch块也同样不增加复杂度。

4. Lines

        该项指数在有调试信息的情况下计算。因为每一行代码可能会产生若干条字节码指令,所以我们用三种不同状态表示行覆盖率

红色背景:无覆盖,该行的所有指令均无执行。
黄色背景:部分覆盖,该行部分指令被执行。
绿色背景:全覆盖,该行所有指令被执行。

5. Methods

        每一个非抽象方法都至少有一条指令。若一个方法至少被执行了一条指令,就认为它被执行过。因为JaCoco直接对字节码进行操作,所以有些方法没有在源码显示(比如某些构造方法和由编译器自动生成的方法)也会被计入在内。

6. Classes

        每个类中只要有一个方法被执行,这个类就被认定为被执行。同5一样,有些没有在源码声明的方法被执行,也认定该类被执行。

 

 

  • 7
    点赞
  • 38
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
单元测试报告 版本:V1.3 文 档 编 号 保 密 等 级 作 者 最后修改日期 审 核 人 最后审批日期 批 准 人 最后批准日期 修订记录 日期 版本 修订说明 修订人 目 录 1 简介 2 1.1 目的 2 1.2 背景 2 1.3 范围 2 2 测试用例清单 2 3 功能测试分析 2 4 边界测试分析 2 5 覆盖率分析 2 6 内存使用分析 2 7 典型缺陷记录 3 7.1 缺陷1 3 7.1.1 表现 3 7.1.2 原因 3 7.1.3 方案 3 8 测试数据分析 3 8.1 测试有效性分析 3 8.2 测试效率分析 3 9 产品质量分析 4 10 测试结论 4 简介 目的 【描述该单元测试报告的目的。】 背景 【描述单元测试报告的背景,单元测试活动目的。如无特殊背景信息,可裁剪。】 范围 【说明该单元测试报告在整个项目周期的适用范围】 测试用例清单 模块 目标类 级别 用例类 用例描述 执行结果 备注 【被测的代码类】 【代码级别】 【Junit测试类1】 【意图描述】 【P/F】 【Junit测试类2】 功能测试分析 边界测试分析 覆盖率分析 目标类 级别 方法覆盖率 行覆盖率 备注 【被测的代码类】 【代码级别】 内存使用分析 典型缺陷记录 记录单元测试中所发现的典型缺陷或常见缺陷。供再次发现同类问题时,作为参考使用。 缺陷1 表现 【缺陷表现描述】 原因 【缺陷产生原因分析描述】 方案 【解决方案描述】 测试有效性分析 【统计实际发现的缺陷数据,分析与计划值产生偏差的原因,结合《项目量化管理计划》定义的阈值,确定是否采取相关措施】 计划发现缺陷数 致命 严重 一般 实际发现缺陷数 偏差分析 对策或调整措施 产品质量分析 【结合上述数据和信息,对本次测试的项目、产品的本身质量进行分析、评价和总结】 测试结论  【描述测试是否达到测试计划的目的,是否满足单元测试的结束条件。】
ipa_coverage_planning 是一种全覆盖算法,用于规划无人机的航线,以实现对一个区域的全面覆盖。下面对其代码进行详解。 首先,算法需要一个网格来表示待覆盖的区域。算法中定义了一个 Grid 类来表示网格,并在其构造函数中初始化了网格的大小和分辨率。网格中的每个单元格都用一个数字表示其状态,0 表示未覆盖的区域,1 表示已覆盖的区域。 算法的入口函数是 coverage_planning 函数。在这个函数中,首先创建一个无人机对象,通过传递网格和无人机的相关参数进行初始化。然后进入循环,直到整个区域被完全覆盖为止。 循环中的每一步都遵循以下步骤: 1. 首先,从当前无人机位置开始,计算未覆盖区域中离无人机最近的点,作为下一个目标点。 2. 然后,使用某种路径规划算法(例如 A* 算法)计算从当前位置到目标点的最短路径。 3. 接下来,通过无人机以固定速度沿着路径移动到目标点,并在移动过程中更新每个单元格的覆盖状态。 4. 当无人机到达目标点后,它将停留一段时间,以达到完全覆盖该点的效果。 5. 最后,重新计算下一个目标点,并重复以上步骤。 在算法的实现中,还需要考虑以下几个方面: 1. 无人机的速度和停留时间的设定,以确保完全覆盖每个点的要求。 2. 路径规划算法的选择和实现,以确保无人机能够找到最短路径。 3. 网格的边界条件处理,防止无人机越界。 通过以上详细的代码解释,我们可以更好地理解并实现 ipa_coverage_planning 算法,以实现全覆盖航线的规划。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

你认识小汐吗

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值