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

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

積分時靜態(tài)分析

持續(xù)集成時間 （CI） 靜態(tài)分析

指標分析

編輯時靜態(tài)分析

運行時靜態(tài)分析

積分時靜態(tài)分析

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

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

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

持續(xù)集成時間 （CI） 靜態(tài)分析

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

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

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

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

指標分析

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

圖 1： Parasoft 靜態(tài)分析指標報告

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

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

編輯時靜態(tài)分析

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

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

運行時靜態(tài)分析

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

關于靜態(tài)分析和 QA 的最后說明

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

作者：Wayne Ariola，Adam Trujillo，Arthur Hicken

審核編輯：郭婷