sonar覆盖率、代码覆盖率、分支覆盖率的计算方式

这篇具有很好参考价值的文章主要介绍了sonar覆盖率、代码覆盖率、分支覆盖率的计算方式。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

代码质量的覆盖率分为三种,覆盖率、代码覆盖率、分支覆盖率,那每一种的计算方式是怎么样的呢?

举例:

sonar覆盖率、代码覆盖率、分支覆盖率的计算方式

上面最有疑惑的是覆盖率,不知道怎么算出了来的,后面再说。

通过sonarqube可以分析出:

指标
可覆盖行(lines_to_cover) 13242
未覆盖的代码(uncovered_lines) 7943
可覆盖分支(conditions_to_cover) 7943
未覆盖分支(uncovered_conditions) 7943

代码覆盖率

代码覆盖率(line_coverage) = (可覆盖行 - 未覆盖的代码)/可覆盖行

或者

行覆盖率 ( line_coverage):在给定的代码行上,行覆盖率只是回答“这行代码是否在单元测试执行期间被执行过?”的问题。它是单元测试覆盖线的密度:

线路覆盖率 = LC / EL
其中:

LC = 覆盖线 ( lines_to_cover - uncovered_lines)
EL = 可执行行总数 ( lines_to_cover)

分支覆盖率

分支覆盖率(branch_coverage) = (可覆盖分支 -未覆盖分支 )/可覆盖分支

或者:

条件覆盖率 = (CT + CF) / (2*B)
其中:

CT = 至少一次被评估为“真”的条件
CF = 至少一次被评估为“假”的条件
B = 条件总数

覆盖率(coverage)

它是Line coverage和Condition coveragecoverage的混合体

计算公式为:Coverage = (CT + CF + LC)/(2*B + EL)

CT = 至少一次被评估为“真”的条件
CF = 至少一次被评估为“假”的条件
LC = 已覆盖行 = lines_to_cover - uncovered_lines
B = 条件总数(conditions_to_cover)
EL = 可执行行总数 (lines_to_cover)

参考 https://docs.sonarqube.org/latest/user-guide/metric-definitions/

其他

条件覆盖 ( branch_coverage):在包含一些布尔表达式的每一行代码中,条件覆盖回答了以下问题:“每个布尔表达式是否都被评估为true?false”。这是在单元测试执行期间遵循的流程控制结构中可能条件的密度。

条件覆盖率 = (CT + CF) / (2*B)
其中:

CT = 至少一次被评估为“真”的条件
CF = 至少一次被评估为“假”的条件
B = 条件总数
新代码的条件覆盖率 ( ):此定义与条件覆盖率new_branch_coverage相同,但仅限于新的/更新的源代码。

条件覆盖率命中 ( branch_coverage_hits_data):涵盖条件的列表。

Conditions by line ( conditions_by_line):按行的条件数。

按行覆盖的条件 (covered_conditions_by_line):按行覆盖的条件数。


Coverage : Line coverage和Condition coveragecoverage的混合体。它的目标是为“单元测试覆盖了多少源代码?”这个问题提供更准确的答案。

覆盖率 = (CT + CF + LC)/(2*B + EL)
其中:

CT = 至少一次被评估为“真”的条件
CF = 至少一次被评估为“假”的条件
LC = 覆盖线 = 覆盖线-未覆盖线
B = 条件总数
EL = 可执行行总数 ( lines_to_cover)
新代码的覆盖率 ( ):此定义与覆盖率new_coverage相同,但仅限于新的/更新的源代码。


行覆盖率 ( line_coverage):在给定的代码行上,行覆盖率只是回答“这行代码是否在单元测试执行期间被执行过?”的问题。它是单元测试覆盖线的密度:

线路覆盖率 = LC / EL
其中:

LC = 覆盖线 ( lines_to_cover - uncovered_lines)
EL = 可执行行总数 ( lines_to_cover)
新代码的线路覆盖率 ( ):此定义与线路覆盖率new_line_coverage相同,但仅限于新的/更新的源代码。

Line coverage hits ( coverage_line_hits_data): 覆盖线的列表。

要覆盖的行数 ( lines_to_cover):单元测试可以覆盖的代码行数(例如,空白行或完整注释行不被视为要覆盖的行数)。
新代码要覆盖的行数 ( ):此定义与要覆盖的行数new_lines_to_cover相同,但仅限于新的/更新的源代码。


跳过的单元测试 ( skipped_tests):跳过的单元测试数。


未覆盖条件 ( uncovered_conditions):单元测试未覆盖的条件数。

新代码的未覆盖条件 ( ):此定义与未覆盖条件new_uncovered_conditions相同,但仅限于新的/更新的源代码。

未覆盖行数 ( uncovered_lines):未被单元测试覆盖的代码行数。

新代码上的未覆盖行 ( ):此定义与未覆盖行new_uncovered_lines相同,但仅限于新的/更新的源代码。


单元测试 ( tests):单元测试的数量。

单元测试持续时间 (test_execution_time):执行所有单元测试所需的时间。

单元测试错误 ( test_errors):失败的单元测试数。

单元测试失败 ( test_failures):因意外异常而失败的单元测试数。

单元测试成功密度(%) (test_success_density):测试成功密度=(单元测试-(单元测试错误+单元测试失败))/(单元测试)*100文章来源地址https://www.toymoban.com/news/detail-462164.html

到了这里,关于sonar覆盖率、代码覆盖率、分支覆盖率的计算方式的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Google代码覆盖率最佳实践

    软件质量保障: 所寫即所思|一个阿里质量人对测试的所感所悟。 谷歌一直倡导的领域之一是使用代码覆盖率数据评估风险并识别测试中的真空。然而,代码覆盖率的价值一直是个争议的话题。每次聊到代码覆盖率时,似乎都会引发无尽的争论。由于大家固守自己阵营,所以

    2024年01月16日
    浏览(50)
  • 单元测试——测试代码功能及代码覆盖率

    目录 目录 前言 一、单元测试是什么? 二、前置准备  三、测试代码  四、示例  五:单元测试覆盖率 单元测试的写法不固定,这里以我自己的一种写法为例,算是很简单的一种写法           单元测试其实就是写一些测试函数,测试代码的功能是否正常运行,一般如果

    2024年02月07日
    浏览(37)
  • Python:代码覆盖率工具coverage

    简介 :覆盖率测量通常用于衡量测试的有效性。它可以显示您的代码的哪些部分正在被测试执行,哪些不是。coverage是一个测量 Python 程序代码覆盖率的工具。它监视您的程序,注意代码的哪些部分已被执行,然后分析源代码以识别可能已执行但未执行的代码。 安装: 官方文

    2024年02月09日
    浏览(34)
  • Lombok导致代码单元测试覆盖率崩塌

    Lombok 由于其使用的便利性, 目前流传非常广泛。甚至有呼声希望其能被Java官方引入,成为JDK的一部分。 当然凡事都有两面性,Lombok的引入也是有代价的。一时注释一时爽,结果导致代码在不知不觉中翻了好几倍。 例如以下几个简单的注解,背后是N多个自动生成的方法: @Da

    2024年02月07日
    浏览(41)
  • Python代码覆盖率分析工具Coverage

    目录 简介 安装 命令行中使用 调用API使用 Coverage是一个Python代码覆盖率分析工具,它可以用于衡量Python测试代码的质量。通过给代码执行带来的覆盖率数据,Coverage可以帮助开发人员找出被回归测试代码中的漏洞,并且指明哪些代码没有被测试到。 Coverage可以让你知道:哪些

    2024年02月11日
    浏览(36)
  • 如何有效保证Java代码单元测试覆盖率

    我们在实际项目开发过程中,不同level的童鞋由于专业技能的层次不同,导致在参与实际开发的业务代码中经常会出现各种bug,项目管理中好的pm或许会给充足的时间来让开发童鞋们定位修复这些bug,也有各种客观原因的PM不会在项目中预留这些时间,往往就需要开发自己通过

    2023年04月17日
    浏览(46)
  • OpenHarmony本地代码和接口覆盖率可视化操作梳理

    目录 一. 修改gn文件,编译执行测试套 1. 修改业务侧BUILD.gn文件,增加编译选项 2.设置lcov统计“branch coverage”的方法 3. 编译测试版本+目标用例 4. 在windows下搭建执行环境,执行测试用例 5. 查看测试生成gcda文件 二. 使用本地代码覆盖率脚本 7. 修改python脚本中的路径 8. 执行脚

    2023年04月26日
    浏览(34)
  • 单元测试必备:Asp.Net Core代码覆盖率实战,打造可靠应用 !

    在前几章我们深度讲解了单元测试和集成测试的基础知识,这一章我们来讲解一下 代码覆盖率 ,代码覆盖率是单元测试运行的 度量值 ,覆盖率通常以百分比表示,用于衡量代码被测试覆盖的程度,帮助开发人员评估测试用例的质量和代码的健壮性。常见的覆盖率包括语句覆盖

    2024年04月23日
    浏览(43)
  • cmake + gtest安装使用 C++单元测试 gcov locv代码覆盖率

    CMakeLists.txt速查简单编写 打开–g3 选项,去掉-O2以上级别的代码优化选项;否则编译器会对代码做一些优化,例如行合并,从而影响行覆盖率结果; 这里我比较懒就没有加 加到test目录下的CMakeLists.txt即可 , 其中代码编译完之后会在test/CMakeFiles/test.dir/ 生成test.cpp.gcno文件, 在运

    2024年02月05日
    浏览(41)
  • springboot项目使用Junit5 + mockito + jacoco 实现单元测试以及代码覆盖率检查

    在创建springboot项目时会默认添加spring-boot-starter-test依赖,其中已经包含了junit、mockito依赖,根据springboot版本的不同junit和mockito的版本也会有所不同 先说一下各自功能: junit只说一点,junt4和junit5的注解不同,使用方式略有差异,其他不赘述了,基本用法都懂。 mockito是mock的

    2023年04月23日
    浏览(55)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包