sonar 中质量指标（度量）

这不是一个详尽的指标列表。有关完整列表，请参阅SonarQube实例上的api / metrics WebAPI。

复杂

名称

键

描述

复杂

这是根据代码路径数计算的复杂度。每当函数的控制流程分裂时，复杂性计数器就会增加1。每个函数的最小复杂度为1.由于关键字和功能性的原因，这种计算方式因语言而略有差异。

更多细节

认知复杂性

cognitive_complexity

理解代码的控制流程有多困难。请参阅https://www.sonarsource.com/resources/white-papers/cognitive-complexity.html以获取有关用于计算此度量的数学模型的完整说明。

重复

名称	键	描述
重复的块	duplicated_blocks	重复行数的块数。对于被认为是重复的代码块：非Java项目：应该有至少100个连续和重复的令牌。这些令牌至少应该分布在： COBOL的30行代码用于ABAP的20行代码其他语言的10行代码 Java项目：无论有多少个令牌和行，至少应该有10个连续的重复语句。在检测重复时忽略缩进和字符串文字中的差异。
重复的文件	duplicated_files	涉及重复的文件数量。
重复的线条	duplicated_lines	涉及重复的行数。
重复行数（％）	duplicated_lines_density	重复密度= 重复行数 / 行数 * 100

问题

名称	键	描述
新问题	new_violations	新问题的数量。
新的xxxxx问题	new_xxxxx_violations	严重性为xxxxx，xxxxx为b locker，critical，major，minor或info的新问题的数量。
问题	违规	问题的数量。
xxxxx问题	xxxxx_violations	严重性为XXXXX，XXXXX为阻滞剂，严重，主要，次要或信息的问题数量。
假阳性问题	false_positive_issues	误报问题的数量
开放式问题	开放式问题	状态为“打开”的问题数量
确认的问题	confirmed_issues	已确认状态的问题数量
重新开放的问题	reopened_issues	状态被重新打开的问题的数量

严重

严重	描述
拦截器	操作/安全风险：此问题可能会使整个应用程序在生产中不稳定。例如：调用垃圾回收器，不关闭套接字等。
危急	操作/安全风险：此问题可能会导致生产中的意外行为，而不会影响整个应用程序的完整性。例如：NullPointerException，严重捕获异常，缺少单元测试等。
重大的	这个问题可能会对*生产力产生*重大影响。例如：过于复杂的方法，封装周期等
次要	这个问题可能会对*生产力*产生潜在的和次要的影响。例如：命名约定，Finalizer只是调用超类终结器等。
信息	未知或尚未明确定义的安全风险或对生产力的影响。

可维护性

名称	键	描述
代码嗅觉	code_smells	代码气味的数量。
新代码嗅觉	new_code_smells	新的代码气味的数量。
可维修性评级（以前称为SQALE评级）	sqale_rating	您的项目评级与您的技术债务比率相关。默认的可维护性评估网格是： A = 0-0.05，B = 0.06-0.1，C = 0.11-0.20，D = 0.21-0.5，E = 0.51-1 可维护性评估量表可以交替陈述，如果未解决的补救成本是： <=已进入应用程序的时间的5％，评级为A. 6至10％之间的评级是B 在11％至20％之间的评级是C 在21到50％之间，评级是D 任何超过50％是E
技术债务	sqale_index	努力解决所有可维护性问题。度量在数据库中以分钟存储。当以天为单位显示数值时，假定每天8小时。
新代码的技术债务	new_technical_debt	新代码的技术债务
技术债务比率	sqale_debt_ratio	开发软件的成本与修复软件的成本之间的比率。技术债务比率公式为：修复成本/开发成本其中可以重申为：修复成本/（开发1行代码的代价*代码行数）开发一行代码的成本值为0.06天。
新代码的技术债务比率	new_sqale_debt_ratio	开发代码的成本与泄漏期间的代码成本之间的比率。

质量盖茨

名称	键	描述
质量门状态	alert_status	与您的项目相关的质量门的状态。可能的值有：ERROR，WARN，OK
质量门详细信息	quality_gate_details	对于您的质量门的所有条件，您知道哪些情况是失败的，哪些不是。

可靠性

名称	键	描述
错误	虫子	错误数量。
新的错误	new_bugs	新bug的数量。
可靠性评级	reliability_rating	A = 0错误 B =至少1次轻微错误 C =至少1次重大错误 D =至少1次严重错误 E =至少1次阻止程序错误
可靠性修复努力	reliability_remediation_effort	努力解决所有错误问题。度量在数据库中以分钟存储。当以天为单位显示数值时，假定每天8小时。
新代码的可靠性修复工作	new_reliability_remediation_effort	与在泄漏期间更改的代码的可靠性修复工作相同。

安全

名称	键	描述
漏洞	漏洞	数v ulnerabilities。
新的漏洞	new_vulnerabilities	新漏洞的数量。
安全评级	security_rating	A = 0漏洞 B =至少1次轻微漏洞 C =至少1次重大漏洞 D =至少1次严重漏洞 E =至少1次阻止漏洞
安全补救努力	security_remediation_effort	努力解决所有的V ulnerability问题。度量在数据库中以分钟存储。当以天为单位显示数值时，假定每天8小时。
新代码的安全修复工作	new_ 安全_remediation_effort	与在泄漏期间更改的代码相同的安全补救措施。

尺寸

公

键

描述

类

类的数量（包括嵌套类，接口，枚举和注释）。

评论行

comment_lines

包含注释或注释代码的行数。

非重要的注释行（空注释行，仅包含特殊字符的注释行等）不会增加注释行的数量。

以下代码段包含9条注释行：

 
                 /**                                    +0 => empty comment line 
                
                 *                                     +0 => empty comment line 
                
                 * This is my documentation            +1 => significant comment 
                
                 * although I don't                    +1 => significant comment 
                
                 * have much                           +1 => significant comment 
                
                 * to say                              +1 => significant comment 
                
                 *                                     +0 => empty comment line 
                
                 ***************************           +0 => non-significant comment 
                
                 *                                     +0 => empty comment line 
                
                 * blabla...                           +1 => significant comment 
                
                 */                                     
                 + 
                 0  
                 => empty comment line 
                
                 /**                                    +0 => empty comment line 
                
                 * public String foo() {               +1 => commented-out code 
                
                 *   System.out.println(message);      +1 => commented-out code 
                
                 *   return message;                   +1 => commented-out code 
                
                 * }                                   +1 => commented-out code 
                
                 */                                     
                 + 
                 0  
                 => empty comment line

更多细节

注释（％）

comment_lines_density

注释行的密度= 注释行 /（代码行 + 注释行）* 100

有了这样一个公式：

50％表示代码行数等于注释行数
100％表示该文件只包含注释行

目录数量。

档

文件数量。

行

线

物理线数（回车数）。

代码行

ncloc

包含至少一个既不是空白也不是制表符，也不是注释部分的字符的物理行数。

更多细节

每种语言的代码行数 ncloc_language_distribution 按语言分布的代码非注释行

功能

功能数量。根据语言的不同，函数可以是函数，也可以是方法或段落。

更多细节

项目

视图中的项目数量。

声明

报表数量。

更多细节

测试

公

键

描述

公

键

描述

条件覆盖

branch_coverage

在包含一些布尔表达式的每行代码中，条件覆盖率只会回答以下问题：'每个布尔表达式是否都被评估为true和false？'。这是在单元测试执行期间遵循的流量控制结构中可能条件的密度。

 
                 Condition coverage = (CT + CF) / ( 
                 2 
                 *B) 
                
                 where 
                
                 CT = conditions that have been evaluated to  
                 'true'  
                 at least once 
                
                 CF = conditions that have been evaluated to  
                 'false'  
                 at least once 
                
                 B = total number of conditions

新代码的条件覆盖

new_branch_coverage

与条件覆盖范围相同，但仅限于新的/更新的源代码。

条件覆盖命中 branch_coverage_hits_data 涵盖的条件列表。

条件按线路 conditions_by_line 线条件数。

按行覆盖条件 covered_conditions_by_line 按行覆盖的条件数量。

覆盖

它是线路覆盖和条件覆盖的组合。它的目标是为以下问题提供更准确的答案：单元测试覆盖了多少源代码？

 
                 Coverage = (CT + CF + LC)/( 
                 2 
                 *B + EL) 
                
                 where 
                
                 CT = conditions that have been evaluated to  
                 'true'  
                 at least once 
                
                 CF = conditions that have been evaluated to  
                 'false'  
                 at least once 
                
                 LC = covered lines = lines_to_cover - uncovered_lines 
                
                 B = total number of conditions 
                
                 EL = total number of executable lines (lines_to_cover)

覆盖新代码

new_coverage

与Coverage相同，但仅限于新的/更新的源代码。

线路覆盖

line_coverage

在给定的代码行中，行覆盖范围只是回答以下问题：在执行单元测试期间是否已执行此代码行？它是由单元测试覆盖的线的密度：

 
                 Line coverage = LC / EL 
                
                 where 
                
                 LC = covered lines (lines_to_cover - uncovered_lines) 
                
                 EL = total number of executable lines (lines_to_cover)

新代码的在线覆盖率 new_line_coverage 与线路覆盖范围相同，但仅限于新的/更新的源代码。

线路覆盖命中 coverage_line_hits_data 被覆盖的线列表。

要覆盖的行

lines_to_cover

单元测试可以覆盖的代码行数（例如，空白行或完整注释行不被视为要覆盖的行）。

包含新代码的行 new_lines_to_cover 与要覆盖的行相同，但仅限于新的/更新的源代码。

跳过单元测试 skipped_tests 跳过的单元测试次数。

未覆盖的条件

uncovered_conditions

未被单元测试覆盖的条件数量。

揭秘条件的新代码 new_uncovered_conditions 与未覆盖的条件相同，但仅限于新的/更新的源代码。

未覆盖的线

uncovered_lines

未被单元测试覆盖的代码行数。

在新代码中发现线条 new_uncovered_lines 与Uncovered行相同，但仅限于新的/更新的源代码。

单元测试

测试

单元测试次数。

单元测试时间 test_execution_time 执行所有单元测试所需的时间。

单元测试错误

test_errors

失败的单元测试数量。

单元测试失败

test_failures

发生意外异常的单元测试失败次数。

单元测试成功密度（％） test_success_density 测试成功密度=（单元测试 - （单元测试错误 + 单元测试失败））/ 单元测试 * 100

集成测试覆盖率和总体测试覆盖率（单元测试+集成测试）存在相同的度量标准。

集成测试和总体测试不存在测试执行的度量标准。

sonar连接：https://docs.sonarqube.org/display/SONAR/Metric+definitions#Metricdefinitions-Tests

stack overflow:

https://stackoverflow.com/questions/11561622/what-is-the-difference-between-code-coverage-and-line-coverage-in-sonar