查找嵌入式C語言程序/軟件中的缺陷的多種技術

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

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

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

情景簡介

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

假設我們已經創(chuàng)建了該應用系統，但是當我們將程序上載到系統目標板上并試圖運行該程序時，我們沒有在LCD屏上看到所預期的輸出。

我們尚不明確系統不能正常工作的原因，因此我們設法對系統進行調試，但是在目標板上進行調試是一件耗時而且煩人的事。因為我們不得不手動分析調試器的結果并試圖人工判斷出問題的真正原因。或者我們使用一些被證實能自動定位出錯誤的工具或技術來幫助我們減輕負擔。


從這一點而言，我們要么期待使用調試器來調試程序能夠帶來好運，要么我們嘗試使用一種自動化的測試策略來查找代碼中所存在的錯誤。如果自動化技術仍然沒有幫助我們查找到錯誤，那么我們不得不回到使用調試器作為最后的辦法。

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

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

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

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

整個程序的運行時內存監(jiān)測

為了進行運行時內存監(jiān)測，我們使用 C++test 來插裝應用程序。這樣的插裝是輕量級的，所以經過插裝后的程序適合在目標板上運行。當我們把程序上載到目標板上并運行經過插裝的程序后，我們將結果下載到PC上，如下的錯誤將被報告出來：

該結果指出在第48行代碼處產生了一次讀取數組越界的錯誤。顯然，msgIndex變量的值肯定超過了數組的范圍。如果我們隨著堆棧追蹤上一級的原因，我們將發(fā)現此處的打印信息所指示的值的確超出了數組的范圍（因為在調用printMessage()函數前我們給出了一個錯誤的條件）。我們可以刪除掉這個不必要的條件（value = 20）以修改這個錯誤。

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);
}