嵌入式軟件無處不在，并在各種設備中提供關鍵功能，從最新的智能手機和游戲小工具到救生醫療設備。創建嵌入式軟件的工程組織明白，確保代碼質量是一個關鍵的差異化因素和競爭優勢。與其他測試和驗證方法一起，許多公司利用代碼測試和現代靜態分析的優勢在開發早期識別缺陷。在過去幾年中，嵌入式市場研究公司 VDC Research 的各種報告表明，采用靜態分析作為關鍵測試自動化工具的公司增長強勁。現代靜態分析可以說是應對確保復雜軟件質量挑戰的最具成本效益、自動化和可重復的方法。

推動這種增長的一個重要原因是，用于識別關鍵缺陷（如內存損壞、資源泄漏、空指針取消引用和無效內存訪問）的技術已經成熟到可以發現大量難以發現的遍歷函數的缺陷的程度現在可以準確地完成文件邊界，從而導致非常少的誤報。然而，真正的創新在于為每個已識別的缺陷提供上下文信息。開發人員需要知道缺陷存在的原因、會產生什么影響以及需要修復的地方。

需要修復的問題的答案并不像知道文件名和行號那么簡單。用于版本控制、代碼重用和代碼組件重用以提高開發效率的代碼分支和合并允許缺陷進入多個版本和產品。

考慮一個軟件團隊的情況，該團隊擁有多個產品的不同版本的分支。由于代碼復制，其中一個分支中的錯誤可能存在于一個或多個其他分支中。在另一種情況下，考慮創建框架以支持智能手機應用程序的團隊。因為他們可能將框架移植到 Windows、Android 或 iPhone 等各種平臺上，所以靜態分析結果清楚地表明已識別的缺陷是僅存在于一個地方還是存在于多個平臺上，這一點至關重要。同樣，當軟件是通過從多個來源聚合創建的時，如果在各種產品中使用特定組件，那將是一場噩夢，因為一個第三方組件的缺陷最終可能會影響包含它的所有不同產品。

不同版本操作系統的多個分支

想象一個負責為移動智能手機創建新操作系統 （OS） 的軟件開發團隊。由于必須支持多個手機供應商 （OEM），因此源代碼控制管理系統中的每個供應商都需要一個開發分支。此外，每個供應商通常都有針對不同版本和產品代的多個分支。畫面開始變得非常復雜。

對代碼的每個分支執行的靜態分析會生成一個缺陷列表。但是，根據引入缺陷的時間，它可能存在于所有版本或子集中。當孤立地查看單個分支中的單個缺陷時，開發人員面臨的挑戰是他們無法在不知道缺陷存在于何處的情況下評估缺陷的嚴重性。不限于單個版本或一個 OEM 客戶端的缺陷將是嚴重的，修復它需要優先于其他任何事情。此外，編寫代碼來修復缺陷的開發人員需要準確地知道需要簽入源代碼控制管理系統中的哪些分支。

圖 1：由于代碼分支和合并導致的重復缺陷。

適用于多個平臺的單一框架

在分支的另一面，通常需要編寫設計為在多個平臺上運行的代碼。諸如移動應用程序框架之類的軟件組件通常被構建為在各種類型的移動電話平臺上運行。對于嵌入式設備，一個常見的要求是構建相同代碼庫的 32 位和 64 位版本。我們舉一個簡單的例子：

gcc --m32 -c foo.c

// 32 位編譯。包含空指針取消引用缺陷。

gcc -c foo.c

// 64 位編譯。包含相同的空指針取消引用缺陷。

在 32 位和 64 位二進制文件中觸發的foo.c中的缺陷將被檢測并報告為單個缺陷。但是，由于源代碼相同，因此復雜的分析不會將其報告為重復缺陷。在失去開發人員對靜態分析解決方案的信任方面，重復與誤報一樣有害。

共享通用代碼組件

在最后一個示例中，考慮一個為一系列網絡交換機開發平臺軟件的團隊。由于平臺軟件提供的功能必須在所有產品中實現，因此該代碼組件將被共享（參見圖 2）。對于在這個團隊工作的開發人員來說，靜態分析報告的缺陷嚴重性的最佳評估不僅是它對一個交換機產品的影響，還包括使用該平臺軟件組件的所有產品的信息。

圖 2：單個軟件組件在多個產品中重復使用。

產品通常是通過組合許多這樣的共享組件來創建的。每個組件不僅是一個項目本身，而且是使用它的各種其他項目的一部分。分析結果需要確定此共享組件中的缺陷對使用它的各個項目有影響。

消除代碼測試中的猜測

采用靜態分析等現代開發人員測試方法是嵌入式軟件行業的一個積極趨勢。該技術已經成熟到可以成為軟件工程師武器庫中強大武器的程度。無需創建復雜的測試用例和測試基礎設施，靜態分析就可以在編寫和編譯代碼時自動發現關鍵缺陷。但是，要使靜態分析成為開發人員最有價值的工具，分析必須提供諸如“此缺陷的影響是什么？”之類的問題的答案。和“我需要在哪里檢查修復？” 幫助確定修復已識別缺陷的優先級，并消除猜測以確保軟件盡可能無錯誤。

審核編輯：郭婷