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

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

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

　　情景簡介

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

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

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

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

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

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

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

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