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

我們的測試用例查找到了更多的內存相關錯誤。很顯然，當失敗處理函數被調用時，我們的內存初始化存在問題（空指針）。通過更進一步的分析，我們發(fā)現在reportSensorValue()函數中存在函數調用順序錯誤。

finalize()函數先于printMessage()函數被調用，但是finalize()函數中釋放了printMessage()函數需要使用的內存。

void finalize()
{
if (messages) {
free(messages[0]);
free(messages[1]);
free(messages[2]);
}
free(messages);
}

將函數調用順序進行修改后，我們重新運行程序。

這樣我們就解決了上面報告中的第一個錯誤?，F在我們再來分析報告中的第二個錯誤：即打印信息中的AccessViolatiONException。產生這個錯誤的原因是相應的消息列表未經初始化。為了解決該問題，我們在打印該信息前調用一次initialize()函數來對其進行初始化。經修改后的函數如下所示：

void reportSensorFailure()
{
initialize();
printMessage(ERROR, 0);
finalize();
}

當我們再次運行該測試用例時，僅有一個任務被報告出來：未經驗證的單元測試用例（an unvalidated unit test case），這其實并不算一條錯誤。我們只需對輸出進行一下驗證，以將該測試用例轉換為回歸測試。通過創(chuàng)建合適的斷言，C++test會自動為我們完成這些步驟。

接下來我們再次運行整個程序。覆蓋率分析告訴我們幾乎整個程序都已經被覆蓋到了，并且沒有發(fā)現任何內存錯誤。

這樣就結束了嗎？其實不然。雖然我們運行了整個程序并為未覆蓋到的函數創(chuàng)建了單元測試用例，但還是有一些路徑是沒有被覆蓋到的。我們仍然可以繼續(xù)創(chuàng)建單元測試用例，但是若指望通過這樣的方法來覆蓋程序中的所有路徑將耗費相當長的時間?；蛘呶覀兪褂昧硗獾姆椒ǎ褂脭祿鞣治鰜韺@些路徑進行模擬。

數據流分析

我們使用C++test的BugDetective來進行數據流分析，BugDetective能模擬系統中的不同路徑并檢查這些路徑中是否存在潛在的問題。進行數據流分析后，我們得到如下結果：

仔細分析報告的結果，我們發(fā)現程序中存在一條未被覆蓋到的潛在路徑可能會造成在finalize()函數中出現兩次free的操作。在程序中，reportSensorValue()函數調用了finalize()函數，然后finalize()函數調用了free()。同時，finalize()函數還會被mainLoop()函數調用。我們可以修改finalize()函數以使其更加智能化，從而修復這個問題，修改后的代碼如下：

void finalize()
{
if (messages) {
free(messages[0]);
free(messages[1]);
free(messages[2]);
free(messages);
messages = 0;
}
}

現在我們再次運行數據流分析，得到的結果將只有兩個問題：

這里我們可能使用了-1作為索引來訪問了數組。這是由于整型變量index被設置的初始值為-1，并且存在一條可能通過if語句的路徑在未將該整型變量正確的進行初始化之前便調用了printMessage()函數。運行時分析未檢查到這樣的一條路徑，并且該路徑很有可能在真實世界中永遠不可能被執(zhí)行到。這就是靜態(tài)數據流分析相對于運真實運行時內存監(jiān)測最主要的不足：數據流分析能檢查出潛在的路徑，這些路徑可能包含在程序實際執(zhí)行過程中不會執(zhí)行到或不存在的路徑。盡管如此，為了做到有備無患，我們刪除了上述的不必要的條件（value>=0）以修改這個潛在的錯誤。