白盒测试也称逻辑驱动测试,是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例,主要用于软件程序验证,属于基于代码的测试技术。与之相对应的黑盒测试是从用户角度对软件进行测试。
JaCoCo(Java Code Coverage)是一个开源的Java代码覆盖率工具,它主要用于评估Java程序的测试完整性。通过跟踪测试过程中执行的代码,JaCoCo能够提供多种覆盖率指标,帮助开发者确保代码的测试质量。这些指标包括指令覆盖、分支覆盖、圈复杂度、行覆盖、方法覆盖和类覆盖。
ant是构建工具,内置任务和可选任务组成的.Ant运行时需要一个XML文件(构建文件)。
2.在Maven项目中引入JaCoCo插件,执行maven jacoco生成代码覆盖率报告
有几种适用于Java的开源覆盖技术。在实现Eclipse插件EclEmma时,观察到它们都不是真正为集成而设计的。它们中的大多数特别适合特定工具(Ant任务,命令行,IDE插件),并且不提供允许在不同上下文中嵌入的文档化API。 EMMA和Cobertura是最好的和广泛使用的两个开源工具。这两个工具都不再由原始作者积极维护,并且不支持当前的Java版本。由于缺乏回归测试,因此很难进行维护和添加功能。
前面有一篇 文章 使用 Python + Coverage 来统计测试用例的代码覆盖率
测试覆盖率和代码覆盖率是衡量代码有效性的最流行方法。这些术语有时会同时出现,因为它们的基本原理相同。但是它们并不是那么一致。很多时候,测试团队和开发团队对这两个术语的使用感到困惑。下面详细讨论代码覆盖率和测试覆盖率之间的区别的原因。
有几种适用于Java的开源覆盖技术。在实现Eclipse插件EclEmma时,观察到它们都不是真正为集成而设计的。它们中的大多数特别适合特定工具(Ant任务,命令行,IDE插件),并且不提供允许在不同上下文中嵌入的文档化API。EMMA和Cobertura是最好的和广泛使用的两个开源工具。这两个工具都不再由原始作者积极维护,并且不支持当前的Java版本。由于缺乏回归测试,因此很难进行维护和添加功能。
我们今天简单介绍 JaCoCo 的实际使用示例,它是目前在大多数 Java 项目中应用最广泛的覆盖率检测框架
本文主要介绍vivo内部研发平台使用JaCoCo实现测试覆盖率的实践,包括JaCoCo原理介绍以及在实践过程中遇到的新增代码覆盖率统计问题和频繁发布导致覆盖率丢失问题的解决办法。
Lombok 由于其使用的便利性, 目前流传非常广泛。甚至有呼声希望其能被Java官方引入,成为JDK的一部分。
目前有赞共享技术团队测试介入的微服务应用有几百个,大部分底层应用的单测覆盖率在 70% 以上,同时测试组提供的多纬度集成测试自动化的覆盖率也在 70% 以上。有赞的业务发展非常快,当存量代码较多时,新项目功能测试的整体覆盖率偏低是正常现象,另外开发提测时,并不能依据已有的全量覆盖率来判断对新增代码的自测完成度,基于这个背景,我们研发了增量代码覆盖率工具,作为项目质量的参考纬度之一,支持统计功能测试、单测和集成测试,并集成到了 DevOps 平台。
jacoco 是一个开源的覆盖率工具,它针对的开发语言是 java。其使用方法很灵活,可以嵌入到 ant、maven 中;可以作为 Eclipse 插件;可以作为 javaAgent 探针监控 java 程序等等。
如图所示,在master分支提交了HelloController,然后从master拉了个新分支test;提交了第1次代码,增加了WorldController;提交了第2次代码,增加了DonController。增量的获取方式有两种:
作为一个测试人员,保证产品的软件质量是其工作首要目标,为了这个目标,测试人员常常会通过很多手段或工具来加以保证,覆盖率就是其中一环比较重要的环节。
测试覆盖率是一种度量指标,指的是在运行一个测试集合时,代码被执行的比例。它的一个主要作用就是告诉我们有多少代码测试到了。其实更严格地说,测试覆盖率应该叫代码覆盖率,只不过大多数情况它都是被用在测试的场景下,所以在很多人的讨论中,并不进行严格的区分。
精准测试是近些年比较热的一个话题。笔者一直认为这是一种治疗大厂“富贵病”的“靶向药”。对于一般公司而言,面对的问题是自动化测试用例过少,甚至没有的问题,还没到测试用例过剩需要挑拣的地步。因此,如果没有过万的接口自动化用例,可以不用拉到底,只了解一下代码覆盖率统计即可。 精准测试的一个技术基础,就是覆盖率统计。通过覆盖率报告,可以了解到一次执行过程,对被测应用的代码覆盖情况,包括类、方法、代码行等。再通过代码增量的统计,就可以了解本次新增代码的覆盖率情况。
关于JAVA代码覆盖率工具JaCoCo,作者会通过三篇来介绍,分别为原理篇、实践篇和踩坑篇,先从原理篇开始介绍~ 一、覆盖率定义 作为一个测试人员,保证产品的软件质量是其工作首要目标,为了这个目标,测试人员常常会通过很多手段或工具来加以保证,覆盖率就是其中一环比较重要的环节。 我们通常会将测试覆盖率分为两个部分,即“需求覆盖率”和“代码覆盖率”。 需求覆盖:指的是测试人员对需求的了解程度,根据需求的可测试性来拆分成各个子需求点,来编写相应的测试用例,最终建立一个需求和用例的映射关系,以用例的测试结果来验证
在做单元测试时,代码覆盖率常常被拿来作为衡量测试好坏的指标,甚至,用代码覆盖率来考核测试任务完成情况,比如,代码覆盖率必须达到80%或 90%。
距离上篇文章挺久的了,天天的也不知道在干嘛,时间就溜过去了。今天聊聊前段时间整理的jacoco。Jacoco是一个针对java语言开源的代码覆盖率工具。
JAVA代码覆盖率工具JaCoCo-原理篇和JAVA代码覆盖率工具JaCoCo-实践篇已经给大家介绍过了,本篇为踩坑篇,这里的话题不是说明JaCoCo有什么问题,而是把过程中遇到的几个棘手问题的解决方法分享给大家,只要细心,放下焦虑的心态,问题都可以解决的。 一、覆盖率踩过的坑 在项目中使用JaCoCo覆盖率的时候,也遇到过各种奇葩的问题,在这里列出来分享下,问题和实际的项目关系密切,希望对有遇到过相似问题的童鞋有所启发。 1.1 覆盖率包在部分手机6.0上安装失败 事情起因:在测试新功能时,用打的覆盖率包
之前在做接口测试代码覆盖率(jacoco)方案的时候,漏了一些东西,这篇文章补一下。做使用jacoco做接口代码覆盖率测试的过程中,遇到一个问题:测试报告里面信息太多,很杂乱没有针对性,很多都是config和bean以及适配器的类,绝大部分没有业务代码,统计出来的覆盖率受影响比较大,不够准确。
版本提测后,开发往往会说,影响范围比较大,做个主链路或者全量回归吧,我只改了几行代码,为什么要回归这么长时间?等等。
前言 美团点评业务快速发展,新项目新业务不断出现,在项目开发和测试人员不足、开发同学粗心的情况下,难免会出现少测漏测的情况,如何保证新增代码有足够的测试覆盖率是我们需要思考的问题。 Bad-Case
每种编程语言都有自己的单元测试框架。执行单元测试的工作一般由构建工具来完成。Jenk-ins做的只不过是执行这些构建工具的单元测试命令,然后对测试报告进行收集,并呈现。
在我们实际的工作中,当完成程序的开发后,需要提交给测试人员进行测试,经过测试人员测试后,代码才能上线到生产环境。
本文系列将介绍Sonar在实际工程项目中落地的场景,例如: 1)多语言项目的扫描,如JAVA/JS/C++/C#/PLSQL 2)多分支扫描 3)覆盖率如何统计 等等。 不在讨论范围内的问题 1)自定义扫描规则? 2)扫出来的问题,怎么让开发及时修复? 本文作为开篇,将介绍 1)Sonar Scanner的工作机制, 2)Java项目中利用 Maven的Sonar Scanner 插件进行扫描的配置和步骤 3)使用Token,多Module项目扫描和忽略等一些实际问题。
美团点评业务快速发展,新项目新业务不断出现,在项目开发和测试人员不足、开发同学粗心的情况下,难免会出现少测漏测的情况,如何保证新增代码有足够的测试覆盖率是我们需要思考的问题。
对于 JaCoCo,有所了解但又不是很熟悉。 "有所了解"指的是在 CI 实践中已经使用 JaCoCo 对单元测试代码覆盖率统计: 当代码 push 到代码仓库后,用 JaCoCo 进行单元测试代码覆盖率统计,并将相应数据推送到 SonarQube。 "不是很熟"指的是应用场景也仅限于此,并未进行过多研究与实践。
当要求质量内建、测试左移、持续集成、DevOps,代码的增量覆盖率几乎是必定会被提出来的话题。这个方案明确了"谁的代码谁负责"的原则,和当年“小岗村包产到户”一样,开发人员只需要为自己的提交/合并请求来提供代码覆盖率数据,而不再需要为整个团队的代码库和历史旧账掉头发了。团队负责人也乐于实施这样的“最佳实践”,树立一个带电的“质量门禁”,没有达标的,一律拒绝签入或者合并。
单元测试是保证项目代码质量的有力武器,但是有些业务场景,依赖的第三方没有测试环境,这时候该怎么做Unit Test呢,总不能直接生产环境硬来吧?
这篇博客文章描述了我们如何使用JaCoCo Maven插件为单元和集成测试创建代码覆盖率报告。
最近做了一些关于代码覆盖率工具的调查,对一些主流的代码覆盖率的工具比如 Gcov,JaCoCo,Istanbul 等都做了一些实践和持续集成的工作,也有了一定的了解。
JaCoCo的概念我就不在这里复述了网上有很多资料介绍,这里主要提一下他的两种插桩模式:On-the-fly和Offline
代码覆盖率,尤其是增量代码覆盖率,是质量门禁的重要指标之一。由于一些不可名状的原因,团队原先提供质量门禁服务的工具暂时停服了,因此需要另外寻找一个工具来代替提供此项服务。于是,笔者就Super-Jacoco做了一个简单的POC。
测试覆盖率报告和测试执行报告是评估代码质量的重要指标。测试覆盖率报告告诉您测试用例涵盖的代码百分比。测试执行报告告诉您已运行哪些测试及其结果。
单元测试是验证函数是否按预期执行的利器,是保障代码质量的有效手段之一。项目能够通过单元测试找到代码中潜在的问题,充足的单元测试用例也是代码使用方法的最好诠释。通常项目的单测质量采用单测覆盖率进行指标衡量,本文结合在项目中的实践,给出maven多模块项目该如何集成jacoco及codecov单测工具。
如果MR/PR中的代码均来自某位开发人员,那么如果质量门禁未通过,这个发起MR/PR的人就是事主,找到他解决即可。这也是通常质量门禁红绿灯背后的逻辑。
小时候大家应该都玩过一个游戏,游戏很简单,就是找不同,在规定时间内两幅图直接的差异点找到就算赢,越快越好,就像下面这样:
在第一篇文章super-jacoco单元测试覆盖率度量实践-1中,笔者介绍了Super-Jacoco的单元测试覆盖率统计只要向Super-Jacoco服务发送如下的一个post请求
经常有人问这样的问题:“我们在做单元测试,那测试覆盖率要到多少才行?”。答案其实很简答,“作为指标的测试覆盖率都是没有用处的。”
代码覆盖率作为一个指导性指标,可以一定程度上反应测试的完备程度,是软件质量度量的一种手段。100%覆盖的代码并不意味着100%无bug的应用,代码覆盖率作为质量目标没有任何意义,而我们应该把它作为一种发现未被测试覆盖的代码的手段。
前面两篇都是讲了jacoco配合Andorid app 代码覆盖的配置以及单人测试生成覆盖率测试报告,那遇到多人测试一个版本,要怎么合并,来评估这个版本的测试范围跟测试质量,这才比较实用;这个就是今天要说的内容 ~其实也很简单,就是下载不同的jacoco 覆盖率配置文件,该文件已被修改过,可以合并多份.ec文件并对比生成一份报告;
本文翻译自国外论坛 medium,原文地址:本文翻译自国外论坛 medium,原文地址:https://medium.com/gitconnected/basics-of-ci-cd-a98340c60b04
覆盖率是用来衡量单元测试对功能代码的测试情况,通过统计单元测试中对功能代码中行、分支、类等模拟场景数量,来量化说明测试的充分度。
在单元测试中,很容易知道已经覆盖了哪些代码区域。但是我们能及时知道API调用的动态范围吗?我们一直在思考,既然已经编写了许多 E2E 测试用例,但是我们应该继续编写多少剩余测试?
精准测试系列《四》分享了如何通过测试管理平台进行代码覆盖率的统计,今天的分享内容是在发布平台进行获取覆盖率报告的逻辑,分享的大致思路还是从前端页面发起请求,然后后端接收到请求继续处理这样的逻辑来讲解。
领取专属 10元无门槛券
手把手带您无忧上云