【DevOps】SonarQube 指标解读

SonarQube 指标解读

  • 1.BUG 评级计算方法(可靠性)
  • 2.漏洞评级计算方法(安全性)
  • 3.债务和坏味道
  • 4.覆盖率
    • 4.1 代码覆盖率
    • 4.2 分支覆盖率
    • 4.3 单元测试覆盖率
  • 5.重复

【DevOps】SonarQube 指标解读_第1张图片

1.BUG 评级计算方法(可靠性)

  • ✅ A:表示代码无 Bug,最高级别
  • ✅ B:代码有一个 次要 Bug,等级评估为 B
  • ✅ C:代码有一个 重要 Bug,等级评估为 C
  • ✅ D:代码有一个 严重 Bug,等级评估为 D
  • ✅ E:代码有一个 阻断 Bug,等级评估为 E,最低级别

BUG 级别描述:

级别
详细描述信息
次要 界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等。如:错别字、界面格式不规范,页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正确,用户体验感受不好,可以优化性能的方案等。
重要 功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性。如:操作时间长、查询时间长、格式错误、边界条件错误,删除没有确认框、数据库表中字段过多等。
严重 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等。如:软件中数据保存后数据库中显示错误,用户所要求的功能缺失,程序接口错误,数值计算统计错误等。
阻断 阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环,导致数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块缺失等问题。如:代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等。

2.漏洞评级计算方法(安全性)

  • ✅ A:表示代码无漏洞,最高级别
  • ✅ B:代码有一个 次要 漏洞,等级评估为 B
  • ✅ C:代码有一个 重要 漏洞,等级评估为 C
  • ✅ D:代码有一个 严重 漏洞,等级评估为 D
  • ✅ E:代码有一个 阻断 漏洞,等级评估为 E,最低级别

漏洞级别描述:

级别
详细描述信息
次要 能够获取一些数据,但不属于核心数据的操作; 在条件严苛的环境下能够获取核心数据或者控制核心业务的操作; 需要用户交互才可以触发的漏洞。包括但不限于 XSS 漏洞、CSRF 漏洞、点击劫持。
重要 需要在一定条件限制下,能获取服务器权限、网站权限与核心数据库数据的操作。包括但不限于交互性代码执行、一定条件下的注入、特定系统版本下的 getshell 等; 任意文件操作漏洞。包括但不限于任意文件写、删除、下载,敏感文件读取等操作; 水平权限绕过。包括但不限于绕过限制修改用户资料、执行用户操作。
严重 直接获取普通系统权限的漏洞。包括但不限于远程命令执行、代码执行、上传 webshell、缓冲区溢出等; 严重的逻辑设计缺陷和流程缺陷。包括但不限于任意账号密码修改、重要业务配置修改、泄露; 可直接批量盗取用户身份权限的漏洞。包括但不限于普通系统的 SQL 注入、用户订单遍历; 严重的权限绕过类漏洞。包括但不限于绕过认证直接访问管理后台、Cookie 欺骗。 运维相关的未授权访问漏洞。包括但不限于后台管理员弱口令、服务未授权访问。
阻断 直接获取重要服务器(客户端)权限的漏洞。包括但不限于远程任意命令执行、上传 webshell、可利用远程缓冲区溢出、可利用的 ActiveX 堆栈溢出、可利用浏览器 use-after-free 漏洞、可利用远程内核代码执行漏洞以及其它因逻辑问题导致的可利用的远程代码执行漏洞; 直接导致严重的信息泄漏漏洞。包括但不限于重要系统中能获取大量信息的 SQL 注入漏洞; 能直接获取目标单位核心机密的漏洞。

3.债务和坏味道

坏味道:是指在代码之中潜在问题的警示信号。并非所有的坏味道所指示的确实是问题,但是对于大多数坏味道,均很有必要加以查看,并作出相应的修改。

债务:每一个问题,Sonar 都会计算出更改这个问题需要花费的时间。通过相加这些时间得出一个总的值称为债务。

【DevOps】SonarQube 指标解读_第2张图片

4.覆盖率

【DevOps】SonarQube 指标解读_第3张图片

指标 中文解释
Lines to Cover 可覆盖行 13242
Uncovered Lines 未覆盖的代码 7943
Conditions to Cover 可覆盖分支 4738
Uncovered Conditions 未覆盖分支 3760

4.1 代码覆盖率

代码覆盖率 ( L i n e   C o v e r a g e ) = 可覆盖行 − 未覆盖的代码 可覆盖行 = 13242 − 7943 13242 = 40.0 % 代码覆盖率(Line\ Coverage) =\frac{可覆盖行 - 未覆盖的代码}{可覆盖行}=\frac{13242-7943}{13242}=40.0\% 代码覆盖率(Line Coverage)=可覆盖行可覆盖行未覆盖的代码=13242132427943=40.0%

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

线路覆盖率 = L C E L 线路覆盖率 = \frac{LC}{EL} 线路覆盖率=ELLC

  • L C LC LC = 覆盖线(Lines to Cover - Uncovered Lines
  • E L EL EL = 可执行行总数(Lines to Cover

4.2 分支覆盖率

分支覆盖率 ( B r a n c h   C o v e r a g e ) = 可覆盖分支 − 未覆盖分支 可覆盖分支 = 4738 − 3760 4738 = 20.6 % 分支覆盖率(Branch\ Coverage) = \frac{可覆盖分支 -未覆盖分支}{可覆盖分支}=\frac{4738-3760}{4738}=20.6\% 分支覆盖率(Branch Coverage)=可覆盖分支可覆盖分支未覆盖分支=473847383760=20.6%或者 条件覆盖率 ( C o n d i t i o n   C o v e r a g e ) = C T + C F 2 × B 条件覆盖率(Condition\ Coverage) = \frac{CT + CF}{2×B} 条件覆盖率(Condition Coverage)=2×BCT+CF

  • C T CT CT = 至少一次被评估为 “真” 的条件
  • C F CF CF = 至少一次被评估为 “假” 的条件
  • B B B = 条件总数(Conditions to Cover

4.3 单元测试覆盖率

它是 Line Coverage 和 Condition Coverage 的混合体。

代码中单元测试的覆盖率,计算方法: C o v e r a g e = C T + C F + L C 2 × B + E L ∗ 100 % Coverage=\frac{CT+CF+LC}{2×B+EL}*100\% Coverage=2×B+ELCT+CF+LC100%

  • C T CT CT:至少有一次被判断为 true 的条件数
  • C F CF CF:至少有一次被判断为 false 的条件数
  • L C LC LC:已覆盖的行数(Lines to Cover - Uncovered Lines
  • B B B:条件总数(Conditions to Cover
  • E L EL EL:所有可执行的代码总行数(Lines to Cover

5.重复

重复度 = 重复行数 总行数 ∗ 100 % = D u p l i c a t e d   L i n e s L i n e s ∗ 100 % 重复度=\frac{重复行数}{总行数}*100\%=\frac{Duplicated\ Lines}{Lines}*100\% 重复度=总行数重复行数100%=LinesDuplicated Lines100%

你可能感兴趣的:(#,DevOps,#,流程管理,devops,sonarqube,ci/cd,ci,代码覆盖率,代码规范,代码审查)