从界面出发,编写Server端SonarQube手册。
首页
说明:
菜单栏
- 项目:被扫描的项目
- 问题:被扫描的项目的问题
- 代码规则:代码检测规则
- 质量配置:质量配置是在分析时使用的规则集合。可以启用或者禁用某些规则。
- 质量阈:正常/错误。可以指定一些指标条件时为错误,比如bug数大于某个值时为错误。
项目概况
- 指标说明:一般将鼠标放在图标上就会显示这个指标的说明
- bugs:bug的数量
- 漏洞:漏洞的数量
- 异味:不规范代码的数量
- 覆盖率:单元测试的对代码的覆盖率
- 重复:重复代码的行数占总代码行数的比例
- 大小:代码行数
- 编程语言:项目检测的编程语言
- 等级说明:由ABCDE5个等级,从A的绿色到E的红色表示严重等级。
项目
总览
说明:
- 支持分支检测
- 显示主要指标情况
- 显示项目的检测配置信息
问题
说明:
- 类型:一条规则定义的类型,有4种:bug,漏洞,异味,安全热点时单独的
- 严重程度:有5种:阻断,严重,重要,次要,提示
- 状态:5种:打开,解决,重开,关闭,确认
- 负责人:分配给谁
- 修复预估时间:系统给的预计修复时间
- 评论:可以评论
安全报告
说明:
- 有2个选项:OWASP前10位,SANS前25位
- SANS前25位:CWE/SANS前25位最危险的软件错误
- 理解:就是这两个网站评了软件错误排名,此项目中有哪些是这些错误。
指标
指标有:
Reliability可靠性
可靠性比率的计算方法)
- 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,最低级别。
图中气泡大小根据bug数变化,bug数越大气泡越大。视觉更加直观。
Security安全性
安全度指标计算方法
- 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
图中气泡大小根据漏洞数变化,漏洞数越大气泡越大。视觉上直观显示。
Maintainability
技术债务:Technical Debt,当前不规范的代码,会对以后产品修改的成本造成影响。
开发成本:开发一行代码(LOC)的成本。 示例:如果开发1 LOC的成本估计为30分钟,则此属性的值为30。目前我们采用的是系统默认值30。注意此处成本是指从零开始重写代码所需的成本。
可维护性:可维护性等级范围从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。
Coverage覆盖率
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) 所有可执行的代码总行数
Line coverage
单元测试覆盖行数密度
Line coverage = LC / EL
- LC = covered lines (lines_to_cover - uncovered_lines) 已覆盖的行数
- EL = total number of executable lines (lines_to_cover) 所有可执行的代码总行数
Condition coverage
Condition Coverage=(CT+CF)/(2*B)
- CT = 至少一次使用 ‘true’的条件数
- CF = 至少一次使用 ‘false’ 的条件数
- B = 条件总数
Unit test success density (%)
测试成功密度=(单元测试总数-(单元测试错误数+单元测试失败数))/单元测试数*100
Duplications重复
Duplication
SonarQube使用自己的复制/粘贴检测引擎,可以检测重复:
- 在源文件中
- 跨项目中的多个文件
- 项目的各个模块
- 跨多个项目
Duplicated Lines(%)
重复率=重复行数/总行数*100
- Duplicated blocks:重复代码块行数
- Duplicated files:重复文件数
- Duplicated lines:重复行数
Size大小
Complexity复杂度
以下关键词增加复杂性:if, for, while, case, catch, throw, return (不是方法的最后一个语句), &&, ||, ?
else, default, finally不增加复杂度
代码复杂度过高将难以理解、难以维护。
Issues问题
- 新违
- 违规
- 开启问题
- 重开问题
- 确认问题
- 误判问题
- 不修复的问题
代码
项目的代码
活动
项目的操作动态
配置
项目的配置选项
设置
项目的设置选项:一般不需要改
质量配置
项目的质量配置选项:一般不需要改
质量阈
项目的质量阈选项:一般不需要改
权限
权限应用权限模板,授予和收回项目级别的权限。权限可以授予群组或单独用户。
公开项目。所有人都可以浏览并查看源码。
问题
问题列表
问题详细
代码规则
代码规则列表,可以查看激活状态
单条代码规则 内容
质量配置
质量配置是在分析时使用的规则集合。
每个语言都有默认配置。没有指定其他配置的项目会使用默认配置。
可以修改单个语言的默认配置,一个语言只有一个配置生效
一般操作是修改父类
质量阈
质量阈是在组织中实施质量策略的最佳方法。在那里可以回答一个问题:我可以今天将项目交付生产吗?
为了回答这个问题,您可以根据测量项目的测量阈值定义一组布尔条件。例如:
- 没有新的阻止程序问题
- 新代码的代码覆盖率大于80%
- 等等。
理想情况下,所有项目都将通过相同的质量阈进行验证,但这并不总是可行的。例如,您可能会发现:
技术实现因一个应用程序而异(对于Web或Java应用程序,您可能不需要在新代码上具有相同的代码覆盖率)。
您想确保对某些应用程序(例如内部框架)有更严格的要求。
等等。
代码质量检测后给一个是否可以进行生产的标志:通过/不通过
一般设定一般参数指标
比如:bugs数量大于某个值就不通过
配置
管理员才有这个选项
配置
通用设置
编辑SonarQube实例的全局设置。
加密
网络调用
权限
用户
新建用户
生成令牌
群组
全局权限
权限模板
项目
项目管理
后台任务
系统
可以查看一些信息
有4个模块
参考
应用市场
说明:
- 查看现在使用的版本
- 搜索安装/卸载插件