在開發(fā)早期，發(fā)現(xiàn)并修復(fù)bug在許多方面都有好處。它可以減少開發(fā)時(shí)間，降低成本，并且防止數(shù)據(jù)泄露或其他安全漏洞。特別是對于DevOps，盡早持續(xù)地將測試納入SDLC軟件開發(fā)生命周期是非常有幫助的。

這就是動(dòng)態(tài)和靜態(tài)分析測試的用武之地。它們在SDLC中各自服務(wù)于不同的目的，同時(shí)也為任何開發(fā)團(tuán)隊(duì)提供獨(dú)特且?guī)缀跫磿r(shí)的投資回報(bào)率。

靜態(tài)與動(dòng)態(tài)分析：了解兩者的區(qū)別

靜態(tài)代碼分析是一個(gè)廣義的術(shù)語，用于描述幾種不同類型的分析。然而，所有這些分析都有一個(gè)共同的特征：它們不需要代碼執(zhí)行即可運(yùn)行。

相比之下，動(dòng)態(tài)分析需要代碼執(zhí)行。盡管還有其他區(qū)別，但這一特征是區(qū)分這兩種測試方法的根本因素。

這也意味著每種方法在開發(fā)過程的不同階段都提供了不同的好處。為了理解這些差異，我們可以回顧以下內(nèi)容。

• 每種策略需要什么。

• 需要使用測試類型。

• 協(xié)助該過程的工具。

什么是靜態(tài)分析？

靜態(tài)代碼分析測試可以包括各種類型，其中兩種主要的類型是基于模式的測試和基于流的測試。

基于模式的靜態(tài)分析可以查找出違反定義編碼規(guī)則的代碼。除了確保代碼滿足合規(guī)性或內(nèi)部計(jì)劃的統(tǒng)一期望外，它還可以幫助團(tuán)隊(duì)預(yù)防缺陷，如資源泄漏、性能和安全問題、邏輯錯(cuò)誤和API濫用等。

基于流的靜態(tài)分析可以查找和分析代碼的各種路徑。這可以通過控制流（執(zhí)行行(hang)的順序）和數(shù)據(jù)流（變量或類似實(shí)體可以被創(chuàng)建、改變、使用和銷毀的順序）來實(shí)現(xiàn)。這些過程可以暴露出導(dǎo)致關(guān)鍵缺陷的問題，例如：

• 內(nèi)存損壞（緩沖區(qū)覆蓋）

• 內(nèi)存訪問違規(guī)

• 空指針解引用

• 競態(tài)條件（Race conditions）

• 死鎖（Deadlocks）

它還可以通過繞過安全關(guān)鍵代碼（如身份驗(yàn)證或加密代碼）的路徑來檢測安全問題。

此外，度量分析包括對代碼的各個(gè)方面進(jìn)行衡量和可視化。它可以幫助檢測現(xiàn)有的缺陷，但更常見的是，為后續(xù)代碼維護(hù)時(shí)，提前消除可能帶來未知缺陷的可能性。這是通過發(fā)現(xiàn)代碼中的復(fù)雜性和冗長性來完成的，例如：

• 過大的組件

• 過多的循環(huán)嵌套

• 一系列過于冗長的判定

• 復(fù)雜的組件間依賴關(guān)系

什么是動(dòng)態(tài)分析？

動(dòng)態(tài)分析有時(shí)被稱為運(yùn)行時(shí)錯(cuò)誤檢測，動(dòng)態(tài)分析是測試類型之間的區(qū)別開始變得模糊的地方。動(dòng)態(tài)應(yīng)用程序安全測試（DAST）是一種分析測試，目的是檢查測試項(xiàng)目而不是執(zhí)行它。這種白盒測試檢查的是內(nèi)部行為，并非外部行為。然而測試中的代碼必須被執(zhí)行。這是通過運(yùn)行與動(dòng)態(tài)測試相同的黑盒測試來完成的。

這意味著動(dòng)態(tài)分析可以在內(nèi)部故障發(fā)生的瞬間檢測并報(bào)告這些故障。這使得測試人員更容易精確地將這些故障與測試行動(dòng)關(guān)聯(lián)起來，以便進(jìn)行事故報(bào)告。類似于好的靜態(tài)分析，DAST提供了完整的技術(shù)細(xì)節(jié)，使開發(fā)人員能夠隔離和修復(fù)潛在的缺陷。

DAST還擴(kuò)展了所有級(jí)別的測試能力，從單元測試到驗(yàn)收，使檢測內(nèi)部故障成為可能，這些故障指向在測試停止后發(fā)生或?qū)⒁l(fā)生的無法觀察到的外部故障。

靜態(tài)分析的利弊

凡事皆有利弊，靜態(tài)分析測試也有優(yōu)點(diǎn)和缺點(diǎn)。

靜態(tài)分析的利弊

優(yōu)點(diǎn)：	缺點(diǎn)：
1. 在不執(zhí)行源代碼的情況下評估源代碼；	1. 可能返回誤報(bào)和漏報(bào)，會(huì)分散開發(fā)人員的注意力；
2. 分析整個(gè)代碼的漏洞和錯(cuò)誤；	2. 手動(dòng)操作需要很長時(shí)間；
3. 遵循定制的、定義好的規(guī)則；	3. 無法找到運(yùn)行時(shí)環(huán)境中出現(xiàn)的錯(cuò)誤或漏洞；
4. 增強(qiáng)開發(fā)人員的責(zé)任感；	4. 決定應(yīng)用哪些行業(yè)編碼標(biāo)準(zhǔn)可能會(huì)令人困擾；
5. 具有自動(dòng)化能力；	5. 確定偏離違反規(guī)則是否合適，可能具有挑戰(zhàn)性。
6. 盡早突出錯(cuò)誤并減少修復(fù)漏洞所需的時(shí)間。

雖然這些缺點(diǎn)看起來令人生畏，但靜態(tài)分析的缺點(diǎn)可以用兩件事來補(bǔ)充：

• 自動(dòng)化靜態(tài)分析

• 使用動(dòng)態(tài)分析技術(shù)

為什么靜態(tài)代碼分析如此有價(jià)值？

所有這些類型的靜態(tài)分析都有一個(gè)共同點(diǎn)：它們會(huì)涉及掃描或檢查程序源代碼。

這是一種快速而簡單的暴露關(guān)鍵缺陷的方法。他實(shí)現(xiàn)了100%的覆蓋率和100%的客觀結(jié)果。

不斷地執(zhí)行這樣的靜態(tài)代碼分析是有意義的，因?yàn)樗峁┝诉@些可操作的結(jié)果，減少了成本和開發(fā)時(shí)間，增加了代碼覆蓋率，等等。

超越靜態(tài)分析的范疇

靜態(tài)掃描提供信息來幫助預(yù)測代碼集成和執(zhí)行時(shí)可能會(huì)發(fā)生的情況。它根據(jù)工具認(rèn)為的缺陷標(biāo)準(zhǔn)來檢測缺陷。通常也可以根據(jù)您的偏好和優(yōu)先級(jí)進(jìn)行定制。

但是，工具不能告訴您測試中或生產(chǎn)中的系統(tǒng)何時(shí)交付了意外的、不適當(dāng)?shù)幕虿粶?zhǔn)確的結(jié)果。

這里的挑戰(zhàn)是難以觀察意想不到的行為。例如，對于用戶、測試人員或測試執(zhí)行工具來說，事務(wù)可能看起來正確地進(jìn)行，但實(shí)際上，組件拋出了一個(gè)未處理的異常，并且未能正確地處理它。一個(gè)控制系統(tǒng)可能會(huì)在測試三天內(nèi)快速正確地響應(yīng)，但可能會(huì)在生產(chǎn)的第四天出現(xiàn)內(nèi)存泄漏并導(dǎo)致崩潰。

通過使用靜態(tài)代碼分析工具修復(fù)所有檢測到的缺陷，并不能保證不會(huì)有其他缺陷導(dǎo)致類似的失敗。這就是為什么將失敗的定義應(yīng)用于內(nèi)部和外部行為是很重要的，即使在集成之后也是如此。內(nèi)部故障必須在外部故障出現(xiàn)之前檢測到。

結(jié)合靜態(tài)和動(dòng)態(tài)分析的最佳實(shí)踐

將靜態(tài)和動(dòng)態(tài)分析相結(jié)合，是獲得可操作結(jié)果、減少錯(cuò)誤發(fā)生、增加錯(cuò)誤檢測并創(chuàng)建更安全代碼的最佳選擇。兩者并無優(yōu)劣之分。它們像精心制作的瑞士手表的所有齒輪一樣協(xié)同工作。

要同時(shí)使用靜態(tài)和動(dòng)態(tài)分析，請遵循這些最佳實(shí)踐：

• 將它們與符合您需求的手動(dòng)和自動(dòng)化解決方案一起使用；

• 使代碼對其他開發(fā)人員具有可讀性和可重用性；

• 在SDLC的正確點(diǎn)使用正確的方法——在早期使用靜態(tài)方法，在運(yùn)行時(shí)環(huán)境中使用動(dòng)態(tài)方法；

• 利用這兩種方法對您的項(xiàng)目進(jìn)行更全面的概述；

• 避免只依賴一種測試方法的陷阱，一個(gè)小的疏忽可能導(dǎo)致大的問題。

將靜態(tài)和動(dòng)態(tài)分析相結(jié)合，使團(tuán)隊(duì)能夠定位更大范圍和數(shù)量的代碼威脅。

獲取有價(jià)值的見解，來選擇最適合您團(tuán)隊(duì)的軟件測試解決方案。