摘要

靜態(tài)分析和動態(tài)分析是一種雙管齊下的方法，可以在可靠性、錯誤檢測、效率和安全性方面改進(jìn)開發(fā)過程。為什么它們都很重要?它們又有什么區(qū)別呢？

前言

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

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

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

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

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

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

每種策略需要什么。

需要使用測試類型。

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

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

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

基于模式的靜態(tài)分析可以查找出違反定義編碼規(guī)則的代碼。除了確保代碼滿足合規(guī)性或內(nèi)部計劃的統(tǒng)一期望外，它還可以幫助團(tuán)隊預(yù)防缺陷，如資源泄漏、性能和安全問題、邏輯錯誤和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)鍵代碼（如身份驗證或加密代碼）的路徑來檢測安全問題。

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

過大的組件

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

一系列過于冗長的判定

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

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

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

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

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

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

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

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

優(yōu)點(diǎn)：

1. 在不執(zhí)行源代碼的情況下評估源代碼；

2. 分析整個代碼的漏洞和錯誤；

3. 遵循定制的、定義好的規(guī)則；

4. 增強(qiáng)開發(fā)人員的責(zé)任感；

5. 具有自動化能力；

6. 盡早突出錯誤并減少修復(fù)漏洞所需的時間。

缺點(diǎn)：

1. 可能返回誤報和漏報，會分散開發(fā)人員的注意力；

2. 手動操作需要很長時間；

3. 無法找到運(yùn)行時環(huán)境中出現(xiàn)的錯誤或漏洞；

4. 決定應(yīng)用哪些行業(yè)編碼標(biāo)準(zhǔn)可能會令人困擾；

5. 確定偏離違反規(guī)則是否合適，可能具有挑戰(zhàn)性。

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

自動化靜態(tài)分析

使用動態(tài)分析技術(shù)

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

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

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

不斷地執(zhí)行這樣的靜態(tài)代碼分析是有意義的，因為它提供了這些可操作的結(jié)果，減少了成本和開發(fā)時間，增加了代碼覆蓋率，等等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

審核編輯：湯梓紅