諸如基于模式的靜態(tài)代碼分析、運行時內(nèi)存監(jiān)控、單元測試和流分析等自動化技術可以一起用于查找嵌入式 C 應用程序中的錯誤。以下討論將使用 Parasoft C/C++test 演示這些技術，Parasoft C/C++test 是一種集成解決方案，用于自動化廣泛的最佳實踐，以提高 C 和 C++ 軟件開發(fā)團隊的生產(chǎn)力和軟件質(zhì)量。

示例傳感器應用

可以在 ARM Cortex-M3 板上運行的簡單傳感器應用程序的上下文中探索推薦的錯誤發(fā)現(xiàn)策略。應用程序已創(chuàng)建并上傳到開發(fā)板，但在運行時，它不會在 LCD 屏幕上呈現(xiàn)預期的輸出。

它不起作用，原因尚不清楚。在目標板上進行調(diào)試既費時又乏味，因為需要手動分析調(diào)試器結(jié)果以嘗試確定真正的問題?；蛘?，可以應用某些工具或技術來自動查明錯誤。

此時，兩個選項是使用調(diào)試器調(diào)試應用程序或應用自動化測試策略從代碼中剝離錯誤。如果應用自動化技術后應用程序仍然無法工作，調(diào)試器可以作為最后的手段。

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

應用了基于模式的靜態(tài)分析，而不是調(diào)試，它快速、易于使用并且?guī)缀蹩梢詰糜诿看未a 更改。通過執(zhí)行靜態(tài)分析確定了一個問題（參見圖 1）。

圖 1：靜態(tài)代碼分析識別 MISRA 編碼標準違規(guī)。

這違反了 MISRA 規(guī)則，即在布爾表達式中使用賦值運算符可能會有風險。目的不是使用賦值運算符，而是使用比較運算符。所以這個問題得到解決，程序重新運行。

由于一些輸出顯示在 LCD 上，因此有所改進。但是，應用程序因訪問沖突而崩潰。再一次，有一個選擇：使用調(diào)試器或繼續(xù)應用自動錯誤檢測技術。鑒于自動錯誤檢測在發(fā)現(xiàn)此類內(nèi)存損壞方面非常有效，因此執(zhí)行運行時內(nèi)存監(jiān)控是最佳選擇。

整個應用程序的運行時內(nèi)存監(jiān)控

可以通過應用適合在目標板上運行的輕量級儀器來執(zhí)行運行時內(nèi)存監(jiān)控。上傳并運行檢測的應用程序并下載結(jié)果后，會報告錯誤（參見圖 2）。

圖 2：運行時內(nèi)存監(jiān)控報告讀取超出范圍的數(shù)組。

這表明在第 48 行讀取了一個超出范圍的數(shù)組。顯然，msgIndex變量的值一定超出了數(shù)組的范圍。向上堆棧跟蹤顯示，這個具有超出范圍值的打印消息是由于在調(diào)用函數(shù)printMessage（）之前為其設置了不正確的條件而導致的。這可以通過放松if語句中的值范圍控制并去掉不必要的條件（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）;

}

現(xiàn)在，當重新運行應用程序時，不會報告內(nèi)存錯誤。應用程序上傳到板后，它似乎按預期工作。然而，一些擔憂仍然存在。

在執(zhí)行的代碼路徑中發(fā)現(xiàn)了一個內(nèi)存覆蓋實例，但這是否意味著未執(zhí)行的代碼中沒有內(nèi)存覆蓋？覆蓋分析表明，有些代碼根本沒有被執(zhí)行。reportSensorFailure（） 函數(shù)沒有被覆蓋，并且調(diào)用reportSensorFailure的mainLoop函數(shù)內(nèi)部的一個分支根本沒有被執(zhí)行（再次參見圖 2）。測試此代碼的一種方法是創(chuàng)建一個單元測試（用于mainLoop函數(shù)）和一個用戶存根（用于readSensor函數(shù)），以模擬在功能測試期間難以重現(xiàn)的條件。

帶有運行時內(nèi)存監(jiān)控的單元測試

創(chuàng)建一個測試用例骨架，然后用測試代碼填充。 此外，為readSensor函數(shù)添加了一個存根以模擬讀取錯誤。運行測試用例——只執(zhí)行這個以前未測試的功能——啟用運行時內(nèi)存監(jiān)控。結(jié)果顯示該函數(shù)現(xiàn)在已被覆蓋，但報告了新的錯誤（參見圖 3）。

圖 3：啟用運行時內(nèi)存監(jiān)控的單元測試會暴露內(nèi)存錯誤。

測試用例發(fā)現(xiàn)了更多與內(nèi)存相關的錯誤。調(diào)用失敗處理程序時，內(nèi)存初始化（空指針）存在明顯問題。進一步分析表明，reportSensorValue（）中混合了調(diào)用順序，因此finalize（）在printMessage（）被調(diào)用之前被調(diào)用，但finalize（）實際上釋放了printMessage（）使用的內(nèi)存。

void finalize（）

{

if （messages） {

free（messages［0］）;

free（messages［1］）;

free（messages［2］）;

}

free（messages）;

}

void printMessage（int msgIndex， int value）

{

const char* msg = messages［msgIndex］;

printf（“Value： %d， State： %s\n”， value， msg）;

fflush（stdout）;

}

void reportSensorFailure（）

{

finalize（）;

printMessage（ERROR_MSG， 0）;

}

這個順序是固定的，測試用例會重新運行一次。

這解決了報告的錯誤之一。下一步是解決報告的第二個問題：打印消息中的 AccessViolationException。這是因為這些表消息未初始化。為了解決這個問題，在打印消息之前調(diào)用initialize（）函數(shù)。修復后的功能如下：

void reportSensorFailure（）

{

initialize（）;

printMessage（ERROR， 0）;

finalize（）;

}

重新運行測試時，只報告一個任務：一個無效的單元測試用例，這并不是真正的錯誤。必須驗證結(jié)果才能將此測試轉(zhuǎn)換為回歸測試（參見圖 4）。

圖 4：必須為回歸測試配置測試。

接下來，再次運行整個應用程序。覆蓋率分析顯示幾乎整個應用程序都被覆蓋了，結(jié)果表明沒有出現(xiàn)內(nèi)存錯誤問題。

即使運行了整個應用程序并為未覆蓋的函數(shù)創(chuàng)建了單元測試，但仍有一些路徑未被覆蓋?？梢岳^續(xù)使用單元測試創(chuàng)建，但需要一些時間才能覆蓋應用程序中的所有路徑。相反，可以使用流量分析來模擬這些路徑。

流量分析

運行流分析以模擬通過系統(tǒng)的不同路徑，并檢查這些路徑中是否存在潛在問題。報告了幾個問題（參見圖 5）。

圖 5：流分析發(fā)現(xiàn)路徑中的幾個問題。

有一條潛在的路徑——一個未被覆蓋的路徑——在finalize（）函數(shù)中可以有一個雙重釋放。reportSensorValue（）函數(shù)調(diào)用finalize（），然后finalize （）調(diào)用free（）。此外，在mainLoop（）中再次調(diào)用finalize （） 。這可以通過使finalize（）更智能來解決：

void finalize（）

{

if （messages） {

free（messages［0］）;

free（messages［1］）;

free（messages［2］）;

free（messages）;

messages = 0;

}

}

然后再運行一次流量分析。僅報告了兩個問題（參見圖 6）。

圖 6：流量分析檢測到兩個剩余問題。

此處可能正在訪問索引為-1的表。這是因為積分索引最初設置為 -1，并且在調(diào)用printMessage（）之前，可能存在一條通過if語句未將此積分設置為正確值的路徑。運行時分析并沒有導致這條路徑，并且這條路徑可能永遠不會在現(xiàn)實生活中被采用。與實際運行時內(nèi)存監(jiān)控相比，這是流分析的主要弱點。流分析顯示潛在路徑，不一定是在實際應用程序執(zhí)行期間將采用的路徑。通過刪除不必要的條件（value 》= 0）可以輕松修復此潛在錯誤。

void handleSensorValue（int value）

{

initialize（）;

int index = -1;

if （value 《= 10） {

index = VALUE_LOW;

} else {

index = VALUE_HIGH;

}

printMessage（index， value）;

}

報告的最終錯誤以類似的方式修復。現(xiàn)在，重新運行流分析時，不會報告任何問題。

回歸測試

為確保一切正常，重新運行整個分析。首先，應用程序在運行時內(nèi)存監(jiān)控下運行，一切似乎都很好。然后使用內(nèi)存監(jiān)控運行單元測試并報告一個任務（參見圖 7）。

圖 7：單元測試發(fā)現(xiàn)回歸失敗。

單元測試檢測到reportSensorFailure（）函數(shù)的行為發(fā)生了變化。這是由finalize（）中的修改引起的，這是為了糾正先前報告的問題之一而進行的更改。此任務引起對更改的注意，并指示必須審查測試用例。然后要么更正代碼，要么更新測試用例，以表明這個新行為實際上是預期的行為?？戳讼麓a，很明顯后者為真，并且更新了斷言的條件。

void sensor_tests_test_reportSensorFailure（）

{

{

messages = 0 ;

}

{

reportSensorFailure（）;

CPPTEST_ASSERT（0 == （ messages ））;

}

}

作為最后的健全性檢查，整個應用程序獨立運行，在集成開發(fā)環(huán)境中構(gòu)建它，無需任何運行時內(nèi)存監(jiān)控。結(jié)果證實它按預期工作。

補充工具

所有應用的測試方法——基于模式的靜態(tài)代碼分析、內(nèi)存分析、單元測試、流分析和回歸測試——不相互競爭，而是相互補充。一起使用，它們提供了一個非常強大的工具，可以為嵌入式 C 軟件提供無與倫比的自動錯誤檢測水平。

作者：Parasoft SA ，Miros?aw Zieli nski

審核編輯：郭婷