基于模式的靜態(tài)代碼分析、運(yùn)行時(shí)內(nèi)存監(jiān)測(cè)、單元測(cè)試以及數(shù)據(jù)流分析等軟件驗(yàn)證技術(shù)是查找嵌入式C語言程序/軟件缺陷行之有效的方法。上述技術(shù)中的每一種都能查找出某一類特定的錯(cuò)誤。即便如此，如果用戶僅采用上述技術(shù)中的一種或者幾種來進(jìn)行驗(yàn)證，這樣的驗(yàn)證方法很有可能會(huì)漏過對(duì)程序中的一些缺陷的檢查。解決此類問題的一種安全和有效的策略就是同時(shí)使用上述軟件驗(yàn)證中的所有互補(bǔ)技術(shù)。這樣就能建立起一個(gè)牢固的框架來幫助用戶檢查出可能會(huì)避開某種特定技術(shù)的缺陷。與此同時(shí)，用戶也自然地建立起一個(gè)能檢測(cè)出關(guān)鍵并且難以查找的功能性錯(cuò)誤的環(huán)境。

本文將詳盡闡述基于模式的靜態(tài)代碼分析、運(yùn)行時(shí)內(nèi)存錯(cuò)誤檢測(cè)、單元測(cè)試以及數(shù)據(jù)流分析等自動(dòng)化技術(shù)共同使用時(shí)是如何查找出嵌入式C語言程序/軟件中的缺陷的。本文中將以Parasoft C++test為例來演示上述各項(xiàng)技術(shù)。C++teST是一個(gè)經(jīng)廣泛的最佳實(shí)踐證明能提升軟件開發(fā)團(tuán)隊(duì)開發(fā)效率以及軟件質(zhì)量的自動(dòng)化集成解決方案。

當(dāng)讀者在閱讀本文以及任何時(shí)候思考查找到的缺陷時(shí)，關(guān)注文中的截圖是很重要的。自動(dòng)化檢測(cè)例如內(nèi)存崩潰和死鎖的缺陷，毫無疑問對(duì)任何開發(fā)團(tuán)隊(duì)都是一項(xiàng)必不可少的任務(wù)。盡管如此，最致命的缺陷卻是功能性錯(cuò)誤，這往往是難以自動(dòng)發(fā)現(xiàn)的。在本文的結(jié)論部分我們將簡(jiǎn)要地討論一下查找這些缺陷的技術(shù)。

情景簡(jiǎn)介

為了給出一個(gè)具體的示例，我們將就一個(gè)我們最近遇到的案例來介紹以及演示我們所推薦的缺陷查找策略：一個(gè)運(yùn)行在ARM 板上的簡(jiǎn)單傳感器應(yīng)用程序。

假設(shè)我們已經(jīng)創(chuàng)建了該應(yīng)用系統(tǒng)，但是當(dāng)我們將程序上載到系統(tǒng)目標(biāo)板上并試圖運(yùn)行該程序時(shí)，我們沒有在LCD屏上看到所預(yù)期的輸出。

我們尚不明確系統(tǒng)不能正常工作的原因，因此我們?cè)O(shè)法對(duì)系統(tǒng)進(jìn)行調(diào)試，但是在目標(biāo)板上進(jìn)行調(diào)試是一件耗時(shí)而且煩人的事。因?yàn)槲覀儾坏貌皇謩?dòng)分析調(diào)試器的結(jié)果并試圖人工判斷出問題的真正原因。或者我們使用一些被證實(shí)能自動(dòng)定位出錯(cuò)誤的工具或技術(shù)來幫助我們減輕負(fù)擔(dān)。

基于模式的靜態(tài)代碼分析

這里，我們假設(shè)僅在絕對(duì)必要的情況下才使用調(diào)試器進(jìn)行調(diào)試，因此我們從運(yùn)行基于模式的靜態(tài)代碼分析開始。它將查找到如下圖所示的問題：

這是違反了 MISRA 的一個(gè)規(guī)則，此違規(guī)說明該處的賦值運(yùn)算符存在一些可疑情況。的確，編程者此處的本意是使用比較運(yùn)算符而不是賦值運(yùn)算符。因此我們將此處檢測(cè)到的沖突修改掉，并重新運(yùn)行程序。

我們發(fā)現(xiàn)有了一些改善：一些輸出被顯示在了LCD屏上了。但是，由于一次訪問違規(guī)，程序崩潰掉了。因此我們需要再次地做出選擇。我們是應(yīng)該使用調(diào)試器還是繼續(xù)使用自動(dòng)化的錯(cuò)誤檢測(cè)技術(shù)。由于經(jīng)驗(yàn)告訴我們自動(dòng)化錯(cuò)誤檢測(cè)技術(shù)能非常高效地檢查出我們當(dāng)前程序所遇到的內(nèi)存崩潰這類問題，因此我們決定使用運(yùn)行時(shí)內(nèi)存監(jiān)測(cè)來查找問題。

整個(gè)程序的運(yùn)行時(shí)內(nèi)存監(jiān)測(cè)

為了進(jìn)行運(yùn)行時(shí)內(nèi)存監(jiān)測(cè)，我們使用 C++test 來插裝應(yīng)用程序。這樣的插裝是輕量級(jí)的，所以經(jīng)過插裝后的程序適合在目標(biāo)板上運(yùn)行。當(dāng)我們把程序上載到目標(biāo)板上并運(yùn)行經(jīng)過插裝的程序后，我們將結(jié)果下載到PC上，如下的錯(cuò)誤將被報(bào)告出來：

該結(jié)果指出在第48行代碼處產(chǎn)生了一次讀取數(shù)組越界的錯(cuò)誤。顯然，msgIndex變量的值肯定超過了數(shù)組的范圍。如果我們隨著堆棧追蹤上一級(jí)的原因，我們將發(fā)現(xiàn)此處的打印信息所指示的值的確超出了數(shù)組的范圍（因?yàn)樵谡{(diào)用printMessage()函數(shù)前我們給出了一個(gè)錯(cuò)誤的條件）。我們可以刪除掉這個(gè)不必要的條件（value <= 20）以修改這個(gè)錯(cuò)誤。

void handleSensorValue(int value)
{
initialize();
int index = -1;
if (value >= 0 && value <= 10) {
index = VALUE_LOW;
} else if ((value > 10) && (value <= 20)) {
index = VALUE_HIGH;
}
printMessage(index, value);
}

然后我們重新運(yùn)行程序，將不會(huì)再報(bào)告任何內(nèi)存錯(cuò)誤。當(dāng)我們把程序上載到目標(biāo)板上時(shí)，它似乎如我們預(yù)期那么在工作了。盡管如此，我們?nèi)匀挥幸恍?dān)心。

我們僅查找到我們所執(zhí)行的代碼路徑中的一個(gè)內(nèi)存寫溢出實(shí)例，我們憑什么能夠斷定我們尚未執(zhí)行到的代碼就不會(huì)有內(nèi)存寫溢出錯(cuò)誤了呢？如果我們檢查覆蓋率分析，我們就會(huì)發(fā)現(xiàn)reportSensorFailure()這個(gè)函數(shù)從未被執(zhí)行到。我們有必要對(duì)這個(gè)函數(shù)進(jìn)行測(cè)試，但是具體如何進(jìn)行呢？建立一個(gè)調(diào)用該函數(shù)的單元測(cè)試用例就是一個(gè)不錯(cuò)的辦法。

在單元測(cè)試中使用運(yùn)行時(shí)內(nèi)存監(jiān)測(cè):我們使用C++test的測(cè)試用例向?qū)韯?chuàng)建一個(gè)測(cè)試用例的框架，并向其中添加一些測(cè)試代碼。然后運(yùn)行該測(cè)試用例——以檢查上面提到的未經(jīng)測(cè)試的函數(shù)，同時(shí)打開運(yùn)行時(shí)內(nèi)存監(jiān)測(cè)功能。使用C++teST，全過程大約只需要數(shù)秒鐘。

結(jié)果標(biāo)明該函數(shù)已經(jīng)被覆蓋到了，但同時(shí)也查找到了新的錯(cuò)誤：