一般來說，最佳實踐是平臺中立的——這就是為什么它們被稱為“最佳實踐”。盡管嵌入式開發特有的微妙之處，有已知的標準來確保質量，無論平臺如何。例如，避免內存泄漏應該是通用的。此外，靜態分析和軟件之間的關系不一定由應用程序定義：它由設備的用途定義。也就是說，運行靜態分析是嵌入式軟件開發特別重要的最佳實踐。

傳統上，嵌入式軟件在發布后訪問起來非常昂貴且痛苦。出于這個原因，大多數質量或驗證活動都集中在消除修補或重構嵌入式代碼的需要上。發布后修復錯誤不僅對品牌而且對利潤構成最大風險。在某些行業，特別是在安全關鍵領域，與軟件缺陷相關的后果非常嚴重，以至于必須完美地執行質量和驗證任務。嵌入到胰島素泵、武器控制系統、汽車制動系統等關鍵設備中的軟件需要使用全方位靜態分析功能的預防策略；否則后果可能包括代價高昂的訴訟、C 級辭職，甚至喪生。這與敏捷相反，持續開發，Web 驅動的軟件應用程序，例如智能手機、電視等，對于這些應用程序而言，預防策略不太重要。為此，在軟件開發范圍的預防策略方面進行了以下討論，檢查了各種靜態分析實現：

積分時靜態分析

持續集成時間 （CI） 靜態分析

指標分析

編輯時靜態分析

運行時靜態分析

積分時靜態分析

在集成期間運行靜態分析以檢測容易實現的目標和嚴重錯誤是實施預防策略的良好起點。集成時靜態分析在不實際執行代碼的情況下模擬可行的應用程序路徑，這對于無法進行運行時分析的系統非常有用。靜態分析可以跨多個函數和文件進行測試，并捕獲常見的內存問題，例如未初始化的內存、溢出、空指針等。

當組織開始在集成期間進行測試時，靜態分析在開發策略方面有幾個目的。首先，工程師可以查看測試結果并確定它們對于特定應用的重要性。靜態分析可能會發現可能對軟件安全性、可靠性或性能產生嚴重影響的潛在缺陷。另一方面，它可能會返回企業可能不關心的東西。例如，企業可能并不關心游戲控制臺中的缺陷會導致軟件在發生不太可能的操作序列時崩潰。用戶可以簡單地重新啟動并繼續享受他們的系統。然而，在其他情況下解決同類問題可能對于防止災難性后果至關重要。

靜態分析還可以幫助軟件工程師發現在風險評估階段很難想到的潛在缺陷。工程師可以對潛在缺陷進行分類，以改進未來的風險評估迭代。

持續集成時間 （CI） 靜態分析

在運行集成時靜態分析之后，軟件工程師應該對代碼中潛在的系統問題有更強烈的認識。下一步是運行 CI 靜態分析，以執行規劃階段概述的編碼策略。這可以防止在集成時間分析期間發現的缺陷類型。

對于靜態分析中發現的每個問題，在代碼的其他地方至少還有 10 個完全相同的東西。靜態分析是同時解決所有同類違規行為的理想工具。這與在代碼中追逐每一條可能的路徑相反。找到系統性問題，創造一個bug無法生存的環境要好得多。

當我們談論靜態分析時，在很多情況下我們指的是反模式分析。積極的模式是應該在代碼中的東西。例如，要求工程師在聲明函數指針時使用typedef的策略是正模式靜態分析規則。這與例如在與標準 C 庫 交互時禁止使用字符串類中的data（）成員函數的策略形成對比。

執行兩種類型（正模式和反模式）的靜態分析很重要，但值得一提的是這種區別，因為如果組織花時間基于正模式構建編碼策略，這可以確保軟件工程師準確地構建代碼它應該符合業務目標或合規性要求。

指標分析

指標分析是一種靜態分析實現，它評估代碼特征并提供有關代碼的洞察力，可以幫助軟件工程師識別弱點（圖 1）。它是一種關鍵傳感器，可以突出顯示可能容易出現邏輯錯誤的應用程序區域。指標分析是一個基本的基線測量，應該觸發進一步的分析，例如代碼審查或其他一些補救活動。

圖 1： Parasoft 靜態分析指標報告

指標分析最好盡早使用，因為它可能會影響軟件工程師編寫代碼的方式。避免嘗試被動地或在 QA 階段實施指標分析。指標分析的目標不僅僅是檢測潛在的缺陷；它以允許工程師遵循可持續編碼軌跡的方式檢測它們。對潛在缺陷熱點運行指標分析，糾正任何違規行為，并實施基于模式的分析規則以防止將來發生。

任何與潛在問題相關的指標都是公平的游戲。例如，一家醫療設備公司可能會使用度量分析來衡量圈復雜度，因為高分表明設備在正常操作期間有太多決策點需要處理。當有 10 個分支要削減時，知道復雜性分數超過了編碼策略中設置的閾值，而不是在 QA 階段發現，這將有助于保持項目按時和按預算進行。例如，組織可能想要測量公共變量，因為高數字可能與代碼中過多的依賴關系相關。每個組織都需要決定哪些指標可以與代碼中可能的缺陷相關聯。

編輯時靜態分析

靜態分析的最佳點是開發人員在編輯器中工作時。在編輯時運行靜態分析有幾個目的。首先，它將軟件工程師指出潛在的問題。其次，它通過確保系統地修復任何問題來實施風險評估策略。

但是什么時候應該實施靜態分析呢？我們已經討論了為什么太遲實施靜態分析是一個問題。但是，它也可能實施得太早，因為靜態分析必須有足夠的上下文才能提供有意義的信息。對字符、行甚至語句運行靜態分析會產生太多噪音而無用。實施積極的設計模式可確保新代碼在編寫時按預期構建。在編輯時運行靜態分析是在開發團隊中促進正確行為的一種有效方式，因為反饋是快速的并且是在正在編寫的代碼的上下文中。利用這種類型的分析可以提高代碼審查的效率，因為工程師應該能夠立即糾正基于策略的錯誤。

運行時靜態分析

一些靜態分析模式可以在運行時檢測缺陷。如果嵌入式目標可以容納開銷，則組織應執行運行時靜態分析以完善其預防策略。運行時靜態分析在代碼實際運行時檢測錯誤，這使軟件工程師能夠使用真實數據測試真實路徑。

關于靜態分析和 QA 的最后說明

在理想的預防策略中，QA 運行靜態分析時發現的錯誤應該已經知道并確定為可接受的。這是因為軟件工程師應該已經針對設計模式進行了測試和調整以強制執行編碼策略。此階段的違規意味著流程存在問題，例如不正確的靜態分析規則。在這些情況下，QA 需要將代碼發送回開發人員，以便他們可以找到缺陷的系統原因并實施規則以防止將來發生。從這個角度來看，靜態分析是一個比錯誤查找器更好的質量門。

作者：Wayne Ariola，Adam Trujillo，Arthur Hicken

審核編輯：郭婷