摘要

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

前言

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

這就是動態和靜態分析測試的用武之地。它們在SDLC中各自服務于不同的目的，同時也為任何開發團隊提供獨特且幾乎即時的投資回報率。

靜態與動態分析：了解兩者的區別

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

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

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

每種策略需要什么。

需要使用測試類型。

協助該過程的工具。

什么是靜態分析？

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

基于模式的靜態分析可以查找出違反定義編碼規則的代碼。除了確保代碼滿足合規性或內部計劃的統一期望外，它還可以幫助團隊預防缺陷，如資源泄漏、性能和安全問題、邏輯錯誤和API濫用等。

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

內存損壞（緩沖區覆蓋）

內存訪問違規

空指針解引用

競態條件（Race conditions）

死鎖（Deadlocks）

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

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

過大的組件

過多的循環嵌套

一系列過于冗長的判定

復雜的組件間依賴關系

什么是動態分析？

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

這意味著動態分析可以在內部故障發生的瞬間檢測并報告這些故障。這使得測試人員更容易精確地將這些故障與測試行動關聯起來，以便進行事故報告。類似于好的靜態分析，DAST提供了完整的技術細節，使開發人員能夠隔離和修復潛在的缺陷。

DAST還擴展了所有級別的測試能力，從單元測試到驗收，使檢測內部故障成為可能，這些故障指向在測試停止后發生或將要發生的無法觀察到的外部故障。

靜態分析的利弊

凡事皆有利弊，靜態分析測試也有優點和缺點。

靜態分析的利弊

優點：

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

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

3. 遵循定制的、定義好的規則；

4. 增強開發人員的責任感；

5. 具有自動化能力；

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

缺點：

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

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

3. 無法找到運行時環境中出現的錯誤或漏洞；

4. 決定應用哪些行業編碼標準可能會令人困擾；

5. 確定偏離違反規則是否合適，可能具有挑戰性。

雖然這些缺點看起來令人生畏，但靜態分析的缺點可以用兩件事來補充：

自動化靜態分析

使用動態分析技術

為什么靜態代碼分析如此有價值？

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

這是一種快速而簡單的暴露關鍵缺陷的方法。他實現了100%的覆蓋率和100%的客觀結果。

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

超越靜態分析的范疇

靜態掃描提供信息來幫助預測代碼集成和執行時可能會發生的情況。它根據工具認為的缺陷標準來檢測缺陷。通常也可以根據您的偏好和優先級進行定制。

但是，工具不能告訴您測試中或生產中的系統何時交付了意外的、不適當的或不準確的結果。

這里的挑戰是難以觀察意想不到的行為。例如，對于用戶、測試人員或測試執行工具來說，事務可能看起來正確地進行，但實際上，組件拋出了一個未處理的異常，并且未能正確地處理它。一個控制系統可能會在測試三天內快速正確地響應，但可能會在生產的第四天出現內存泄漏并導致崩潰。

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

結合靜態和動態分析的最佳實踐

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

要同時使用靜態和動態分析，請遵循這些最佳實踐：

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

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

在SDLC的正確點使用正確的方法——在早期使用靜態方法，在運行時環境中使用動態方法；

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

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

將靜態和動態分析相結合，使團隊能夠定位更大范圍和數量的代碼威脅。

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

審核編輯：湯梓紅