電子發燒友App
諸如基于模式的靜態代碼分析、運行時內存監控、單元測試和流分析等自動化技術可以一起用于查找嵌入式 C 應用程序中的錯誤。以下討論將使用 Parasoft C/C++test 演示這些技術，Parasoft C/C++test 是一種集成解決方案，用于自動化廣泛的最佳實踐，以提高 C 和 C++ 軟件開發團隊的生產力和軟件質量。
示例傳感器應用
可以在 ARM Cortex-M3 板上運行的簡單傳感器應用程序的上下文中探索推薦的錯誤發現策略。應用程序已創建并上傳到開發板，但在運行時，它不會在 LCD 屏幕上呈現預期的輸出。
它不起作用，原因尚不清楚。在目標板上進行調試既費時又乏味，因為需要手動分析調試器結果以嘗試確定真正的問題?；蛘?，可以應用某些工具或技術來自動查明錯誤。
此時，兩個選項是使用調試器調試應用程序或應用自動化測試策略從代碼中剝離錯誤。如果應用自動化技術后應用程序仍然無法工作，調試器可以作為最后的手段。
基于模式的靜態代碼分析
應用了基于模式的靜態分析，而不是調試，它快速、易于使用并且幾乎可以應用于每次代碼 更改。通過執行靜態分析確定了一個問題（參見圖 1）。
圖 1：靜態代碼分析識別 MISRA 編碼標準違規。
這違反了 MISRA 規則，即在布爾表達式中使用賦值運算符可能會有風險。目的不是使用賦值運算符，而是使用比較運算符。所以這個問題得到解決，程序重新運行。
由于一些輸出顯示在 LCD 上，因此有所改進。但是，應用程序因訪問沖突而崩潰。再一次，有一個選擇：使用調試器或繼續應用自動錯誤檢測技術。鑒于自動錯誤檢測在發現此類內存損壞方面非常有效，因此執行運行時內存監控是最佳選擇。
整個應用程序的運行時內存監控
可以通過應用適合在目標板上運行的輕量級儀器來執行運行時內存監控。上傳并運行檢測的應用程序并下載結果后，會報告錯誤（參見圖 2）。
圖 2：運行時內存監控報告讀取超出范圍的數組。
這表明在第 48 行讀取了一個超出范圍的數組。顯然，msgIndex變量的值一定超出了數組的范圍。向上堆棧跟蹤顯示，這個具有超出范圍值的打印消息是由于在調用函數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）;
}
現在，當重新運行應用程序時，不會報告內存錯誤。應用程序上傳到板后，它似乎按預期工作。然而，一些擔憂仍然存在。
在執行的代碼路徑中發現了一個內存覆蓋實例，但這是否意味著未執行的代碼中沒有內存覆蓋？覆蓋分析表明，有些代碼根本沒有被執行。reportSensorFailure（） 函數沒有被覆蓋，并且調用reportSensorFailure的mainLoop函數內部的一個分支根本沒有被執行（再次參見圖 2）。測試此代碼的一種方法是創建一個單元測試（用于mainLoop函數）和一個用戶存根（用于readSensor函數），以模擬在功能測試期間難以重現的條件。
帶有運行時內存監控的單元測試
創建一個測試用例骨架，然后用測試代碼填充。 此外，為readSensor函數添加了一個存根以模擬讀取錯誤。運行測試用例——只執行這個以前未測試的功能——啟用運行時內存監控。結果顯示該函數現在已被覆蓋，但報告了新的錯誤（參見圖 3）。
圖 3：啟用運行時內存監控的單元測試會暴露內存錯誤。
測試用例發現了更多與內存相關的錯誤。調用失敗處理程序時，內存初始化（空指針）存在明顯問題。進一步分析表明，reportSensorValue（）中混合了調用順序，因此finalize（）在printMessage（）被調用之前被調用，但finalize（）實際上釋放了printMessage（）使用的內存。
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。這是因為這些表消息未初始化。為了解決這個問題，在打印消息之前調用initialize（）函數。修復后的功能如下：
void reportSensorFailure（）
{
initialize（）;
printMessage（ERROR， 0）;
finalize（）;
}
重新運行測試時，只報告一個任務：一個無效的單元測試用例，這并不是真正的錯誤。必須驗證結果才能將此測試轉換為回歸測試（參見圖 4）。
圖 4：必須為回歸測試配置測試。
接下來，再次運行整個應用程序。覆蓋率分析顯示幾乎整個應用程序都被覆蓋了，結果表明沒有出現內存錯誤問題。
即使運行了整個應用程序并為未覆蓋的函數創建了單元測試，但仍有一些路徑未被覆蓋?？梢岳^續使用單元測試創建，但需要一些時間才能覆蓋應用程序中的所有路徑。相反，可以使用流量分析來模擬這些路徑。
流量分析
運行流分析以模擬通過系統的不同路徑，并檢查這些路徑中是否存在潛在問題。報告了幾個問題（參見圖 5）。
圖 5：流分析發現路徑中的幾個問題。
有一條潛在的路徑——一個未被覆蓋的路徑——在finalize（）函數中可以有一個雙重釋放。reportSensorValue（）函數調用finalize（），然后finalize （）調用free（）。此外，在mainLoop（）中再次調用finalize （） 。這可以通過使finalize（）更智能來解決：
void finalize（）
{
if （messages） {
free（messages［0］）;
free（messages［1］）;
free（messages［2］）;
free（messages）;
messages = 0;
}
}
然后再運行一次流量分析。僅報告了兩個問題（參見圖 6）。
圖 6：流量分析檢測到兩個剩余問題。
此處可能正在訪問索引為-1的表。這是因為積分索引最初設置為 -1，并且在調用printMessage（）之前，可能存在一條通過if語句未將此積分設置為正確值的路徑。運行時分析并沒有導致這條路徑，并且這條路徑可能永遠不會在現實生活中被采用。與實際運行時內存監控相比，這是流分析的主要弱點。流分析顯示潛在路徑，不一定是在實際應用程序執行期間將采用的路徑。通過刪除不必要的條件（value 》= 0）可以輕松修復此潛在錯誤。
void handleSensorValue（int value）
{
initialize（）;
int index = -1;
if （value 《= 10） {
index = VALUE_LOW;
} else {
index = VALUE_HIGH;
}
printMessage（index， value）;
}
報告的最終錯誤以類似的方式修復?，F在，重新運行流分析時，不會報告任何問題。
回歸測試
為確保一切正常，重新運行整個分析。首先，應用程序在運行時內存監控下運行，一切似乎都很好。然后使用內存監控運行單元測試并報告一個任務（參見圖 7）。
圖 7：單元測試發現回歸失敗。
單元測試檢測到reportSensorFailure（）函數的行為發生了變化。這是由finalize（）中的修改引起的，這是為了糾正先前報告的問題之一而進行的更改。此任務引起對更改的注意，并指示必須審查測試用例。然后要么更正代碼，要么更新測試用例，以表明這個新行為實際上是預期的行為?？戳讼麓a，很明顯后者為真，并且更新了斷言的條件。
void sensor_tests_test_reportSensorFailure（）
{
{
messages = 0 ;
}
{
reportSensorFailure（）;
CPPTEST_ASSERT（0 == （ messages ））;
}
}
作為最后的健全性檢查，整個應用程序自行運行，在集成開發環境中構建它，無需任何運行時內存監控。結果證實它按預期工作。
補充工具
所有應用的測試方法——基于模式的靜態代碼分析、內存分析、單元測試、流分析和回歸測試——不相互競爭，而是相互補充。一起使用，它們提供了一個非常強大的工具，可以為嵌入式 C 軟件提供無與倫比的自動錯誤檢測水平。
作者：Marek Kucharski，Miros?aw Zieli nski
審核編輯：郭婷
工商網監
評論