更多原创测试技术文章同步更新到微信公众号 ：三国测，敬请扫码关注个人的微信号，感谢！
原文链接：http://www.cnblogs.com/zishi/p/6766994.html
众所周知Sonar是一个很强大的静态扫描工具，代码提交之后可以自动触发代码扫描，并给出report，因此给开发项目带来了很多便利。
日前我把本地版本升级到6.2了，项目的度量项也增加了许多。看过去一堆的ABCD，A应该是最好，D最差，但是中间的差别还是需要弄清楚。
为了更好的理解，我详细翻看了官方文档，同时也参考了网上一些参考，尤其是坏味道部分，
参考了大神Martin Fowler的《Refactoring: Improving the Design of Existing Code》关于代码重构的一些见解，
最后，我将所有这些资料在这里做一个总结，在此也分享给大家：
1、Reliability可靠性
1.1 Reliability Rating
可靠性比率的计算方法）
A = 0 Bug 最高等级A，表示代码无bug
B = at least 1 Minor Bug 代码只要有一个次要bug，等级就为B
C = at least 1 Major Bug 只要包含一个重要bug，等级将为C
D = at least 1 Critical Bug 只要有一个严重bug，等级评估为D
E = at least 1 Blocker Bug 只要有一个最高等级的阻断级别的bug，可靠性评估为E，最低级别。
1.2 Reliability remediation effort
修复所有缺陷问题成本/耗时
1.3 Reliability remediation effort on new code
在新增代码上修复所有缺陷问题成本/耗时
1.4 备注
图中气泡大小根据bug数变化，bug数越大气泡越大。视觉更加直观。
2、Security安全性
2.1 Security Rating
安全度指标计算方法
A = 0 Vulnerability 没有漏洞时，项目评估为*别A
B = at least 1 Minor Vulnerability 只要包含一个次要漏洞，项目评估为级别B
C = at least 1 Major Vulnerability 只要包含一个重要漏洞，项目评估为级别C
D = at least 1 Critical Vulnerability 只要包含一个严重漏洞，评估为D
E = at least 1 Blocker Vulnerability 只要包含一个阻断漏洞，项目评估为最低级别E
2.2 备注
lines of code 计量方法：包括至少一个字符，不包括空格。
图中气泡大小根据漏洞数变化，漏洞数越大气泡越大。视觉上直观显示。
3、Maintainability可维护性
3.1 Technical Debt
“技术债务”概念，这个概念最早是在 1992 年由 Ward Cunningham 在他的论文“The WyCash Portfolio Management System”中提出的，之后被软件工程界接受并推广，《重构》的作者 Martin Fowler 也在其网站上对技术债务有所介绍。其实原理可以理解为“出来混早晚要还的”，当前不规范的代码，会对以后产品修改的成本造成影响。Technical Debt 计算公式如下：
3.2 开发成本
开发一行代码（LOC）的成本。 示例：如果开发1 LOC的成本估计为30分钟，则此属性的值为30。目前我们采用的是系统默认值30。注意此处成本是指从零开始重写代码所需的成本。
3.3 可维护性
可维护性等级范围从A（非常好）到E（非常差）。 评级由技术债务比率的值决定，技术债务比率是将项目的技术债务与从零开始重写代码所需的成本进行比较。 A到D的默认值为0.05,0.1,0.2,0.5。任何超过0.5评级就为E。
举个例子：假设开发成本是30分钟，2,500 LOC的技术债务为24,000分钟的项目将有技术债务比率为24000 /（30 * 2,500）= 0.32。 因此项目的可维护性评级就是D。
4、Coverage覆盖率
4.1 Coverage
行覆盖和条件覆盖的混合。单元测试覆盖多少源代码。Coverage = (CT + CF + LC)/(2*B + EL)，其中 ：
CT = conditions that have been evaluated to ‘true’ at least once至少有一次被判断为true的条件数
CF = conditions that have been evaluated to ‘false’ at least once 至少一次被判断为false的条件数
LC = covered lines = lines_to_cover uncovered_lines 已覆盖的行数
B = total number of conditions 条件总数
EL = total number of executable lines (lines_to_cover) 所有可执行的代码总行数
4.2 Line coverage
单元测试覆盖行数密度
Line coverage = LC / EL
LC =
covered lines (lines_to_cover - uncovered_lines) 已覆盖的行数
EL =
total number of executable lines (lines_to_cover) 所有可执行的代码总行数
4.3 Condition coverage
Condition
Coverage=（CT+CF）/(2*B)
CT = 至少一次使用 ‘true’的条件数
CF = 至少一次使用 ‘false’ 的条件数
B = 条件总数
4.4 Unit test success density (%)
测试成功密度=（单元测试总数-（单元测试错误数+单元测试失败数））/单元测试数*100
5、Duplications重复
5.1 Duplication
SonarQube使用自己的复制/粘贴检测引擎，可以检测重复：
1、在源文件中
2、跨项目中的多个文件
3、项目的各个模块
4、跨多个项目
5.2 Duplicated Lines(%)
重复率=重复行数/总行数*100
Duplicated blocks:重复代码块行数
Duplicated files:重复文件数
Duplicated lines:重复行数
5.3处理Duplicated
a、分析这些重复，并通过使用继承或其他合适的模式来消除它们（只有在要对块进行单元测试时才这样做）
b、将复制的更改复制到复制的块上
c、使用问题和技术债务机制，通过编辑质量配置文件以包括来自公共Sonar存储库的复制块规则，监控成本并跟踪此错误的修复。
6、Size大小
7、Complexity复杂度
7.1 Complexity复杂度
以下关键词增加复杂性：if, for, while, case, catch, throw, return (不是方法的最后一个语句), &&, ||, ?
7.2 备注
else, default, finally不增加复杂度
代码复杂度过高将难以理解、难以维护。
8、Code Smells坏味道
Code Smell
某些东西会混淆维护者或在读代码时产生误导。有时，Bug和Code Smell之间的界线是模糊的。 当有疑问时，问自己：“打破这条规则的代码是否是程序员想要的？ 如果答案是“可能不是”，那么它是一个Bug。 否则它就是一个代码坏味道。
9、Issues问题
9.1 Open Issues
当前存在的全部问题
9.2 Reopened Issues
关闭后又重新打开的问题，可能由于之前误判关闭或者重新出现同样问题，需要再次将问题置为打开状态。
9.3 Confirmed Issues
确认的问题 - 通过确认问题，你基本上是承认：“是的，这是一个问题。” ，并将问题从“打开”状态移动到“已确认”状态。
9.4 False Positive Issues
误判问题-在上下文中查看问题，你意识到可能由于一些原因判定了这个问题，然而这个问题实际上不是一个问题，因此可以在此处标记为False Positive，然后继续下一步。注意：做此判断的人需要拥有项目的管理员权限。
9.5 Won't Fix
不修复的问题 – 通过查看上下文中的关联，你意识到虽然这是一个有效的问题，实际上并不需要修复。因此可以在此处标记为Won't Fix，然后继续下一步。注意做如此判断的人则需要拥有项目的管理员权限。
附录：参考文档一览
《Refactoring: Improving the Design of Existing Code》 [美]Martin Fowler
Sonar Project Page：https://docs.sonarqube.org/display/SONAR/Project+Page?src=search
sonarqube官方文档翻译之UserGuide ：http://blog.csdn.net/chenmin_2014/article/details/54138759
作者原创技术文章，转载请注明出处
其他推荐相关阅读：
单元测试系列之一：如何使用JUnit、JaCoCo和EclEmma提高单元测试覆盖率
单元测试系列之四：Sonar平台中项目主要指标以及代码坏味道详解