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

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

finalize()函數(shù)先于printMessage()函數(shù)被調(diào)用，但是finalize()函數(shù)中釋放了printMessage()函數(shù)需要使用的內(nèi)存。

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

將函數(shù)調(diào)用順序進行修改后，我們重新運行程序。

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

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

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

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

這樣就結束了嗎？其實不然。雖然我們運行了整個程序并為未覆蓋到的函數(shù)創(chuàng)建了單元測試用例，但還是有一些路徑是沒有被覆蓋到的。我們?nèi)匀豢梢岳^續(xù)創(chuàng)建單元測試用例，但是若指望通過這樣的方法來覆蓋程序中的所有路徑將耗費相當長的時間?；蛘呶覀兪褂昧硗獾姆椒?，使用數(shù)據(jù)流分析來對這些路徑進行模擬。

數(shù)據(jù)流分析

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

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

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

現(xiàn)在我們再次運行數(shù)據(jù)流分析，得到的結果將只有兩個問題：

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