coverity代码检测工具介绍_微服务测试之静态代码扫描
背景
微服務架構模式具有服務間獨立，可獨立開發部署等特點，獨立開發誘發了技術上的分離，HTTP通信增加了問題診斷的復雜度，對系統的功能、性能和安全方面的質量保障帶來了很大的挑戰。
“微服務架構對測試的挑戰
微服務架構模式下多個獨立業務服務同時開展開發工作，每個系統都有各自的業務范圍和開發周期要求，這樣一來，下圖所示的傳統流程中產品經理提供需求，需求人員進行需求分析、開發人員進行開發，最后交給測試人員進行測試的方法，就無法滿足測試覆蓋和測試效率的要求。
相對于傳統的單體模式而言，微服務模式下對測試帶來的挑戰總結起來包括以下內容：
- 1. 微服務系統模塊層次化，需要保證模塊內部代碼的質量。這種場景下傳統的端到端的測試無法滿足測試要求；
- 2. 需要保證各個微服務系統內部模塊間的正確性。系統模塊間以及前端和后端通常會同時開展開發工作，模塊間或者前后端通過接口（通常是Restful http接口）進行連接，而模塊和后端往往沒有界面，為了保證各個系統單個依賴系統的正確性，因此需要借助Mock技術隔離依賴的前提下進行接口級的測試；
- 3. 需要保證微服務系統中的接口一致性，即契約的一致性。需要通過契約測試手段保證契約的正確性，進而保證同步開發過程中的前后開發的正確性和一致性；
- 4. 需要保障單個微服務系統的正確性。需要進行組件級的測試進行微服務系統的正確性；
- 5. 需要保障整個系統的正確性。各個微服務系統串接之后通過端到端的測試保證整體系統的正確性；
“微服務架構下如何開展測試
針對上面提到的微服務對測試的挑戰，一方面為了保證在服務各個層級上對微服務進行全面的測試，特別是對于分布式系統；另一方面又要確保測試執行的效率，這樣才能保證持續集成/持續交付（CI/CD）。因此，總體的測試策略采用如下解決方法：
- 1. 開展「質量」文化。讓開發人員建立起代碼「質量」意識，用于保障模塊內部的質量；
- 2. 采用自動化測試手段。在微服務架構中，開發分解為負責不同服務的多個小組，測試人員往往每天要花費大量的時間，了解不同團隊的開發進度。如果還需要手動進行回歸測試（Regression Test），最終將會不堪重負。所以自動化測試在微服務模式下是必須采取的手段。
- 3. 分層的自動化測試策略。自動化測試分層在Mike Cohn 提出的測試金字塔（Test Pyramid）原理中進行了詳細的闡述。它提倡在代碼級、接口級、應用級進行不同粒度的測試來保證系統的質量。從自動化測試投入比例來看，單元測試和靜態代碼掃描的投入比例最大，其次是接口自動化測試，最后是UI自動化測試。同時為了提高測試效率和測試覆蓋率，功能測試需要借助探索式測試手段開展測試。
- 4. 采用流水線技術進行可視化快速反饋。由于微服務系統非常多，這樣往往會增加了運維和溝通成本，為了提高溝通效率，需要借助流水線的技術，可視化查看每一個構建（Build）、測試（Test）、部署（Deploy）過程，快速做出質量反饋和處理決策。通過可視化流水線最終可以實現各個環節的監控，采用DevOps手段打通業務、開發、測試和運維的部門墻。
下面結合分層自動化測試的思想，首先對靜態代碼掃描進行介紹。
靜態代碼掃描
“靜態代碼掃描背景
靜態代碼分析是指在不運行代碼的方式下，通過詞法分析、語法分析、控制流、數據流分析等技術對程序代碼進行掃描的技術。它的目的是驗證代碼是否滿足規范性、安全性、可靠性、可維護性的要求。靜態代碼掃描處于分層自動化測試的最底層，它和單元測試同級別。為了保證公司代碼的規范性、安全性、可靠性的要求，通過定制公司級的靜態代碼掃描規范、掃描規則和掃描實施流程保證實施高效落地。
“靜態代碼掃描意義
為開發者
軟件開發人員最終負責代碼質量。代碼質量是非功能性需求的一部分，因此是開發人員的直接責任。代碼質量不應該存在技術債務，在開發的過程中每一步都提供反饋，從IDE到發布。這使得開發人員能夠盡早做出有關代碼質量的決策，使他們能夠做得更好，并提供質量更好的軟件產品。
為DevOps
DevOps需要確保軟件的構建方式正確。DevOps中涉及的責任很多，其中包括支持開發流程，自動化測試，確保質量，提高生產力.....并最終實現持續部署。良好的代碼質量是實現所有這些目標的必要條件，盡管不是充分條件。靜態代碼掃描可在任何構建/測試/部署步驟中添加的代碼質量檢驗門檻，能夠自動執行一組統一的質量標準，從而確保組織交付更好的軟件。
為管理者
代碼靜態掃描可降低風險并提高團隊生產力。管理人員需要能夠安全地運行軟件，并且需要花費合理的投資回報。我們的解決方案一目了然地顯示了他們面臨的技術債務以及他們緩解的成本。它還具有開箱即用的功能，可以系統地提高開發團隊的可維護性和長期生產力。這使管理人員能夠以最佳成本使用風險控制方法確保其組織能夠交付更好的軟件。
“靜態代碼掃描介紹
靜態代碼掃描處在特性分支開發完成之后，具體的描述如下：
- 1. 開發人員從Master分支拉取特性分支作為開發分支；
- 2. 開發完特性分支后、代碼構建、單元測試、靜態代碼掃描；
- 3. 通過后合并到Master分支，用于投產；
“靜態代碼掃描流程
隨行付靜態代碼掃描平臺的具體實現是通過集成SonarQube平臺工具、Jenkins集成工具、IDE SonarLint插件和CheckStyle本地化規則模板等開源工具、插件集而成。實現本地化代碼的實施檢測，版本構建后的二次檢測，以及郵件反饋等功能的流程閉環，保證投產前代碼符合隨行付代碼規范的要求。具體的流程如下圖所示：
- 1.本地化IDE中通過SonarLint插件實現和SonarQube平臺規則、規范的同步、實現本地代碼檢查；隨行付定制化了java規則、XML規則257條，javascript規則86條，用于檢測代碼的規范性、代碼缺陷、漏洞、壞味道、重復率等信息。并將定制化的規則放到了SonarQube平臺上，SonrLint插件的規則比較全面，包括所有的sonajava規則和javascript規則，為了保證本地使用定制的規則，且同sonarqube中的規則一致，需要遠程連接SonarQube服務器,并綁定項目。以Eclipse為例，展示SonarQube連接和項目綁定過程：
- 2.代碼提交到代碼庫GitLab中后，在Jenkins中測試環境構建時，自動觸發Sonar掃描，并將掃描結果發布到SonarQube平臺。下圖為SonarQube展示的一個項目的結果：
- 3.SonarQube平臺根據質量閥的要求，不滿足質量閥要求則郵件通知開發人員。
- 4.開發人員收到郵件后，進行代碼處理，直到滿足規范要求為止。
- 5.以周為單位統計SonarQube平臺中靜態代碼掃描出來的Bugs漏洞壞味道的數量，定時自動發送周報給相關干系人，報告中會包含問題處理情況的趨勢圖。
SonarQube與規則
SonarQube是一個用于代碼質量管理的開源平臺，支持25+種編程語言的質量掃描。SonqrQube由遠程機、Server端和數據庫構成。遠程客戶機可以通過各種不同的分析機制，從而將被分析的項目代碼上傳到SonarQube server 并進行代碼質量的管理和分析，SonarQube 還會通過Web API將分析的結果以可視化、可度量的方式展示給出來。邏輯結構如下圖所示：
“SonarQube的整合能力
SonarQube平臺中支持整合各種靜態代碼掃描檢測工具。SonarQube中各種代碼檢測工具分析對象及應用技術對比：
Java靜態分析工具分析對象應用技術CheckStyleJava源文件缺陷模式匹配FindBugs字節碼缺陷模式匹配；數據流分析PMDJava源代碼缺陷模式匹配
CheckStyle
可以很方便的幫我們檢查Java代碼中的格式錯誤，它能夠自動化代碼規范檢查過程，從而使得開發人員從這項重要，但是枯燥的任務中解脫出來。基本上都是根據開發規則定制規則。主要涵蓋以下內容：
- Javadoc 注釋：檢查類及方法的 Javadoc 注釋
- 命名約定：檢查命名是否符合命名規范
- 標題：檢查文件是否以某些行開頭
- Import 語句：檢查 Import 語句是否符合定義規范
- 代碼塊大小，即檢查類、方法等代碼塊的行數
- 空白：檢查空白符，如 tab，回車符等
- 修飾符：修飾符號的檢查，如修飾符的定義順序
- 塊：檢查是否有空塊或無效塊
- 代碼問題：檢查重復代碼，條件判斷，魔數等問題
- 類設計：檢查類的定義是否符合規范，如構造函數的定義等問題
FindBugs
Findbugs是一個靜態分析工具，它檢查類或者JAR文件，將字節碼與一組缺陷模式進行對比以發現可能的問題。主要涵蓋以下內容：
- Bad practice 壞的實踐：常見代碼錯誤，用于靜態代碼檢查時進行缺陷模式匹配
- Correctness 可能導致錯誤的代碼，如空指針引用等
- 國際化相關問題：如錯誤的字符串轉換
- 可能受到的惡意攻擊，如訪問權限修飾符的定義等
- 多線程的正確性：如多線程編程時常見的同步，線程調度問題
- 運行時性能問題：如由變量定義，方法調用導致的代碼低效問題
PMD
一種開源分析Java代碼錯誤的工具，其原理為使用JavaCC生成解析器來解析源代碼并生成AST(抽象語法樹)。與其他分析工具不同的是，PMD通過靜態分析獲知代碼錯誤。也就是說，在不運行Java程序的情況下報告錯誤。PMD附帶了許多可以直接使用的規則，利用這些規則可以找出Java源程序的許多問題，例如：
- 潛在的 Bugs：檢查潛在代碼錯誤，如空的 try/catch/finally/switch 語句
- 未使用代碼（Dead code）：檢查未使用的變量，參數，方法等
- 可選的代碼：String/StringBuffer的濫用
- 復雜的表達式：檢查不必要的 if 語句，可被 while 替代的 for 循環
- 重復的代碼：檢查重復的代碼
- 循環體創建新對象：檢查在循環體內實例化新對象
- 資源關閉：檢查 Connect，Result，Statement 等資源使用之后是否被關閉掉
此外，用戶還可以自己定義規則，檢查Java代碼是否符合某些特定的編碼規范。例如，你可以編寫一個規則，要求PMD找出所有創建Thread和Socket對象的操作。
三種工具對比
由表中可以看出幾種工具對于代碼檢查各有側重。其中，Checkstyle 更偏重于代碼編寫格式，及是否符合編碼規范的檢驗， 對代碼 bug 的發現功能較弱；而 FindBugs，PMD著重于發現代碼缺陷。在對代碼缺陷檢查中，這三種工具在針對的代碼缺陷類別也各有不同，且類別之間有重疊。
“規則定制
考慮到Sonar Java規則已經包含了PMD和CheckStyle規則，因此我們選擇了Sonar的默認規則，并對其進行了定制化。下圖中SonarQube中展示了部分定制化規則內容。
定制化后的規則覆蓋的代碼缺陷類型如下表所示(部分規則)：
代碼缺陷分類示例引用操作空指針引用對象操作對象比較（使用==而不是equals）表達式復雜化對于的if語句數組使用數組下標越界未使用變量或代碼段未使用變量資源回收I/O未關閉方法調用未使用方法返回值代碼設計空的try/catch/finally塊
總結
本篇介紹了微服務架構架構對測試的挑戰，在微服務架構下如何開展測試工作以及在微服務架構下的如何實現靜態代碼掃描。后續文章將介紹，敬請關注：
- 1. 微服務測試之單元測試
- 2. 微服務測試之契約測試
- 3. 微服務測試之接口測試
- 4. 微服務測試之UI自動化測試
- 5. 微服務測試之探索式測試
作者簡介
王田，隨行付架構部測試架構師。負責測試方法論布道、自動化測試工具研究與推廣。
總結
以上是生活随笔為你收集整理的coverity代码检测工具介绍_微服务测试之静态代码扫描的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： linux服务器上svn的log_如何在
- 下一篇： git push 的符号笔有什么用_如何