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

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

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

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

指標分析

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

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

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

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

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

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

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

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

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

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

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

指標分析

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

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

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

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

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

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

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

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

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

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

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

作者：Wayne Ariola，Adam Trujillo，Arthur Hicken

審核編輯：郭婷