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

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

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

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

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

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

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

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

適用于多個(gè)平臺(tái)的單一框架

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

gcc --m32 -c foo.c

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

gcc -c foo.c

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

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

共享通用代碼組件

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

圖 2：?jiǎn)蝹€(gè)軟件組件在多個(gè)產(chǎn)品中重復(fù)使用。

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

消除代碼測(cè)試中的猜測(cè)

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

審核編輯：郭婷