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