靜態代碼掃描爲整個發展組織增長價值。不管您在開發組織中發揮的做用如何,靜態代碼掃描解決方案都具備附加價值,擁有軟件開發中所須要的尖端功能,最大限度地提升質量並管理軟件產品中的風險。javascript
微服務架構模式具備服務間獨立,可獨立開發部署等特色,獨立開發誘發了技術上的分離,HTTP通訊增長了問題診斷的複雜度,對系統的功能、性能和安全方面的質量保障帶來了很大的挑戰。前端
微服務架構模式下多個獨立業務系統(服務)同時開展開發工做,每一個系統都有各自的業務範圍和開發週期要求,這樣一來,下圖所示的傳統流程中產品經理提供需求,需求人員進行需求分析、開發人員進行開發,最後交給測試人員進行測試的方法,就沒法知足測試覆蓋和測試效率的要求。java
相對於傳統的單體模式而言,微服務模式下對測試帶來的挑戰總結起來包括如下內容:數據庫
針對上面提到的微服務對測試的挑戰,一方面爲了保證在服務各個層級上對微服務進行全面的測試,特別是對於分佈式系統;另外一方面又要確保測試執行的效率,這樣才能保證持續集成/持續交付(CI/CD)。所以,整體的測試策略採用以下解決方法:編程
下面結合分層自動化測試的思想,首先對靜態代碼掃描進行介紹。後端
靜態代碼分析是指在不運行代碼的方式下,經過詞法分析、語法分析、控制流、數據流分析等技術對程序代碼進行掃描的技術。它的目的是驗證代碼是否知足規範性、安全性、可靠性、可維護性的要求。靜態代碼掃描處於分層自動化測試的最底層,它和單元測試同級別。爲了保證公司代碼的規範性、安全性、可靠性的要求,經過定製公司級的靜態代碼掃描規範、掃描規則和掃描實施流程保證明施高效落地。數組
軟件開發人員最終負責代碼質量。代碼質量是非功能性需求的一部分,所以是開發人員的直接責任。代碼質量不該該存在技術債務,在開發的過程當中每一步都提供反饋,從IDE到發佈。這使得開發人員可以儘早作出有關代碼質量的決策,使他們可以作得更好,並提供質量更好的軟件產品。安全
DevOps須要確保軟件的構建方式正確。DevOps中涉及的責任不少,其中包括支持開發流程,自動化測試,確保質量,提升生產力.....並最終實現持續部署。良好的代碼質量是實現全部這些目標的必要條件,儘管不是充分條件。靜態代碼掃描可在任何構建/測試/部署步驟中添加的代碼質量檢驗門檻,可以自動執行一組統一的質量標準,從而確保組織交付更好的軟件。bash
代碼靜態掃描可下降風險並提升團隊生產力。管理人員須要可以安全地運行軟件,而且須要花費合理的投資回報。咱們的解決方案一目瞭然地顯示了他們面臨的技術債務以及他們緩解的成本。它還具備開箱即用的功能,能夠系統地提升開發團隊的可維護性和長期生產力。這使管理人員可以以最佳成本使用風險控制方法確保其組織可以交付更好的軟件。服務器
靜態代碼掃描處在特性分支開發完成以後,具體的描述以下:
隨行付靜態代碼掃描平臺的具體實現是經過集成SonarQube平臺工具、Jenkins集成工具、IDE SonarLint插件和CheckStyle本地化規則模板等開源工具、插件集而成。實現本地化代碼的實施檢測,版本構建後的二次檢測,以及郵件反饋等功能的流程閉環,保證投產前代碼符合隨行付代碼規範的要求。具體的流程以下圖所示:
2.代碼提交到代碼庫GitLab中後,在Jenkins中測試環境構建時,自動觸發Sonar掃描,並將掃描結果發佈到SonarQube平臺。下圖爲SonarQube展現的一個項目的結果:
3.SonarQube平臺根據質量閥的要求,不知足質量閥要求則郵件通知開發人員。
質量閥要求:
1.新覆蓋率大於等於80%;
2.新增Bugs爲0;
3.新增漏洞爲0;
4.新增壞味道爲0;
複製代碼
SonarQube是一個用於代碼質量管理的開源平臺,支持25+種編程語言的質量掃描。SonqrQube由遠程機、Server端和數據庫構成。遠程客戶機能夠經過各類不一樣的分析機制,從而將被分析的項目代碼上傳到SonarQube server 並進行代碼質量的管理和分析,SonarQube 還會經過Web API將分析的結果以可視化、可度量的方式展現給出來。邏輯結構以下圖所示: {% asset_img img11.png img11.png %}
SonarQube平臺中支持整合各類靜態代碼掃描檢測工具。SonarQube中各類代碼檢測工具分析對象及應用技術對比:
Java靜態分析工具 | 分析對象 | 應用技術 |
---|---|---|
CheckStyle | Java源文件 | 缺陷模式匹配 |
FindBugs | 字節碼 | 缺陷模式匹配;數據流分析 |
PMD | Java源代碼 | 缺陷模式匹配 |
能夠很方便的幫咱們檢查Java代碼中的格式錯誤,它可以自動化代碼規範檢查過程,從而使得開發人員從這項重要,可是枯燥的任務中解脫出來。基本上都是根據開發規則定製規則。主要涵蓋如下內容:
Findbugs是一個靜態分析工具,它檢查類或者JAR文件,將字節碼與一組缺陷模式進行對比以發現可能的問題。主要涵蓋如下內容:
一種開源分析Java代碼錯誤的工具,其原理爲使用JavaCC生成解析器來解析源代碼並生成AST(抽象語法樹)。與其餘分析工具不一樣的是,PMD經過靜態分析獲知代碼錯誤。也就是說,在不運行Java程序的狀況下報告錯誤。PMD附帶了許多能夠直接使用的規則,利用這些規則能夠找出Java源程序的許多問題,例如:
此外,用戶還能夠本身定義規則,檢查Java代碼是否符合某些特定的編碼規範。例如,你能夠編寫一個規則,要求PMD找出全部建立Thread和Socket對象的操做。
代碼缺陷分類 | 示例 | Checkstyle | FindBugs | PMD |
---|---|---|---|---|
引用操做 | 空指針引用 | √ | √ | √ |
對象操做 | 對象比較(使用 == 而不是 equals) | √ | √ | |
表達式複雜化 | 多餘的 if 語句 | √ | ||
未使用變量或代碼段 | 未使用變量 | √ | √ | |
資源回收 | I/O 未關閉 | √ | ||
方法調用 | 未使用方法返回值 | √ | ||
代碼設計 | 空的 try/catch/finally 塊 | √ |
由表中能夠看出幾種工具對於代碼檢查各有側重。其中,Checkstyle 更偏重於代碼編寫格式,及是否符合編碼規範的檢驗, 對代碼 bug 的發現功能較弱;而 FindBugs,PMD着重於發現代碼缺陷。在對代碼缺陷檢查中,這三種工具在針對的代碼缺陷類別也各有不一樣,且類別之間有重疊。
考慮到Sonar Java規則已經包含了PMD和CheckStyle規則,所以咱們選擇了Sonar的默認規則,並對其進行了定製化。下圖中SonarQube中展現了部分定製化規則內容。
定製化後的規則覆蓋的代碼缺陷類型以下表所示:
代碼缺陷分類 | 示例 |
---|---|
引用操做 | 空指針引用 |
對象操做 | 對象比較(使用==而不是equals) |
表達式複雜化 | 對於的if語句 |
數組使用 | 數組下標越界 |
未使用變量或代碼段 | 未使用變量 |
資源回收 | I/O未關閉 |
方法調用 | 未使用方法返回值 |
代碼設計 | 空的try/catch/finally塊 |
本篇介紹了微服務架構架構對測試的挑戰,在微服務架構下如何開展測試工做以及在微服務架構下的如何實現靜態代碼掃描。後續文章將介紹,敬請關注:
本分類文章,與「隨行付研究院」微信號文章同步,第一時間接收公衆號推送,請關注「隨行付研究院」公衆號。
複製代碼