單元測試系列之四：Sonar平臺中項目主要指標以及代碼壞味道詳解

更多原創測試技術文章同步更新到微信公衆號 ：三國測，敬請掃碼關注我的的微信號，感謝！

 

原文連接：http://www.cnblogs.com/zishi/p/6766994.html

衆所周知Sonar是一個很強大的靜態掃描工具，代碼提交以後能夠自動觸發代碼掃描，並給出report，所以給開發項目帶來了不少便利。

日前我把本地版本升級到6.2了，項目的度量項也增長了許多。看過去一堆的ABCD，A應該是最好，D最差，可是中間的差異仍是須要弄清楚。

爲了更好的理解，我詳細翻看了官方文檔，同時也參考了網上一些參考，尤爲是壞味道部分，

參考了大神Martin Fowler的《Refactoring: Improving the Design of Existing Code》關於代碼重構的一些看法，

最後，我將全部這些資料在這裏作一個總結，在此也分享給你們：

一、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數越大氣泡越大。視覺更加直觀。

二、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 計量方法：包括至少一個字符，不包括空格。

圖中氣泡大小根據漏洞數變化，漏洞數越大氣泡越大。視覺上直觀顯示。

 

三、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。

 

 

四、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

五、Duplications重複

5.1 Duplication

SonarQube使用本身的複製/粘貼檢測引擎，能夠檢測重複：

一、在源文件中
二、跨項目中的多個文件
三、項目的各個模塊
四、跨多個項目

5.2 Duplicated Lines(%)

重複率=重複行數/總行數*100

 

Duplicated blocks:重複代碼塊行數

Duplicated files:重複文件數

Duplicated lines:重複行數

5.3處理Duplicated

a、分析這些重複，並經過使用繼承或其餘合適的模式來消除它們（只有在要對塊進行單元測試時才這樣作）

b、將複製的更改複製到複製的塊上
c、使用問題和技術債務機制，經過編輯質量配置文件以包括來自公共Sonar存儲庫的複製塊規則，監控成本並跟蹤此錯誤的修復。

 

六、Size大小

七、Complexity複雜度

7.1 Complexity複雜度

如下關鍵詞增長複雜性：if, for, while, case, catch, throw, return (不是方法的最後一個語句), &&, ||, ?

7.2 備註

else, default,  finally不增長複雜度

代碼複雜度太高將難以理解、難以維護。

 

八、Code Smells壞味道

Code Smell

某些東西會混淆維護者或在讀代碼時產生誤導。有時，Bug和Code Smell之間的界線是模糊的。 當有疑問時，問本身：「打破這條規則的代碼是不是程序員想要的？ 若是答案是「可能不是」，那麼它是一個Bug。 不然它就是一個代碼壞味道。

 

九、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提升單元測試覆蓋率

 

單元測試系列之二：Mock工具Jmockit實戰

 

單元測試系列之三：JUnit單元測試規範

 

單元測試系列之四：Sonar平臺中項目主要指標以及代碼壞味道詳解

 

單元測試系列之五：Mock工具之Mockito實戰

 

單元測試系列之六：JUnit5 技術前瞻

 

單元測試系列之七：Sonar 數據庫表關係整理一（rule相關）

 

單元測試系列之八：Sonar 數據庫表關係整理一（續）

 

單元測試系列之九：Sonar 經常使用代碼規則整理（一）

 

單元測試系列之十：Sonar 經常使用代碼規則整理(二)

 

單元測試系列之十一：Jmockit之mock特性詳解