您好,登錄后才能下訂單哦!
靜態(tài)代碼掃描為整個(gè)發(fā)展組織增加價(jià)值。無論您在開發(fā)組織中發(fā)揮的作用如何,靜態(tài)代碼掃描解決方案都具有附加價(jià)值,擁有軟件開發(fā)中所需要的尖端功能,最大限度地提高質(zhì)量并管理軟件產(chǎn)品中的風(fēng)險(xiǎn)。
背景
微服務(wù)架構(gòu)模式具有服務(wù)間獨(dú)立,可獨(dú)立開發(fā)部署等特點(diǎn),獨(dú)立開發(fā)誘發(fā)了技術(shù)上的分離,HTTP通信增加了問題診斷的復(fù)雜度,對(duì)系統(tǒng)的功能、性能和安全方面的質(zhì)量保障帶來了很大的挑戰(zhàn)。
“
微服務(wù)架構(gòu)對(duì)測試的挑戰(zhàn)
微服務(wù)架構(gòu)模式下多個(gè)獨(dú)立業(yè)務(wù)服務(wù)同時(shí)開展開發(fā)工作,每個(gè)系統(tǒng)都有各自的業(yè)務(wù)范圍和開發(fā)周期要求,這樣一來,下圖所示的傳統(tǒng)流程中產(chǎn)品經(jīng)理提供需求,需求人員進(jìn)行需求分析、開發(fā)人員進(jìn)行開發(fā),最后交給測試人員進(jìn)行測試的方法,就無法滿足測試覆蓋和測試效率的要求。 相對(duì)于傳統(tǒng)的單體模式而言,微服務(wù)模式下對(duì)測試帶來的挑戰(zhàn)總結(jié)起來包括以下內(nèi)容:
1. 微服務(wù)系統(tǒng)模塊層次化,需要保證模塊內(nèi)部代碼的質(zhì)量。這種場景下傳統(tǒng)的端到端的測試無法滿足測試要求;
2. 需要保證各個(gè)微服務(wù)系統(tǒng)內(nèi)部模塊間的正確性。系統(tǒng)模塊間以及前端和后端通常會(huì)同時(shí)開展開發(fā)工作,模塊間或者前后端通過接口(通常是Restful http接口)進(jìn)行連接,而模塊和后端往往沒有界面,為了保證各個(gè)系統(tǒng)單個(gè)依賴系統(tǒng)的正確性,因此需要借助Mock技術(shù)隔離依賴的前提下進(jìn)行接口級(jí)的測試;
3. 需要保證微服務(wù)系統(tǒng)中的接口一致性,即契約的一致性。需要通過契約測試手段保證契約的正確性,進(jìn)而保證同步開發(fā)過程中的前后開發(fā)的正確性和一致性;
4. 需要保障單個(gè)微服務(wù)系統(tǒng)的正確性。需要進(jìn)行組件級(jí)的測試進(jìn)行微服務(wù)系統(tǒng)的正確性;
“
微服務(wù)架構(gòu)下如何開展測試
針對(duì)上面提到的微服務(wù)對(duì)測試的挑戰(zhàn),一方面為了保證在服務(wù)各個(gè)層級(jí)上對(duì)微服務(wù)進(jìn)行全面的測試,特別是對(duì)于分布式系統(tǒng);另一方面又要確保測試執(zhí)行的效率,這樣才能保證持續(xù)集成/持續(xù)交付(CI/CD)。因此,總體的測試策略采用如下解決方法:
1. 開展「質(zhì)量」文化。讓開發(fā)人員建立起代碼「質(zhì)量」意識(shí),用于保障模塊內(nèi)部的質(zhì)量;
2. 采用自動(dòng)化測試手段。在微服務(wù)架構(gòu)中,開發(fā)分解為負(fù)責(zé)不同服務(wù)的多個(gè)小組,測試人員往往每天要花費(fèi)大量的時(shí)間,了解不同團(tuán)隊(duì)的開發(fā)進(jìn)度。如果還需要手動(dòng)進(jìn)行回歸測試(Regression Test),最終將會(huì)不堪重負(fù)。所以自動(dòng)化測試在微服務(wù)模式下是必須采取的手段。
下面結(jié)合分層自動(dòng)化測試的思想,首先對(duì)靜態(tài)代碼掃描進(jìn)行介紹。
靜態(tài)代碼掃描
“
靜態(tài)代碼掃描背景
靜態(tài)代碼分析是指在不運(yùn)行代碼的方式下,通過詞法分析、語法分析、控制流、數(shù)據(jù)流分析等技術(shù)對(duì)程序代碼進(jìn)行掃描的技術(shù)。它的目的是驗(yàn)證代碼是否滿足規(guī)范性、安全性、可靠性、可維護(hù)性的要求。靜態(tài)代碼掃描處于分層自動(dòng)化測試的最底層,它和單元測試同級(jí)別。為了保證公司代碼的規(guī)范性、安全性、可靠性的要求,通過定制公司級(jí)的靜態(tài)代碼掃描規(guī)范、掃描規(guī)則和掃描實(shí)施流程保證實(shí)施高效落地。
“
靜態(tài)代碼掃描意義
軟件開發(fā)人員最終負(fù)責(zé)代碼質(zhì)量。代碼質(zhì)量是非功能性需求的一部分,因此是開發(fā)人員的直接責(zé)任。代碼質(zhì)量不應(yīng)該存在技術(shù)債務(wù),在開發(fā)的過程中每一步都提供反饋,從IDE到發(fā)布。這使得開發(fā)人員能夠盡早做出有關(guān)代碼質(zhì)量的決策,使他們能夠做得更好,并提供質(zhì)量更好的軟件產(chǎn)品。
DevOps需要確保軟件的構(gòu)建方式正確。DevOps中涉及的責(zé)任很多,其中包括支持開發(fā)流程,自動(dòng)化測試,確保質(zhì)量,提高生產(chǎn)力.....并最終實(shí)現(xiàn)持續(xù)部署。良好的代碼質(zhì)量是實(shí)現(xiàn)所有這些目標(biāo)的必要條件,盡管不是充分條件。靜態(tài)代碼掃描可在任何構(gòu)建/測試/部署步驟中添加的代碼質(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ù)以及他們緩解的成本。它還具有開箱即用的功能,可以系統(tǒng)地提高開發(fā)團(tuán)隊(duì)的可維護(hù)性和長期生產(chǎn)力。這使管理人員能夠以最佳成本使用風(fēng)險(xiǎn)控制方法確保其組織能夠交付更好的軟件。
“
靜態(tài)代碼掃描介紹
靜態(tài)代碼掃描處在特性分支開發(fā)完成之后,具體的描述如下:
1. 開發(fā)人員從Master分支拉取特性分支作為開發(fā)分支;
2. 開發(fā)完特性分支后、代碼構(gòu)建、單元測試、靜態(tài)代碼掃描;
“
靜態(tài)代碼掃描流程
隨行付靜態(tài)代碼掃描平臺(tái)的具體實(shí)現(xiàn)是通過集成SonarQube平臺(tái)工具、Jenkins集成工具、IDE SonarLint插件和CheckStyle本地化規(guī)則模板等開源工具、插件集而成。實(shí)現(xiàn)本地化代碼的實(shí)施檢測,版本構(gòu)建后的二次檢測,以及郵件反饋等功能的流程閉環(huán),保證投產(chǎn)前代碼符合隨行付代碼規(guī)范的要求。具體的流程如下圖所示:
質(zhì)量閥要求:
? ?1.新覆蓋率大于等于80%;
? ?2.新增Bugs為0;
? ?3.新增漏洞為0;
? ?4.新增壞味道為0;
4.開發(fā)人員收到郵件后,進(jìn)行代碼處理,直到滿足規(guī)范要求為止。
SonarQube與規(guī)則
SonarQube是一個(gè)用于代碼質(zhì)量管理的開源平臺(tái),支持25+種編程語言的質(zhì)量掃描。SonqrQube由遠(yuǎn)程機(jī)、Server端和數(shù)據(jù)庫構(gòu)成。遠(yuǎn)程客戶機(jī)可以通過各種不同的分析機(jī)制,從而將被分析的項(xiàng)目代碼上傳到SonarQube server 并進(jìn)行代碼質(zhì)量的管理和分析,SonarQube 還會(huì)通過Web API將分析的結(jié)果以可視化、可度量的方式展示給出來。邏輯結(jié)構(gòu)如下圖所示:
“
SonarQube的整合能力
SonarQube平臺(tái)中支持整合各種靜態(tài)代碼掃描檢測工具。SonarQube中各種代碼檢測工具分析對(duì)象及應(yīng)用技術(shù)對(duì)比:
Java靜態(tài)分析工具 | 分析對(duì)象 | 應(yīng)用技術(shù) |
---|---|---|
CheckStyle | Java源文件 | 缺陷模式匹配 |
FindBugs | 字節(jié)碼 | 缺陷模式匹配;數(shù)據(jù)流分析 |
PMD | Java源代碼 | 缺陷模式匹配 |
可以很方便的幫我們檢查Java代碼中的格式錯(cuò)誤,它能夠自動(dòng)化代碼規(guī)范檢查過程,從而使得開發(fā)人員從這項(xiàng)重要,但是枯燥的任務(wù)中解脫出來?;旧隙际歉鶕?jù)開發(fā)規(guī)則定制規(guī)則。主要涵蓋以下內(nèi)容:
Javadoc 注釋:檢查類及方法的 Javadoc 注釋
命名約定:檢查命名是否符合命名規(guī)范
標(biāo)題:檢查文件是否以某些行開頭
Import 語句:檢查 Import 語句是否符合定義規(guī)范
代碼塊大小,即檢查類、方法等代碼塊的行數(shù)
空白:檢查空白符,如 tab,回車符等
修飾符:修飾符號(hào)的檢查,如修飾符的定義順序
塊:檢查是否有空塊或無效塊
代碼問題:檢查重復(fù)代碼,條件判斷,魔數(shù)等問題
Findbugs是一個(gè)靜態(tài)分析工具,它檢查類或者JAR文件,將字節(jié)碼與一組缺陷模式進(jìn)行對(duì)比以發(fā)現(xiàn)可能的問題。主要涵蓋以下內(nèi)容:
Bad practice 壞的實(shí)踐:常見代碼錯(cuò)誤,用于靜態(tài)代碼檢查時(shí)進(jìn)行缺陷模式匹配
Correctness 可能導(dǎo)致錯(cuò)誤的代碼,如空指針引用等
國際化相關(guān)問題:如錯(cuò)誤的字符串轉(zhuǎn)換
可能受到的惡意***,如訪問權(quán)限修飾符的定義等
多線程的正確性:如多線程編程時(shí)常見的同步,線程調(diào)度問題
一種開源分析Java代碼錯(cuò)誤的工具,其原理為使用JavaCC生成解析器來解析源代碼并生成AST(抽象語法樹)。與其他分析工具不同的是,PMD通過靜態(tài)分析獲知代碼錯(cuò)誤。也就是說,在不運(yùn)行Java程序的情況下報(bào)告錯(cuò)誤。PMD附帶了許多可以直接使用的規(guī)則,利用這些規(guī)則可以找出Java源程序的許多問題,例如:
潛在的 Bugs:檢查潛在代碼錯(cuò)誤,如空的 try/catch/finally/switch 語句
未使用代碼(Dead code):檢查未使用的變量,參數(shù),方法等
可選的代碼:String/StringBuffer的濫用
復(fù)雜的表達(dá)式:檢查不必要的 if 語句,可被 while 替代的 for 循環(huán)
重復(fù)的代碼:檢查重復(fù)的代碼
循環(huán)體創(chuàng)建新對(duì)象:檢查在循環(huán)體內(nèi)實(shí)例化新對(duì)象
此外,用戶還可以自己定義規(guī)則,檢查Java代碼是否符合某些特定的編碼規(guī)范。例如,你可以編寫一個(gè)規(guī)則,要求PMD找出所有創(chuàng)建Thread和Socket對(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ī)則):
代碼缺陷分類 | 示例 |
---|---|
引用操作 | 空指針引用 |
對(duì)象操作 | 對(duì)象比較(使用==而不是equals) |
表達(dá)式復(fù)雜化 | 對(duì)于的if語句 |
數(shù)組使用 | 數(shù)組下標(biāo)越界 |
未使用變量或代碼段 | 未使用變量 |
資源回收 | I/O未關(guān)閉 |
方法調(diào)用 | 未使用方法返回值 |
代碼設(shè)計(jì) | 空的try/catch/finally塊 |
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。