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

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

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

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

不同版本操作系統(tǒng)的多個分支

想象一個負(fù)責(zé)為移動智能手機(jī)創(chuàng)建新操作系統(tǒng) （OS） 的軟件開發(fā)團(tuán)隊。由于必須支持多個手機(jī)供應(yīng)商 （OEM），因此源代碼控制管理系統(tǒng)中的每個供應(yīng)商都需要一個開發(fā)分支。此外，每個供應(yīng)商通常都有針對不同版本和產(chǎn)品代的多個分支。畫面開始變得非常復(fù)雜。

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

圖 1：由于代碼分支和合并導(dǎo)致的重復(fù)缺陷。

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

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

gcc --m32 -c foo.c

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

gcc -c foo.c

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

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

共享通用代碼組件

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

圖 2：單個軟件組件在多個產(chǎn)品中重復(fù)使用。

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

消除代碼測試中的猜測

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

審核編輯：郭婷