今天繼續學習使用SonarQube分析項目代碼，爲了便於理解，將官方手冊用到的翻譯出來。
UserGuide
Quality Gate
Use the Best Quality Gate Configuration
推薦默認配置，對於每一個版本，我們都會根據SonarQube的能力調整默認質量門（Quality Gate）。SonarQube6.2版本新增了三個度量，可靠比，安全比，可維護性比。極力推薦這些新的度量作爲默認質量檢查的一部分。
注意質量門的條件，必須使用不同的值。舉例說明，對於檢查絕對數量值沒有意義，如：代碼行數大於1000.
Quality Gate Status
在Project頁面上方會顯示質量門現有的狀態。
若質量門顯示狀態爲“Fails”，你可以注意到是哪些地方出了問題，也可以爲你的其他感興趣的項目提交新的質量門狀態。
Security
質量門可以被任何用戶訪問。若想要改變質量門配置，必須獲得管理員允許。項目管理員可以選擇哪個項目和哪個質量門關聯。
Define Quality Gate
每個質量門條件是有以下部分組合：
度量（measure）
時間（period）：值（對於時間）或漏洞（不同值）
比較操作符
警告值（可選）
錯誤值（可選）
例如，條件組合可能爲：
measure：Blocker issue
period:Value
comparison operator:>
error value:0
可以簡單表述爲：沒有致命問題。
Projects
“項目”這一欄可以對多個項目進行查看度量。
登錄的用戶可以查看默認的喜歡的項目，如果你沒有選擇最喜歡的項目，你可以看到所有你有權限訪問的項目。有以下過濾標準：
失敗質量門
低可靠性，安全性和可維護性
低覆蓋率
過多的重複代碼
一旦你選擇了你的項目，你就可以查看項目更多的細節->Projects
Local and Branch Analysis
提交代碼之前檢查代碼問題–SonarLint。在你的IDE中提出問題。
合併pull request之前檢查代碼問題–PR分析允許你配置你的CI引擎來執行“預演”分析。新的問題都會標註出來。如果沒有新問題，則會提示“all clear”消息。在 GitHub plugin（插件）支持 GitHub項目的PR分析，或者其他的插件。
在SonarQube中分析長期的分支–這種情況下，在SonarQube中持續分析典型項目，可以稱爲主分支，包括SonarQube中正在分析的第二分支。典型的項目是版本分支。在這種場景下，可以通過添加sonar.branch=[branch key]分支分析版本分支的屬性，在SonarQube中創建一個第二的，獨立的項目。
Code Viewer
SonarQube的核心是代碼審查，它展示了代碼源文件和高層次的數據：
行數
問題數
單元覆蓋率
重複度
SCM信息（近期提交某行代碼的人和時間）
給定測試文件的測試結果，執行時間和狀態
code viewer有兩個方面：現有的文件，標記的文件
現有文件
佈局包括兩個部分：
頭部位於文件的上方。展示了有用的信息，提供了修飾和過濾動作。
源代碼居中，基於頭部選擇顯示額外的信息。
具體見官網文檔說明。
Coverage
紅色：表示沒有被覆蓋
橙色：表示部分被覆蓋
綠色：表示完全覆蓋
對於Java程序，使用JaCoCo，可以得到以下信息：
- 顯示覆蓋特定一行不同測試的數量；
- 列出這些測試；
- 能夠尋找定義這些測試的測試文件。
Duplications
通過點擊相應位置，展開查看重複代碼行數，定位重複代碼位置。
Tests
在測試文件上，構件視圖可以看到不同的數據。
在“Show details”選項提供了“coverage per test（每個測試單元的覆蓋率）”信息。
這一部分可以回答兩個問題：
- 哪一個文件被給定的單元測試覆蓋？
- 有多少代碼行數被給定的單元測試覆蓋？
Issues
每個issue有五個等級：
- BLOCKER:會影響應用程序的缺陷：內存泄漏，未關閉的JDBC連接…必須立刻修復的代碼；
- CRITICAL ：可能會影響應用程序的缺陷或者是安全性缺陷：空的catch塊，sql注入，…必須立刻查看代碼；
- MAJOR：可能會影響開發者效率的質量缺陷：未覆蓋的代碼，重複塊，未使用的參數….
- MINOR：可能會影響開發者效率的質量缺陷：每行不能太長，“switch”語句應該至少有三個條件，….
- INFO：既不是缺陷也不是質量問題，只是一個發現。
SonarQube 問題工作流可以幫助你管理這些問題。你有七種方法處理這些問題（不是在代碼中修復）：註釋，分派，確認，改變嚴重性，已解決，不會被修復，假陽性。這些可以分爲以下三類。
Technical Review
Confirm:通過確認一個問題，將其從“open”狀態轉換爲“Confirm”。
False Positive:在全文中查看問題，發現不是一個真正的問題，標記爲“False Positive”；
Won’t Fix:在全文中查看問題，發現不是一個有效的問題，即可以被接受的技術債；
Change Severity:是一個問題，但不是一個壞問題，或者是一個更嚴重的問題，根據自己的經驗來調整嚴重等級；
Resolve：如果你認爲你已經修復了一個開放的問題，你可以解決它。如果修改正確，下次執行時將會關閉狀態，若修改不正確，下次執行分析後，狀態仍然保持開放。
如果標記出很多問題是屬於False Positive和Won’t Fix，說明編碼規則不適合現有的背景，你可以在 quality profile 中修改或使用問題包含來聚焦規則使用於特定的部分。類似的，若
嚴重性變更過多，也得考慮更新文件中規則了。
Dispositioning
通過了Technical Review之後，該決定由誰來解決問題了。默認是由最後一個提交者負責，你也可以重新分配給自己或者其他人。被分配者會接收到郵件通知。
General
在問題生命期中任何時候，你都可以註釋問題。在運行日誌中顯示出細節註釋。你也可以編輯或刪除你做的註釋。
Bulk Change
所有的這些變更都可以一次性做成多個問題，通過使用問題搜索結果面板的Bulk Change。
其他：問題來源於規則或者收集在文件中的規則。只有指定的用戶才能編輯文件，但所有用戶都可以查看它們。
Rules
略
Metric Definition
Complexity
Documentation
Duplications
Issues
Maintainability
Quality Gates
Reliability
Security
Tests
Complexity
Complexity:基於代碼路徑數量計算複雜度。功能控制流分裂，複雜度依次增加。每個功能最小複雜度爲1.由於關鍵詞和功能原因，不同語言複雜度計算有些不同。
Complexity/class:類的平均複雜度
Complexity/file：文件的平均複雜度
Complexity/method：函數的平均複雜度
Documentation
Commment lines:包含註釋或註釋代碼的行數。不包括僅有註釋符號的行數。可參見官網本節有關注釋代碼的例子。http://docs.sonarqube.org/display/SONAR/Metric+Definitions
Comments(%):註釋行數密度=註釋行數/(代碼行數+註釋行數)100（50%表示代碼行數與註釋行數相同，100%表示只有註釋行）
Public documented API(%)：公有記錄API密度=（公有的API-公有未記錄的API）/公有API100
Public undocumented API：不帶註釋頭的公有API
Commented-out LOC:代碼註釋行數
Duplications
Duplicated blocks:重複代碼塊行數
Duplicated files:重複文件數
Duplicated lines:重複行數
Duplicated lines(%):重複密度=重複行數/總行數*100
Issues
New issues
New xxxxx issues
Issues
xxxxx issues
False positive issues
Open issues
Confirmed issues
Reopened issues
Severity
Blocker:致命的
Critical:關鍵的
Major:主要的
Minor:微小的
Info：未知的
Maintainability
Code smells
New code smells
Maintainability Rating:A=0-0.05, B=0.06-0.1, C=0.11-0.20, D=0.21-0.5, E=0.51-1
Technical Debt:技術債，修復所有維護問題的成本。
Technical Debt on new code：新代碼上的技術債
Technical Debt Ratio：技術債比例=修復成本/開發成本
Technical Debt Ratio on new code：開發者變更代碼的花費與相關問題的花費比
Quality Gate
Quality Gate Status:有ERROR,WARN,OK三種狀態
Quality Gate Details:質量門各種條件的細節
Reliability
Bugs
New Bugs
Reliability Rating:
A = 0 Bug
B = at least 1 Minor Bug
C = at least 1 Major Bug
D = at least 1 Critical Bug
E = at least 1 Blocker Bug
Reliability remediation effort:修復所有缺陷問題成本
Reliability remediation effort on new code：在新增代碼上修復所有缺陷問題成本
Security
Vulnerabilities
New Vulnerabilities
Security Rating:
A = 0 Vulnerability
B = at least 1 Minor Vulnerability
C = at least 1 Major Vulnerability
D = at least 1 Critical Vulnerability
E = at least 1 Blocker Vulnerability
Security remediation effort
Security remediation effort on new code
詳細度量：Classes, Directories,files,lines(顯示的行數),lines of code（包括至少一個字符，不包括空格）,lines of code per language,methods,projects,public API（公有類數量+公有方法數量+公有屬性數量）,Statements.
Tests
Condition coverage on new code：新增或更新代碼的條件覆蓋度
coverage on new code：新增或更新代碼的覆蓋度
Line coverage on new code：新增或更新代碼的行覆蓋度
Lines to cover on new code：新增或更新代碼覆蓋的行數
Uncovered conditions on new code：新增或更新代碼未覆蓋的條件數
Uncovered lines on new code：新增或更新代碼未覆蓋的行數
Coverage：行覆蓋和條件覆蓋的混合。單元測試覆蓋多少源代碼。Coverage = (CT + CF + LC)/(2B + EL)，其中
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)
Condition coverage hits：條件覆蓋的列表
Line coverage hits：行覆蓋的列表
Conditions by line：行條件數
Uncovered conditions：單元測試未覆蓋的條件數
Covered conditions by line：行覆蓋的條件數
Uncovered lines：單元測試沒有覆蓋的代碼行數
Lines to cover：單元測試可能覆蓋的代碼行數
Skipped unit tests：跳過的單元測試數量
Unit test failures：異常的單元測試數量
Unit test errors：失敗的單元測試數量
Unit tests：單元測試數量
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）/(2B)
CT = 至少一次使用 ‘true’的條件數
CF = 至少一次使用 ‘false’ 的條件數
B = 條件總數
Unit test success density (%)：測試成功密度=（單元測試總數-（單元測試錯誤數+單元測試失敗數））/單元測試數*100
Unit tests duration:執行所有單元測試所需的時間