Dashboard看的是統計跟平均值,真正有用的資訊,應該是drilldown進去看到細節會比較有用
Dashboard中常會看到向上或向下的三角型,通常會有灰、紅、綠三色,那個叫Tendency
,是指跟前一次build出來的results比較的結果.
左邊的圖是程式五項能力指標
-
Usa. Usability 可用性
-
Eff. Efficiency 效率
-
Mai. Maintainabilitiy 維護性
-
Por. Portability 可攜性
-
Rel. Reliability 可靠性
愈高愈好,最好能五個指標都是 100%
右邊的Voilations是程式經過checkstyle, PDM, findbugs,….這些rule檢查後的不通過數量,嚴重性依上而下為
-
Blocker 阻塞
-
Critical 嚴重
-
Major 主要
-
Minor 次要
-
Info 資訊
檢查不通過的數量當然是愈少愈好,理想值是都為0
建議盡可能的把所有的check rules打開,然後再把不適用的rule做調整或停用
程式的單元測試覆蓋率
另外常見的還有
-
class converage : 類別覆蓋率
-
method converage : 方法覆蓋率
覆蓋率愈高愈好,100%為理想值,但通常,粒度(Grain)的單位愈小,愈難達到100%,粒度的大小由上至下為,類別 > 方法 > 分支 > 行
一般來說,建議值為:
* class converage 100%
* method converage 100%
-
branch
coverage
採用
TDD
的號稱可以達到95%, 但個人建議值在 70% 以上
-
line
coverage
採用
TDD
的號稱可以達到95%, , 但個人建議值在 80% 以上
覆蓋率比較有爭議性, 覆蓋率 != 品質,但基本上把不需要測試的settor,gettor去掉後,保持line coverage
在75%以上,應該不難。
程式的複雜度,採用McCabe
的計算方式
左邊是平均值,右邊的chart圖是統計值,統計有兩個view,可以從class的角度或從method的角度來看(建議)
x軸是複雜度,y軸是數量,
在本例中:
-
複雜度為1的method約有600個
-
複雜度為2的method約有180個
-
複雜度為4的method約有100個
-
…
以method為計算單位的建議值
Cyclomatic Complexity
Risk Evaluation
中文解釋
1 to 10 |
a simple program, without very much risk |
method夠簡單,風險低 |
11 to 20 |
a more complex program, moderate risk |
method有點複雜,有點風險 |
21 to 50 |
a complex, high risk program |
method很複雜,高風險 |
> 50 |
an un-testable program (very high risk) |
只有上帝跟原開發者才懂的method(也許過個月後,只有剩上帝懂) |
左邊的chart圖是LCOM4(Lack of cohesion of methods),右邊是RFC(Response for class)
LCOM4是用來判別類別是否具有太多的責任的指標,一般來說,類別設計應該符合單一責任原則
,如果一個類別之中的methods,並沒有共同的參數或是公用的field,那表示此類別可能可以進行切割。
LCOM4的說明文章
LCOM4的chart圖x軸是LCOM4的值,y軸是class的數量
上圖中,LCOM4=3,每一個區域表示可以被獨立切割的部份
RFC的chart圖x軸是RFC的值,y軸是class的數量,RFC的值愈小愈好,
左邊是程式註解的數量,右邊是程式重覆(copy & paste code)的數量
左邊的Package tangle index是指package糾纏指標,右邊的Dependencies to cut是指有多少個packages需要做依賴性切割
Package tangle index的值愈小愈好
Dependencies to cut的值愈小愈好,理想值為0
只要圖中消除紅底白色的部份,就可以有效降低Package tangle index
分享到:
相关推荐
Sonar 报表说明** Sonar 报告主要分为6部分,涵盖了代码质量的多个维度: 4.1 报表结构 - 代码概况:展示代码总览、健康度等信息。 - 问题列表:列出所有检测到的问题,按严重性分类。 - 新旧问题对比:显示...
- **国际化与报告文档化**:Sonar支持多语言界面,能够满足国际化需求,并且提供丰富的报表和文档支持。 #### 安装Sonar Sonar是Codehaus上的一个开源项目,使用LGPL V3许可证发布。用户可以通过以下步骤完成Sonar...
【Sonar 报表说明】 4.1 报表结构 SonarQube 报表主要分为六大部分:概述、质量门禁、规则、复杂度、代码覆盖率和历史。这些部分提供了关于代码质量、潜在问题、代码结构和历史变化的详细信息。 4.2 错误提示 在 ...
在实际项目应用中,Sonar可以提供详细的数据报表,例如在文中提到的Java项目案例,Sonar揭示了不同项目类型的代码质量差异,如零售类项目代码生产率低、缺陷多但结构质量高。这有助于团队识别问题,优化代码库,提高...
在“workspace-sonar.rar”这个压缩包中,包含了“sonarqube-7.1”版本的软件以及一个名为“解压即可用.txt”的说明文件,这表明我们可以直接解压并启动SonarQube,无需进行复杂的配置。 1. **SonarQube核心功能** ...
它将报表集成在SonarQube仪表板中。 用户必须使用checkstyle格式为代码生成GoMetaLinter报告。 因此,该报告使用 集成到SonarQube中。 版本1.0仅提供golint支持。 版本1.1提供了测试覆盖率支持。 即将发布的版本将...
Sonar 平台不仅能够进行代码检查,还可以提供可视化的报表,便于团队协作和代码审查。 1、简单介绍原理: Sonar 的工作原理主要是通过 SonarScanner(原 SonarQube Runner)来执行静态代码分析任务。开发者首先配置...
JumbleHudsonPlugin.zip,“此插件将读取混乱的XML报表并生成一个随时间变化的趋势图。它还将生成一个包含每个包和类的分数的报表。”hudson插件,它读取混乱的报告并生成每个构建的报告和趋势图
它提供了丰富的报表和仪表板,帮助团队持续改进代码质量。 在搭建好这些环境后,我们需要在 Hudson 中安装 Sonar Plugin,这样 Hudson 就能与 Sonar 进行交互,执行代码分析任务。接着,配置 Hudson 的系统设置,...
7. **可视化仪表板**:SonarQube的用户界面直观易用,提供丰富的图表和报表,清晰地展示项目的健康状况和改进趋势,帮助管理者做出决策。 8. **技术债务管理**:SonarQube能够计算和追踪技术债务,这是一项衡量因...
6. **插件支持**:7.9.0版本可能引入了新的插件或升级了现有插件,以扩展SonarQube的功能,如支持更多的VCS系统、报表格式或定制化的分析规则。 7. **数据可视化**:新的图表和指标可能被添加,以便更清晰地呈现...
SonarQube中的使用单位和集成测试覆盖率报告示例为了将jacoco报告发布到sonarqube,请使用您的凭据在本地〜/ .m2 / settings.xml文件中设置新的配置文件: <profile> <id>sonar</id> <activation> <activeByDefault>...
- 提供丰富的报表和度量 **2. Sonar的主要功能** - **代码审查**: 自动进行代码审查,提高代码质量。 - **持续集成**: 与 Jenkins 等持续集成工具集成,实时反馈代码质量。 - **统计度量**: 提供代码复杂度、重复...
9. **conf**: 配置文件目录,包含SonarQube的主要配置文件如`sonar.properties`,用户可以在这里修改SonarQube的行为,比如数据库连接参数、服务器端口、插件配置等。 SonarQube 7.5版本提供了强大的静态代码分析...
通过在jacoco中使用报表附加,我们可以解决此问题并覆盖整个项目中的所有类,而不仅仅是测试所在模块中的类。根pom.xml 特性: < properties> < jacoco>0.7.9</ jacoco> < sonar .jacoco.re
- 使用了如Jenkins的分布式调度平台,Sonar进行静态代码检查,以及AutoV自动化测试框架。 3. **自动化测试工具**: - AutoV:基于TestNg/SpringBoot的组件化自动化测试框架,广泛应用于唯品会内部。 - Vmock-...
SonarQube和SonarLint等工具就是静态代码分析的代表,而SonarWeb可能是这类工具的一个Web实现。 代码质量管理则关注于确保代码的可读性、可维护性和可靠性。这包括遵循编码标准,保持一致的命名约定,减少冗余代码...