靜態分析與動態分析就像是一種「雙管齊下」的方法，用來提升開發流程在可靠度、錯誤偵測、效率與資安等面向的整體表現。但兩者之間有何不同？又為什麼各自都不可或缺？
在開發早期就發現並修正錯誤，往往能帶來多重效益，例如縮短開發時程、降低成本，並避免資料外洩或其他資安漏洞。
特別是在 DevOps 的情境下，將測試及早且持續地納入 SDLC（Software Development Life Cycle，軟體開發生命週期）中，效果尤其顯著。
這正是靜態分析與動態分析派上用場的地方。兩者在 SDLC 中各自扮演不同角色，同時也能為開發團隊帶來獨特且幾乎立即可見的投資報酬率（ROI）。
重點摘要：靜態與動態分析的核心差異快速導覽
要將軟體品質發揮到最大，關鍵在於知道何時、以及如何正確使用靜態分析與動態分析。
- 靜態 vs. 動態： 靜態分析是在不執行程式的情況下檢查程式碼；動態分析則是在程式執行期間檢驗其行為。
- 提早攔截問題： 靜態分析可在執行前就防止缺陷與資安風險進入系統。
- 找出執行期問題： 動態分析能揭露僅在執行期間才會出現的記憶體、邏輯與效能問題。
- 兩者並用： 結合靜態與動態測試可帶來更完整的涵蓋率、更快速的回饋，以及更可靠的軟體品質。
- 透過自動化提升效率： 將兩種技術整合至 CI/CD pipeline，可提供持續回饋並加速問題修正。
靜態分析 vs. 動態分析：差異解析
靜態程式碼分析是一個廣義的統稱，涵蓋多種不同分析方式。但它們有一個共同特點：不需要執行程式碼即可進行分析。
相較之下，動態分析必須執行程式碼。儘管兩者還有其他差異，但是否需要執行程式，正是區分這兩種測試方法的關鍵。
這也代表兩種方法在開發流程的不同階段，各自能發揮不同的價值。以下將從幾個面向來說明這些差異。
- 各策略的基本需求
- 各自涵蓋的測試類型
- 支援分析流程的工具
什麼是靜態分析？
靜態程式碼分析包含多種分析方式，其中最主要的兩類是樣式導向（pattern-based）與流程導向（flow-based）分析。
樣式導向靜態分析會檢查是否存在違反既定程式撰寫規範的程式碼樣式。除了確保程式碼符合法規遵循或內部規範的一致性要求外，也能協助團隊預防以下問題：
- 資源洩漏
- 效能與資安問題
- 邏輯錯誤
- API 誤用
流程導向靜態分析則是找出並分析程式中可能走過的各種路徑，包括：
- 控制流程（control flow）： 程式碼行被執行的先後順序
- 資料流程（data flow）： 變數或類似實體從建立、修改、使用到銷毀的過程
這類分析能揭露可能導致重大缺陷的問題，例如：
- 記憶體毀損（緩衝區覆寫）
- 記憶體存取違規
- Null pointer 解參考
- Race condition（競態條件）
- Deadlock（死結）
此外，這類分析也能指出繞過關鍵資安程式碼（例如身分驗證或加密處理）的路徑，進而協助偵測潛在的資安問題。
另外，指標分析（metrics analysis）會測量並視覺化程式碼的各種屬性。它有助於發現既有缺陷，但更常見的用途，是提前警示在後續維護階段，可能難以預防或偵測未來缺陷的風險，例如：
- 元件規模過大
- 迴圈巢狀層級過深
- 判斷邏輯過於冗長
- 元件間相依關係過於複雜
靜態分析的實際例子
一個簡單的靜態分析例子，就是使用自動化工具在不執行程式的情況下檢查程式碼。這些工具會分析程式碼的結構、邏輯與資料流程，協助在開發初期就發現問題。
例如，linter 會掃描 C 或 C++ 程式碼，以確保符合撰碼規範，並標示出未使用的變數、無法到達的程式碼，或不安全的語言結構。
靜態型別分析或語意分析，則會檢視整個程式碼中變數與函式的使用方式，以找出可能導致執行期失敗的原因，包括：
- 型別不一致
- 未初始化的變數
- 除以零
- API 使用錯誤
靜態分析也常被用於資安掃描。透過追蹤資料在程式碼中的流向，工具可以在不執行任何測試的情況下，偵測如緩衝區溢位、null pointer 解參考，或缺少輸入驗證等弱點。
另一個例子是程式碼複雜度分析，透過衡量複雜度與相依深度等指標，標示出難以測試或維護的函式。
在實務上，這些分析通常會自動整合至 IDE 或 CI pipeline 中，讓開發者即時取得回饋，並在軟體建置或部署之前，就能及早處理缺陷、資安風險與合規問題。
什麼是動態分析？
動態分析有時也被稱為執行期錯誤偵測（runtime error detection），在這個領域中，各種測試類型之間的界線開始變得模糊。
以嵌入式系統而言，動態分析著重於檢視應用程式的內部運作與結構，而非外部行為，因此程式碼的執行通常是透過白箱測試（white box testing）來完成。
動態分析能在內部錯誤發生的當下立即偵測並回報，讓測試人員能夠更精準地將錯誤與測試動作對應，利於事件回報與問題追蹤。
若進一步聚焦於應用程式的外部行為並以資安為重點，就會進入動態應用程式資安測試（DAST, Dynamic Application Security Testing）的範疇。DAST 屬於分析型測試，目的在於檢視受測項目本身，而非單純操作功能，但仍必須實際執行程式碼。
DAST 也延伸了經驗式測試在各個層級（從單元測試到驗收測試）的能力，使測試人員能偵測到那些原本無法從外部觀察到的內部失效，而這些失效可能會在測試結束後才對外顯現。
動態分析的實際例子
動態分析是在軟體執行期間進行檢測，用來找出僅會在執行時出現的問題。它會評估程式的實際行為、記憶體互動方式，以及對輸入的反應。
常見的例子包括單元測試與整合測試，透過受控的輸入來執行函式或元件。在測試過程中，可即時發現執行期錯誤，例如 assertion 失敗、邏輯錯誤，或未預期的邊界條件。
另一個例子是執行期記憶體分析，用來監控記憶體配置與使用情況，以找出僅在執行期間才會出現的問題：
- 記憶體洩漏
- 緩衝區溢位
- Null pointer 解參考
動態分析也廣泛應用於資安測試，例如 fuzzing，透過輸入格式錯誤或非預期的資料來執行應用程式，以找出系統當機、未定義行為或安全弱點。
在實務上，動態分析通常會整合進 CI pipeline 與測試環境中，即時回饋執行期行為、驗證功能正確性，並協助團隊在部署前攔截缺陷。
靜態分析的優缺點
和所有邁向 DevSecOps 成熟度的做法一樣，靜態分析同樣有其優點與限制。
優點
- 在不執行程式的情況下檢查程式碼。
- 對整體程式碼進行分析，以找出漏洞與錯誤。
- 可依需求套用客製化、明確定義的規則。
- 提升開發人員對程式碼品質的責任感。
- 適合自動化導入。
- 提早標示錯誤，縮短修正時間。
- 降低專案整體成本。
缺點
- 可能產生誤判（false positive／false negative），影響開發人員判斷。
- 手動執行時可能相當耗時。
- 無法找出僅在執行期環境中才會出現的錯誤或弱點。
- 選擇要套用哪些產業撰碼標準可能令人困惑。
- 有時難以判斷是否該接受偏離規則的例外情況。
雖然缺點看起來不少，但靜態分析的不足，其實可以透過以下兩點補強：
- 將靜態分析自動化。
- 搭配使用動態分析技術。
動態分析的優缺點
動態分析和其他測試方法一樣，同樣具有優勢與限制。
優點
- 在軟體執行期間評估其實際行為。
- 偵測靜態分析無法發現的執行期錯誤。
- 找出記憶體、資源與效能相關問題。
- 揭露僅在執行期間才會浮現的資安漏洞。
- 透過實際或模擬輸入，驗證功能行為是否正確。
- 精準對應測試動作與實際觀察到的錯誤。
- 支援 CI/CD 自動化，提供持續的執行期回饋。
缺點
- 對於大型或複雜系統而言，可能相當耗時。
- 需要相當完整的測試涵蓋率，才能找出所有執行期問題。
- 若測試未涵蓋特定路徑，可能會遺漏相關缺陷。
- 測試環境建置可能複雜，且耗費資源。
- 若測試輸入不足，某些深層邏輯缺陷仍可能被隱藏。
雖然這些缺點看似關鍵，但動態分析在搭配以下做法時，效果會大幅提升：
- 完整的自動化測試涵蓋率
- 先以靜態分析在執行前攔截問題
為什麼靜態程式碼分析如此重要？
所有這些靜態分析方式都有一個共同點：透過掃描或由工具檢視程式碼本身來進行分析。
這是一種快速且有效的方式，用來揭露關鍵性缺陷，並能達到100% 程式碼涵蓋率與100% 客觀結果。
持續進行靜態分析是非常合理的作法，因為它能提供可立即採取行動的結果，同時降低成本與開發時間，並提升程式碼涵蓋率等多項效益。
靜態分析的限制範圍
靜態掃描能提供資訊，用來預測程式碼整合與執行後可能發生的情況。它是依據工具所定義的「缺陷」來進行偵測，而這些定義通常可依照組織的偏好與優先順序進行客製化。
然而，靜態分析無法告訴你系統在測試或正式環境中，是否會產生非預期、不恰當或不正確的結果。
真正的挑戰在於觀察非預期行為。舉例來說，對使用者、測試人員或測試工具而言，一筆交易看似正常完成，但實際上某個元件可能已丟出未處理的例外，導致處理流程失敗。
又或者，一個控制系統在測試環境下連續三天都反應正常且即時，但在正式環境中卻可能因為記憶體持續洩漏，而在第四天發生當機。
即使修正了靜態程式碼分析工具所偵測到的所有缺陷，仍無法保證不會發生上述這類失效。因此，對「失效」的定義，必須同時套用在內部行為與外部行為上，甚至是在整合完成之後。
關鍵在於：內部失效必須在對外顯現之前就被偵測到。
結合靜態與動態分析的最佳實務
結合靜態與動態分析，是取得可行動結果、降低錯誤發生率、提升錯誤偵測能力，並打造更安全程式碼的最佳做法。兩者並無高下之分，而是如同精密瑞士錶中的齒輪，彼此協同運作、缺一不可。
以下是同時使用靜態與動態分析時的建議做法：
- 依照需求，搭配人工與自動化方式同時使用兩種分析技術。
- 確保程式碼具備良好可讀性與可重用性，方便其他開發人員維護。
- 在 SDLC 的正確階段使用正確的方法：開發早期用靜態分析，執行期環境用動態分析。
- 同時運用兩種分析方式，取得專案更全面的品質視角。
- 避免只依賴單一測試方法，這類小疏忽往往會造成重大問題。
結合靜態與動態分析，能協助團隊找出更多元、數量更多的可被利用攻擊途徑（threat vectors），全面提升系統的安全性。
本文由Parasoft提供