在C語(yǔ)言中用ASSERT調試的八個(gè)技巧

C語(yǔ)言中的ASSERT(斷言)宏是嵌入式軟件開(kāi)發(fā)人員可以使用的最好的調試工具之一。雖然ASSERT功能強大，但我很少看到它被實(shí)施，并且在一些使用它的案例中，它的實(shí)施要么是有瑕疵的要么是不正確的。以下一些技巧將不僅能夠幫助闡明在何時(shí)、何地使用ASSERT，而且還能闡明如何開(kāi)始正確使用它。

技巧1：記住ASSERT的定義

對許多開(kāi)發(fā)人員來(lái)說(shuō)，斷言是一個(gè)令人困惑的話(huà)題，因為它們的許多使用方式與其設計初衷背道而馳。我見(jiàn)到的最清晰的斷言定義是這樣的：

“斷言是在程序某個(gè)特定點(diǎn)的一個(gè)布爾表達式，除非程序中有缺陷(Bug)，否則它的值將為真。”

想要理解上述斷言定義的開(kāi)發(fā)人員應該留意下面三個(gè)要點(diǎn)：

·斷言會(huì )評估一個(gè)表達式是真還是假

·斷言是在代碼中的某個(gè)點(diǎn)對系統狀態(tài)的一種假設

·斷言會(huì )驗證系統假設，如果不為真，就表明代碼中有一個(gè)缺陷

技巧2：使用ASSERT驗證函數的先決條件

斷言非常適合契約式設計環(huán)境，在這種環(huán)境中，開(kāi)發(fā)人員非常清晰地定義了某個(gè)函數的先決條件。斷言可以用來(lái)檢查該函數的輸入是否滿(mǎn)足先決條件。就拿圖1所示的代碼片段為例：

圖1：函數的先決條件

函數的STate輸入應該在定義的系統狀態(tài)范圍內。如果State不是有效的狀態(tài)值，那么它就不是錯誤，而是缺陷!斷言可以用來(lái)驗證State是有效的假設，如圖2所示：

圖2：對函數先決條件應用斷言

在State不小于最大值的事件中，斷言表達式將被評估為假，程序于是將停止執行。停止程序執行可以讓開(kāi)發(fā)人員很容易馬上看到哪里的代碼出錯，而不是過(guò)段時(shí)間以后才知道。

技巧3：使用ASSERT驗證函數的后置條件

斷言也能用來(lái)驗證契約式設計環(huán)境中對某個(gè)函數輸出的假設。例如，如果前面定義的System_StateSet函數返回SystemState變量，開(kāi)發(fā)人員可以預計它也在期望的范圍之內。斷言可以用來(lái)對缺陷進(jìn)行監視，如圖3所示。

圖3：對函數后置條件應用斷言

開(kāi)發(fā)人員在查看上述代碼后可能會(huì )感到這些檢查毫無(wú)意義。剛剛才設置好的SystemState怎么就會(huì )出現大于SYSTEM_STATE_MAX的值呢?答案是這確實(shí)不應該出現，然而有時(shí)候會(huì )莫名其妙地發(fā)生改變，也許是通過(guò)中斷或并行線(xiàn)程，此時(shí)斷言可以立即標志出這個(gè)缺陷。

技巧4：不要把ASSERT用于錯誤處理

在記住斷言定義之后，開(kāi)發(fā)人員應該切記：斷言是用于檢測缺陷的，不能用于錯誤處理。錯誤處理是設計用于響應錯誤的用戶(hù)輸入和意外的事件順序的軟件。錯誤在系統中預料是會(huì )發(fā)生的，但僅僅是因為有無(wú)效的輸入而并不意味著(zhù)代碼中有缺陷。錯誤處理應該與缺陷尋找分開(kāi)來(lái)。錯誤使用斷言的一個(gè)典型例子是，在試圖打開(kāi)一個(gè)文件用于讀取時(shí)去檢查文件的指針，如圖4所示。

圖4：ASSERT的不當使用

讀者可以清楚地看到，試圖打開(kāi)文件的結果與文件系統的狀態(tài)和用戶(hù)數據有關(guān)，而與代碼中的缺陷一點(diǎn)關(guān)系也沒(méi)有。開(kāi)發(fā)人員應該編寫(xiě)錯誤處理程序，而不是用斷言，以便在文件不存在時(shí)，錯誤處理程序可以用一些默認可用數據來(lái)創(chuàng )建它，以便后續代碼繼續操作。

技巧5：ASSERT僅對開(kāi)發(fā)有意義，不能用于生產(chǎn)

開(kāi)發(fā)ASSERT宏的原始意圖是在開(kāi)發(fā)過(guò)程中啟用它，在后面生產(chǎn)時(shí)要禁用?？梢杂肗DEBUG宏激活和禁用ASSERT。正確實(shí)施的斷言在被禁用后應該對嵌入式系統基本沒(méi)有影響。

問(wèn)題是，如果測試是在斷言啟用的情況下進(jìn)行的(為了捕捉任何缺陷，應該這樣做)，那么現在禁用斷言將導致交付的產(chǎn)品與測試的產(chǎn)品處于不同的狀態(tài)。斷言確實(shí)會(huì )占用一些代碼空間，但更重要的是，它們需要占用少量的時(shí)鐘周期來(lái)評估它們的布爾表達式。禁用ASSERT可能對具有有限資源的裸機系統的執行時(shí)序產(chǎn)生很大影響，從而導致在生產(chǎn)系統中產(chǎn)生新的缺陷。開(kāi)發(fā)團隊需要判斷是否值得冒關(guān)閉斷言的風(fēng)險。

一種替代方案是保留斷言在激活狀態(tài)，而將它們的輸出重定向到一個(gè)系統日志。這樣可以確保任何揮之不去的缺陷很容易被識別，而且能避免中止系統的運行，而中止系統可不是明智之舉。

技巧6：不允許斷言有副作用

ASSERT的默認實(shí)現允許開(kāi)發(fā)人員包含一段可執行代碼作為布爾表達式的一部分。舉例來(lái)說(shuō)，一個(gè)狀態(tài)變量可以被實(shí)現為表達式的一部分并傳遞給ASSERT。但如果傳遞給ASSERT的表達式有副作用，也就是說(shuō)，它會(huì )改變嵌入式系統的狀態(tài)，那么禁用斷言將改變系統的行為。開(kāi)發(fā)人員應該確保他們的表達式?jīng)]有副作用，否則他們需要冒險在系統中增加只針對產(chǎn)品代碼喚醒的休眠時(shí)間缺陷。

技巧7：斷言應該占代碼的1%至3%

每個(gè)開(kāi)發(fā)人員對于代碼庫(Code Base)中應該有多少個(gè)斷言都有自己的主見(jiàn)。大家一致同意的一個(gè)數字是，代碼庫中的斷言占比應該大于0。斷言為開(kāi)發(fā)人員提供了一種在代碼庫中發(fā)生缺陷的時(shí)刻發(fā)現它的好方法。調試是在開(kāi)發(fā)嵌入式系統中最浪費時(shí)間并令人沮喪的事情之一。不管開(kāi)發(fā)人員認可的占比是1%、3%還是5%，使用斷言肯定對你有利，并會(huì )使開(kāi)發(fā)嵌入式軟件變得多少有些趣味。

技巧8：將斷言用作可執行代碼注釋

斷言可以生成極好的注釋!編寫(xiě)出色的表達式可以確切地告訴開(kāi)發(fā)人員在代碼的某個(gè)給定點(diǎn)應該預料發(fā)生什么事情。開(kāi)發(fā)人員應該做好他們斷言的架構，幫助人們更清楚地理解系統中發(fā)生的事情，進(jìn)而幫助減少缺陷。

小結

斷言是一種出色的工具，但有太多的嵌入式軟件開(kāi)發(fā)人員忽視了這一工具。本文討論的八個(gè)技巧只是如何正確使用斷言的冰山一角。接下來(lái)讀者就可以在測試平臺中建立和開(kāi)始使用斷言，并研究它們在實(shí)際的嵌入式系統中是如何工作的。