靜態(tài)代碼掃描為整個(gè)發(fā)展組織增加價(jià)值。無(wú)論您在開(kāi)發(fā)組織中發(fā)揮的作用如何，靜態(tài)代碼掃描解決方案都具有附加價(jià)值，擁有軟件開(kāi)發(fā)中所需要的尖端功能，最大限度地提高質(zhì)量并管理軟件產(chǎn)品中的風(fēng)險(xiǎn)。

創(chuàng)新互聯(lián)專注于三沙網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠(chéng)為您提供三沙營(yíng)銷型網(wǎng)站建設(shè)，三沙網(wǎng)站制作、三沙網(wǎng)頁(yè)設(shè)計(jì)、三沙網(wǎng)站官網(wǎng)定制、微信小程序定制開(kāi)發(fā)服務(wù)，打造三沙網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供三沙網(wǎng)站排名全網(wǎng)營(yíng)銷落地服務(wù)。

背景

微服務(wù)架構(gòu)模式具有服務(wù)間獨(dú)立，可獨(dú)立開(kāi)發(fā)部署等特點(diǎn)，獨(dú)立開(kāi)發(fā)誘發(fā)了技術(shù)上的分離，HTTP通信增加了問(wèn)題診斷的復(fù)雜度，對(duì)系統(tǒng)的功能、性能和安全方面的質(zhì)量保障帶來(lái)了很大的挑戰(zhàn)。

“

微服務(wù)架構(gòu)對(duì)測(cè)試的挑戰(zhàn)

微服務(wù)架構(gòu)模式下多個(gè)獨(dú)立業(yè)務(wù)服務(wù)同時(shí)開(kāi)展開(kāi)發(fā)工作，每個(gè)系統(tǒng)都有各自的業(yè)務(wù)范圍和開(kāi)發(fā)周期要求，這樣一來(lái)，下圖所示的傳統(tǒng)流程中產(chǎn)品經(jīng)理提供需求，需求人員進(jìn)行需求分析、開(kāi)發(fā)人員進(jìn)行開(kāi)發(fā)，最后交給測(cè)試人員進(jìn)行測(cè)試的方法，就無(wú)法滿足測(cè)試覆蓋和測(cè)試效率的要求。 相對(duì)于傳統(tǒng)的單體模式而言，微服務(wù)模式下對(duì)測(cè)試帶來(lái)的挑戰(zhàn)總結(jié)起來(lái)包括以下內(nèi)容：

• 1. 微服務(wù)系統(tǒng)模塊層次化，需要保證模塊內(nèi)部代碼的質(zhì)量。這種場(chǎng)景下傳統(tǒng)的端到端的測(cè)試無(wú)法滿足測(cè)試要求；

• 2. 需要保證各個(gè)微服務(wù)系統(tǒng)內(nèi)部模塊間的正確性。系統(tǒng)模塊間以及前端和后端通常會(huì)同時(shí)開(kāi)展開(kāi)發(fā)工作，模塊間或者前后端通過(guò)接口（通常是Restful http接口）進(jìn)行連接，而模塊和后端往往沒(méi)有界面，為了保證各個(gè)系統(tǒng)單個(gè)依賴系統(tǒng)的正確性，因此需要借助Mock技術(shù)隔離依賴的前提下進(jìn)行接口級(jí)的測(cè)試；

• 3. 需要保證微服務(wù)系統(tǒng)中的接口一致性，即契約的一致性。需要通過(guò)契約測(cè)試手段保證契約的正確性，進(jìn)而保證同步開(kāi)發(fā)過(guò)程中的前后開(kāi)發(fā)的正確性和一致性；

• 4. 需要保障單個(gè)微服務(wù)系統(tǒng)的正確性。需要進(jìn)行組件級(jí)的測(cè)試進(jìn)行微服務(wù)系統(tǒng)的正確性；

• 5. 需要保障整個(gè)系統(tǒng)的正確性。各個(gè)微服務(wù)系統(tǒng)串接之后通過(guò)端到端的測(cè)試保證整體系統(tǒng)的正確性；

“

微服務(wù)架構(gòu)下如何開(kāi)展測(cè)試

針對(duì)上面提到的微服務(wù)對(duì)測(cè)試的挑戰(zhàn)，一方面為了保證在服務(wù)各個(gè)層級(jí)上對(duì)微服務(wù)進(jìn)行全面的測(cè)試，特別是對(duì)于分布式系統(tǒng)；另一方面又要確保測(cè)試執(zhí)行的效率，這樣才能保證持續(xù)集成/持續(xù)交付（CI/CD）。因此，總體的測(cè)試策略采用如下解決方法：

• 1. 開(kāi)展「質(zhì)量」文化。讓開(kāi)發(fā)人員建立起代碼「質(zhì)量」意識(shí)，用于保障模塊內(nèi)部的質(zhì)量；

• 2. 采用自動(dòng)化測(cè)試手段。在微服務(wù)架構(gòu)中，開(kāi)發(fā)分解為負(fù)責(zé)不同服務(wù)的多個(gè)小組，測(cè)試人員往往每天要花費(fèi)大量的時(shí)間，了解不同團(tuán)隊(duì)的開(kāi)發(fā)進(jìn)度。如果還需要手動(dòng)進(jìn)行回歸測(cè)試（Regression Test），最終將會(huì)不堪重負(fù)。所以自動(dòng)化測(cè)試在微服務(wù)模式下是必須采取的手段。

• 3. 分層的自動(dòng)化測(cè)試策略。自動(dòng)化測(cè)試分層在Mike Cohn 提出的測(cè)試金字塔（Test Pyramid）原理中進(jìn)行了詳細(xì)的闡述。它提倡在代碼級(jí)、接口級(jí)、應(yīng)用級(jí)進(jìn)行不同粒度的測(cè)試來(lái)保證系統(tǒng)的質(zhì)量。從自動(dòng)化測(cè)試投入比例來(lái)看，單元測(cè)試和靜態(tài)代碼掃描的投入比例最大，其次是接口自動(dòng)化測(cè)試，最后是UI自動(dòng)化測(cè)試。同時(shí)為了提高測(cè)試效率和測(cè)試覆蓋率，功能測(cè)試需要借助探索式測(cè)試手段開(kāi)展測(cè)試。

• 4. 采用流水線技術(shù)進(jìn)行可視化快速反饋。由于微服務(wù)系統(tǒng)非常多，這樣往往會(huì)增加了運(yùn)維和溝通成本，為了提高溝通效率，需要借助流水線的技術(shù)，可視化查看每一個(gè)構(gòu)建（Build）、測(cè)試（Test）、部署（Deploy）過(guò)程，快速做出質(zhì)量反饋和處理決策。通過(guò)可視化流水線最終可以實(shí)現(xiàn)各個(gè)環(huán)節(jié)的監(jiān)控，采用DevOps手段打通業(yè)務(wù)、開(kāi)發(fā)、測(cè)試和運(yùn)維的部門墻。

下面結(jié)合分層自動(dòng)化測(cè)試的思想，首先對(duì)靜態(tài)代碼掃描進(jìn)行介紹。

靜態(tài)代碼掃描

“

靜態(tài)代碼掃描背景

靜態(tài)代碼分析是指在不運(yùn)行代碼的方式下，通過(guò)詞法分析、語(yǔ)法分析、控制流、數(shù)據(jù)流分析等技術(shù)對(duì)程序代碼進(jìn)行掃描的技術(shù)。它的目的是驗(yàn)證代碼是否滿足規(guī)范性、安全性、可靠性、可維護(hù)性的要求。靜態(tài)代碼掃描處于分層自動(dòng)化測(cè)試的最底層，它和單元測(cè)試同級(jí)別。為了保證公司代碼的規(guī)范性、安全性、可靠性的要求，通過(guò)定制公司級(jí)的靜態(tài)代碼掃描規(guī)范、掃描規(guī)則和掃描實(shí)施流程保證實(shí)施高效落地。

“

靜態(tài)代碼掃描意義

為開(kāi)發(fā)者

軟件開(kāi)發(fā)人員最終負(fù)責(zé)代碼質(zhì)量。代碼質(zhì)量是非功能性需求的一部分，因此是開(kāi)發(fā)人員的直接責(zé)任。代碼質(zhì)量不應(yīng)該存在技術(shù)債務(wù)，在開(kāi)發(fā)的過(guò)程中每一步都提供反饋，從IDE到發(fā)布。這使得開(kāi)發(fā)人員能夠盡早做出有關(guān)代碼質(zhì)量的決策，使他們能夠做得更好，并提供質(zhì)量更好的軟件產(chǎn)品。

為DevOps

DevOps需要確保軟件的構(gòu)建方式正確。DevOps中涉及的責(zé)任很多，其中包括支持開(kāi)發(fā)流程，自動(dòng)化測(cè)試，確保質(zhì)量，提高生產(chǎn)力.....并最終實(shí)現(xiàn)持續(xù)部署。良好的代碼質(zhì)量是實(shí)現(xiàn)所有這些目標(biāo)的必要條件，盡管不是充分條件。靜態(tài)代碼掃描可在任何構(gòu)建/測(cè)試/部署步驟中添加的代碼質(zhì)量檢驗(yàn)門檻，能夠自動(dòng)執(zhí)行一組統(tǒng)一的質(zhì)量標(biāo)準(zhǔn)，從而確保組織交付更好的軟件。

為管理者

代碼靜態(tài)掃描可降低風(fēng)險(xiǎn)并提高團(tuán)隊(duì)生產(chǎn)力。管理人員需要能夠安全地運(yùn)行軟件，并且需要花費(fèi)合理的投資回報(bào)。我們的解決方案一目了然地顯示了他們面臨的技術(shù)債務(wù)以及他們緩解的成本。它還具有開(kāi)箱即用的功能，可以系統(tǒng)地提高開(kāi)發(fā)團(tuán)隊(duì)的可維護(hù)性和長(zhǎng)期生產(chǎn)力。這使管理人員能夠以最佳成本使用風(fēng)險(xiǎn)控制方法確保其組織能夠交付更好的軟件。

“

靜態(tài)代碼掃描介紹

靜態(tài)代碼掃描處在特性分支開(kāi)發(fā)完成之后，具體的描述如下：

• 1. 開(kāi)發(fā)人員從Master分支拉取特性分支作為開(kāi)發(fā)分支；

• 2. 開(kāi)發(fā)完特性分支后、代碼構(gòu)建、單元測(cè)試、靜態(tài)代碼掃描；

• 3. 通過(guò)后合并到Master分支，用于投產(chǎn)；

“

靜態(tài)代碼掃描流程

隨行付靜態(tài)代碼掃描平臺(tái)的具體實(shí)現(xiàn)是通過(guò)集成SonarQube平臺(tái)工具、Jenkins集成工具、IDE SonarLint插件和CheckStyle本地化規(guī)則模板等開(kāi)源工具、插件集而成。實(shí)現(xiàn)本地化代碼的實(shí)施檢測(cè)，版本構(gòu)建后的二次檢測(cè)，以及郵件反饋等功能的流程閉環(huán)，保證投產(chǎn)前代碼符合隨行付代碼規(guī)范的要求。具體的流程如下圖所示：

• 1.本地化IDE中通過(guò)SonarLint插件實(shí)現(xiàn)和SonarQube平臺(tái)規(guī)則、規(guī)范的同步、實(shí)現(xiàn)本地代碼檢查；隨行付定制化了java規(guī)則、XML規(guī)則257條，javascript規(guī)則86條，用于檢測(cè)代碼的規(guī)范性、代碼缺陷、漏洞、壞味道、重復(fù)率等信息。并將定制化的規(guī)則放到了SonarQube平臺(tái)上，SonrLint插件的規(guī)則比較全面，包括所有的sonajava規(guī)則和javascript規(guī)則，為了保證本地使用定制的規(guī)則，且同sonarqube中的規(guī)則一致，需要遠(yuǎn)程連接SonarQube服務(wù)器,并綁定項(xiàng)目。以Eclipse為例，展示SonarQube連接和項(xiàng)目綁定過(guò)程：

• 2.代碼提交到代碼庫(kù)GitLab中后，在Jenkins中測(cè)試環(huán)境構(gòu)建時(shí)，自動(dòng)觸發(fā)Sonar掃描，并將掃描結(jié)果發(fā)布到SonarQube平臺(tái)。下圖為SonarQube展示的一個(gè)項(xiàng)目的結(jié)果：

• 3.SonarQube平臺(tái)根據(jù)質(zhì)量閥的要求，不滿足質(zhì)量閥要求則郵件通知開(kāi)發(fā)人員。

質(zhì)量閥要求：
 ? ?1.新覆蓋率大于等于80%；
 ? ?2.新增Bugs為0；
 ? ?3.新增漏洞為0；
 ? ?4.新增壞味道為0；

• 4.開(kāi)發(fā)人員收到郵件后，進(jìn)行代碼處理，直到滿足規(guī)范要求為止。

• 5.以周為單位統(tǒng)計(jì)SonarQube平臺(tái)中靜態(tài)代碼掃描出來(lái)的Bugs\漏洞\壞味道的數(shù)量，定時(shí)自動(dòng)發(fā)送周報(bào)給相關(guān)干系人，報(bào)告中會(huì)包含問(wèn)題處理情況的趨勢(shì)圖。

SonarQube與規(guī)則

SonarQube是一個(gè)用于代碼質(zhì)量管理的開(kāi)源平臺(tái)，支持25+種編程語(yǔ)言的質(zhì)量掃描。SonqrQube由遠(yuǎn)程機(jī)、Server端和數(shù)據(jù)庫(kù)構(gòu)成。遠(yuǎn)程客戶機(jī)可以通過(guò)各種不同的分析機(jī)制，從而將被分析的項(xiàng)目代碼上傳到SonarQube server 并進(jìn)行代碼質(zhì)量的管理和分析，SonarQube 還會(huì)通過(guò)Web API將分析的結(jié)果以可視化、可度量的方式展示給出來(lái)。邏輯結(jié)構(gòu)如下圖所示：

“

SonarQube的整合能力

SonarQube平臺(tái)中支持整合各種靜態(tài)代碼掃描檢測(cè)工具。SonarQube中各種代碼檢測(cè)工具分析對(duì)象及應(yīng)用技術(shù)對(duì)比：

CheckStyle

可以很方便的幫我們檢查Java代碼中的格式錯(cuò)誤，它能夠自動(dòng)化代碼規(guī)范檢查過(guò)程，從而使得開(kāi)發(fā)人員從這項(xiàng)重要，但是枯燥的任務(wù)中解脫出來(lái)?；旧隙际歉鶕?jù)開(kāi)發(fā)規(guī)則定制規(guī)則。主要涵蓋以下內(nèi)容：

• Javadoc 注釋：檢查類及方法的 Javadoc 注釋

• 命名約定：檢查命名是否符合命名規(guī)范

• 標(biāo)題：檢查文件是否以某些行開(kāi)頭

• Import 語(yǔ)句：檢查 Import 語(yǔ)句是否符合定義規(guī)范

• 代碼塊大小，即檢查類、方法等代碼塊的行數(shù)

• 空白：檢查空白符，如 tab，回車符等

• 修飾符：修飾符號(hào)的檢查，如修飾符的定義順序

• 塊：檢查是否有空塊或無(wú)效塊

• 代碼問(wèn)題：檢查重復(fù)代碼，條件判斷，魔數(shù)等問(wèn)題

• 類設(shè)計(jì)：檢查類的定義是否符合規(guī)范，如構(gòu)造函數(shù)的定義等問(wèn)題

FindBugs

Findbugs是一個(gè)靜態(tài)分析工具，它檢查類或者JAR文件，將字節(jié)碼與一組缺陷模式進(jìn)行對(duì)比以發(fā)現(xiàn)可能的問(wèn)題。主要涵蓋以下內(nèi)容：

• Bad practice 壞的實(shí)踐：常見(jiàn)代碼錯(cuò)誤，用于靜態(tài)代碼檢查時(shí)進(jìn)行缺陷模式匹配

• Correctness 可能導(dǎo)致錯(cuò)誤的代碼，如空指針引用等

• 國(guó)際化相關(guān)問(wèn)題：如錯(cuò)誤的字符串轉(zhuǎn)換

• 可能受到的惡意***，如訪問(wèn)權(quán)限修飾符的定義等

• 多線程的正確性：如多線程編程時(shí)常見(jiàn)的同步，線程調(diào)度問(wèn)題

• 運(yùn)行時(shí)性能問(wèn)題：如由變量定義，方法調(diào)用導(dǎo)致的代碼低效問(wèn)題

PMD

一種開(kāi)源分析Java代碼錯(cuò)誤的工具，其原理為使用JavaCC生成解析器來(lái)解析源代碼并生成AST(抽象語(yǔ)法樹(shù))。與其他分析工具不同的是，PMD通過(guò)靜態(tài)分析獲知代碼錯(cuò)誤。也就是說(shuō)，在不運(yùn)行Java程序的情況下報(bào)告錯(cuò)誤。PMD附帶了許多可以直接使用的規(guī)則，利用這些規(guī)則可以找出Java源程序的許多問(wèn)題，例如：

• 潛在的 Bugs：檢查潛在代碼錯(cuò)誤，如空的 try/catch/finally/switch 語(yǔ)句

• 未使用代碼（Dead code）：檢查未使用的變量，參數(shù)，方法等

• 可選的代碼：String/StringBuffer的濫用

• 復(fù)雜的表達(dá)式：檢查不必要的 if 語(yǔ)句，可被 while 替代的 for 循環(huán)

• 重復(fù)的代碼：檢查重復(fù)的代碼

• 循環(huán)體創(chuàng)建新對(duì)象：檢查在循環(huán)體內(nèi)實(shí)例化新對(duì)象

• 資源關(guān)閉：檢查 Connect，Result，Statement 等資源使用之后是否被關(guān)閉掉

此外，用戶還可以自己定義規(guī)則，檢查Java代碼是否符合某些特定的編碼規(guī)范。例如，你可以編寫一個(gè)規(guī)則，要求PMD找出所有創(chuàng)建Thread和Socket對(duì)象的操作。

三種工具對(duì)比

由表中可以看出幾種工具對(duì)于代碼檢查各有側(cè)重。其中，Checkstyle 更偏重于代碼編寫格式，及是否符合編碼規(guī)范的檢驗(yàn)， 對(duì)代碼 bug 的發(fā)現(xiàn)功能較弱；而 FindBugs，PMD著重于發(fā)現(xiàn)代碼缺陷。在對(duì)代碼缺陷檢查中，這三種工具在針對(duì)的代碼缺陷類別也各有不同，且類別之間有重疊。

“

規(guī)則定制

考慮到Sonar Java規(guī)則已經(jīng)包含了PMD和CheckStyle規(guī)則，因此我們選擇了Sonar的默認(rèn)規(guī)則，并對(duì)其進(jìn)行了定制化。下圖中SonarQube中展示了部分定制化規(guī)則內(nèi)容。

定制化后的規(guī)則覆蓋的代碼缺陷類型如下表所示(部分規(guī)則)：