单元测试覆盖率

2024-06-04 10:04
文章标签 单元测试 覆盖率

本文主要是介绍单元测试覆盖率,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

什么是单元测试覆盖率

关于其定义,先来看一下维基百科上的一段描述:

代码覆盖(Code coverage)是软件测试中的一种度量,描述程序中源代码被测试的比例和程度,所得比例称为代码覆盖率。

简单来理解,就是单元测试中代码执行量与代码总量之间的比率。

以一个最简单的例子来直观感受一下:

Service服务类:

public class NumToStringServiceImpl implements NumToStringService {@Overridepublic String num2Str(Integer i) {String str = "";switch (i) {case 1:str = "one";break;case 2:str = "two";break;default:str = "none";}return str;}
}

单元测试类:

public class NumToStringServiceTest {@AutowiredNumToStringService numToStringService;@Testvoid testNum2Str() {String str1 = numToStringService.num2Str(1);assertThat(str1, is("one"));String str2 = numToStringService.num2Str(2);assertThat(str2, is("two"));}
}

从上面的代码中能看出,单元测试方法testNum2Str能够覆盖到服务类num2Str方法的case 1case 2两个分支,覆盖不到default分支。那么覆盖率就是num2Str方法case 1case 2分支的代码量除以方法的总代码量。

单元测试覆盖率框架

单元测试覆盖率常用的框架有JaCoCoEMMACobertura。我们目前(在Jenkins中)使用的是JaCoCo。

JaCoCo可以统计的指标有:

  1. 指令(C0 Coverage):JaCoCo计数的最小单元是单一的Java字节码指令。指令覆盖率提供了关于字节码执行数量、未执行数量的信息。
  2. 分支(C1 Coverage):对所有的ifswitch语句计算分支覆盖率。统计在方法中分支执行数量、未执行数量的信息。但要注意,异常处理不在此计算范围内。
  3. 圈复杂度(Cyclomatic Complexity):对非抽象方法计算圈复杂度,并汇总类、包和组的(圈)复杂度。这个值可以做为单元测试用例是否完全覆盖的参考。
  4. 行(Lines):一行可能包含一条或多条指令,如果至少有一条指令被执行了,那么该行就算作是被执行了。
  5. 方法(Methods):每个非抽象方法至少包含一条指令。如果至少有一条指令被执行了,那么该方法就算作是被执行了。
  6. 类(Classes):如果类中至少有一个方法被执行了,那么该类就算作是被执行了。

注:个人认为,最需要关注的指标是(Lines)和分支(C1 Coverage),其次是方法(Methods)和(Classes),指令(C0 Coverage)和圈复杂度(Cyclomatic Complexity)可以不用关注,因为跟(Lines)和分支(C1 Coverage)其实是差不多的,只不过多了一种参考维度。

查看单元测试覆盖率

在IntelliJ IDEA中已经内置了JaCoCo插件,因此研发可以在本机运行单元测试来查看覆盖率:

1、点击IDE右上侧的"Edit Configurations...":

2、在"Choose coverage runner"中选择JaCoCo:

 

3、点击"Run ... with Coverage"运行:

 

 4、运行完成后会展示分支(C1 Coverage)、(Lines)、方法(Methods)、(Classes)这四个指标:

 5、点击"Generate Coverage Report"可以生成一份html版的所有指标的报告:

 

JaCoCo与持续集成

1、需要在项目的<plugins>中加入JaCoCo插件:

<plugin><groupId>org.jacoco</groupId><artifactId>jacoco-maven-plugin</artifactId><version>0.8.5</version><executions><execution><id>default-prepare-agent</id><goals><goal>prepare-agent</goal></goals></execution><execution><id>default-report</id><goals><goal>report</goal></goals></execution></executions>
</plugin>

目前发现如果项目中不加以上配置,而是在Jenkinsfile中

 以命令的方式去应用JaCoCo,会导致不能生成jacoco.exec,进而无法运行覆盖率测试。

2、在Jenkinsfile中加入

 

exclusionPattern: '**/controller/*.class', sourceExclusionPattern: '**/controller/*.java'

可以过滤掉controller层的检测。因为目前我们的单元测试主要是针对service层的,如果把controller层的类引入进来,会使单元测试覆盖率的值变低。

3、可以在Jenkins(http://${ip}:${port}/job/${your_project}/lastBuild/jacoco/)中查看生成的单元测试覆盖率报告:

 

该报告与IntelliJ IDEA中的报告都是JaCoCo原生的,是准确的。

目前发现SonarQube中的报告一是不准,二是指标不全,建议不要查看SonarQube的报告。

题外话

覆盖率作为衡量单元测试质量的唯一标准是不合理的。比如下面这个例子:

public double cal(double a, double b) {if (b != 0) {return a / b;}
}


仅一个测试用例就可以做到100%的覆盖率,比如cal(10.0, 2.0),但并不代表测试足够全面了,还需要考虑当除数等于0的情况下,代码执行是否符合预期。


---------------------
作者:谷隐凡二
来源:CSDN
原文:https://blog.csdn.net/m0_37570494/article/details/125440949
版权声明:本文为作者原创文章,转载请附上博文链接!
内容解析By:CSDN,CNBLOG博客文章一键转载插件

这篇关于单元测试覆盖率的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1029773

相关文章

springboot+maven搭建的项目,集成单元测试

springboot+maven搭建的项目,集成单元测试 1.在pom.xml文件中引入单元测试的依赖包 <!--单元测试依赖--><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><scope>test</scope></depen

PowerMock 单元测试总结与常见坑解决方案

PowerMock 单元测试总结与常见坑解决方案 官方文档: PowerMock GitHub PowerMock 在单元测试中能够帮助我们解决静态类、final 方法、私有方法等无法轻易 mock 的问题。下面是我在实际使用 PowerMock 时踩过的一些坑,并结合 PowerMock 的一些方法进行总结。 基本依赖和设置 在 Maven 中添加 PowerMock 依赖。在测试

JAVA—单元测试

单元测试:就是针对最小的功能单元(方法),编写测试代码对其进行正确性测试     之前是使用main函数调用来进行检测,无法实现自动化测试 也会影响其他方法的测试 目录 1.junit框架概述 2.junit框架的常见注解 1.junit框架概述 package High_junit;//字符串工具类 用于测试public class String_ju

idea单元测试报错找不到主类

报错截图 主要是单测中没有配置类 在下面的command line 中选择jar manifest 因为条参数过长,这里设置只使用主类 详细解释见: https://www.jianshu.com/p/8322b3b17040

file | 某文件夹【解耦合】下的文件查找功能实现及功能单元测试

文件查找工具 概要思路OS模块 --- 学习版os.getcwd()os.path.dirname(os.getcwd())os.path.dirname() 和 os.path.basename() OS模块 — 实战版单元测试解耦合 概要 梳理业务主逻辑: 查看存放被采集JSON数据的文件夹内的文件列表【所有 包含文件夹下的文件夹下的文件】 这是本节内容聚焦的点和My

【JUnit单元测试框架】

单元测试的概念 单元测试,顾名思义,是针对软件中的最小可测试部分(通常是类或方法)进行的测试。它的目的是确保这些最小单元按照预期工作,从而帮助开发者快速定位和解决问题。单元测试通常遵循“隔离”原则,即测试一个功能单元时,应该尽量减少对其他部分的依赖,以便专注于当前单元的行为。 历史做法及其问题 将所有测试代码都放在main方法中,并通过main方法去调用其他方法进行测试。这种做法存在几个显著

visual studio2015单元测试

尝试引用了包含待测了待测程序的项目,但是不知道该如何调用待测代码,所以只能通过引用生成的库文件 进行单元测试的步骤: 一、创建控制台静态库项目,将要测试的代码编译为库文件 二、创建单元测试项目,引用创建的库文件,并在stdafx.h中包含之前库文件的头文件: 1)直接include头文件的绝对路径 2)将头文件复制到单元测试项目的根目录下,并直接在stdafx.h头文件中include头

软件测试常用工具总结(测试管理、单元测试、接口测试、自动化测试、性能测试、负载测试...)

前言 在软件测试的过程中,多多少少都是会接触到一些测试工具,作为辅助测试用的,以提高测试工作的效率,使用好了测试工具,能对测试起到一个很好的作用,同时,有些公司,也会要求掌握一些测试工具,或者,是在面试时,也会被问到测试工具的,比如,在面试时,最常见的问题便是,你在测试时,用的是什么测试工具?或者,要做性能测试时,要用什么测试工具进行测试会比较好?等等问题。 作为测试人员,了解下现在有哪些

单元测试 Mock不Mock?

文章目录 前言单元测试没必要?Mock不Mock?什么是Mock?Mock的意义何在? 如何Mock?应该Mock什么?Mock 编写示例 总结 前言 前段时间,我们团队就单元测试是否采用 Mock 进行了一番交流,各有各的说法。本文就单元测试 Mock不Mock 给出我的观点,欢迎各位同仁提出不同的意见,共同探讨、相互交流。 单元测试没必要? 我见过好多不写单元测试的项目,

RD单元测试和QA接口测试的区别

1.单元测试 单元测试的基本原则:单元测试应该测试独立的单元模块,这个单元不应依赖于其他模块。 单元测试会强迫你去把各个模块解耦,因为耦合的很紧的模块是很难进行单元测试的,一般情况下,一个普通的程序员在任务很紧的时候很难费劲心思去将代码进行模块化的;当为了单元测试,自己就会去想方设法将模块解耦,这也算是单元测试的一个副产品吧。 单元测试能够进行最仔细的最细致的最方便的最全面的测试;只要测试用