嵌入式軟件測試的十大秘訣3 作者： 來(lái)源于： 發(fā)布時(shí)間：2007-1-31 20:45:00
4.不要讓自己大海撈針
大海撈針只是對調試的一種生動(dòng)比喻。
經(jīng)常聽(tīng)到組里有人對自己正在調試的代碼說(shuō)shit!可以理解，因為代碼不是他寫(xiě)的，他有足夠的理由去shit bug百出的代碼，只要他自己不要寫(xiě)出這種代碼，否則有一天同組的其它人可能同樣會(huì )shit他寫(xiě)的代碼。為何會(huì )有大海撈針呢?肯定是有人把針掉到海里咯;那針為何會(huì )掉在海里呢?肯定是有人不小心或草率唄。所以當你在抱怨針那么難找的時(shí)候，你是否想過(guò)是你自己草率地丟掉的。同樣，當你調試個(gè)半死的時(shí)候，你是否想過(guò)你要好好反省一下當初為了尋求捷徑可能沒(méi)有嚴格地遵守好的編碼設計規范、沒(méi)有檢測一些假設條件或算法的正確性、沒(méi)有將一些可能存在問(wèn)題的代碼打上記號呢?關(guān)于如何寫(xiě)高質(zhì)量請參考林銳的《高質(zhì)量c++/c編程指南》或《關(guān)于C的0x8本“經(jīng)書(shū)”》。
如果你確實(shí)已經(jīng)把針掉在海里是，為了防止在找到之前刺到自己，你必須要做一些防范工作，比如戴上安全手套。同樣，為了盡能地暴露和捕捉問(wèn)題根源，我們可以設計比較全面的錯誤跟蹤代碼。怎么來(lái)做呢?盡可能對每個(gè)函數調用失敗作出處理，盡可能檢測每個(gè)參數輸入輸出的有效性包括指針以及檢測是否過(guò)多或過(guò)少地調用某個(gè)過(guò)程。錯誤跟蹤能夠讓你知道你大概把針掉在哪個(gè)位置。
5.重現并隔離問(wèn)題
如果你不是把針掉在大海了，而是掉在草堆里，那要好辦寫(xiě)。因為至少我們可以把草堆分成很多塊，一塊一塊的找。對于模塊獨立的大型項目，使用隔離方法往往是對付那些隱藏極深bug的最后方法。如果問(wèn)題的出現是間歇性的,我們有必要設法去重現它并記錄使其重現的整個(gè)過(guò)程以備在下一次可以利用這些條件去重現問(wèn)題。如果你確信可以使用記錄的那些條件去重現問(wèn)題，那么我們就可以著(zhù)手去隔離問(wèn)題。怎么隔離呢?我們可以用#ifdef把一些可能和問(wèn)題無(wú)關(guān)的代碼關(guān)閉，把系統最小化到仍能夠重現問(wèn)題的地步。如果還是無(wú)法定位問(wèn)題所在，那么有必要打開(kāi)“工具箱”了?？梢栽囍?zhù)用ICE或數據監視器去查看某個(gè)可疑變量的變化;可以使用跟蹤工具獲得函數調用的情況包括參數的傳遞;檢查內存是否崩潰以及堆棧溢出的問(wèn)題。
6.以退為進(jìn)
獵人為了不使自己在森林里迷路，他常常會(huì )在樹(shù)木上流下一些標記，以備自己將來(lái)有一天迷路時(shí)可以根據這些標記找到出路。對過(guò)去代碼的修改進(jìn)行跟蹤記錄對將來(lái)出現問(wèn)題之后的調試很有幫助。假如有一天，你最近一次修改的程序跑了很久之后忽然死掉了，那么你這時(shí)的第一反映就是我到底改動(dòng)了些什么呢，因為上次修改之前是好的。那么如何檢測這次相對于上次的修改呢?沒(méi)錯，代碼控制系統SCS或稱(chēng)版本控制系統VCS(Concurrent Version Control,CVS是VCS的演化版本)。將上個(gè)版本check in下來(lái)后和當前測試版本比較。比較的工具可以是SCS/VCS/CVS自帶的diff工具或其它功能更強的比較工具，比如BeyondCompare和ExamDiff。通過(guò)比較，記錄所有改動(dòng)的代碼，分析所有可能導致問(wèn)題的可疑代碼。
7.確定測試的完整性
你怎么知道你的測試有多全面呢?覆蓋測試(coverage testing)可以回答這個(gè)問(wèn)題。覆蓋測試工具可以告訴你CPU到底執行了那些代碼。好的覆蓋工具通?？梢愿嬖V你大概20%到40%代碼沒(méi)有問(wèn)題，而其余的可能存在bug。覆蓋工具有不同的測試級別，用戶(hù)可以根據自己的需要選擇某個(gè)級別。即使你很確信你的單元測試已經(jīng)很全面并且沒(méi)有dead code,覆蓋工具還是可以為你指出一些潛在的問(wèn)題，看下面的代碼:
if (i >= 0 && (almostAlwaysZero == 0 || (last = i)))
如果almostAlwaysZero為非0,那么last=i賦值語(yǔ)句就被跳過(guò)，這可能不是你所期望的。這種問(wèn)題通過(guò)覆蓋工具的條件測試功能可以輕松的被發(fā)現。
總之，覆蓋測試對于提高代碼質(zhì)量很有幫助。
8.提高代碼質(zhì)量意味著(zhù)節省時(shí)間
有研究表明軟件開(kāi)發(fā)的時(shí)間超過(guò)80%被用在下面幾個(gè)方面:
.調試自己的代碼(單元測試)
.調試自己和其他相關(guān)的代碼(模塊間測試)
.調試整個(gè)系統(系統測試)
更糟糕的是你可能需要花費10-200倍的時(shí)間來(lái)找一個(gè)bug,而這個(gè)bug在開(kāi)始的時(shí)候可能很容易就能找到。一個(gè)小bug可能讓你付出巨大的代價(jià)，即使這個(gè)bug對整個(gè)系統的性能沒(méi)有太大的影響，但很可能會(huì )影響讓那些你可以看得到的部分。所以我們必須要養成良好的編碼和測試手段以求更高的代碼質(zhì)量，以便縮短調試的代碼。
9.發(fā)現它，分析它，解決它
這世界沒(méi)有萬(wàn)能的膏藥。profile再強大也有力不從心的時(shí)候;內存監視器再好，也有無(wú)法發(fā)現的時(shí)候;覆蓋工具再好用，也有不能覆蓋的地方。一些隱藏很深的問(wèn)題即使用盡所有工具也有可能無(wú)法查到其根源，這時(shí)我們能做的就是通過(guò)這些問(wèn)題所表現出來(lái)的外在現象或一些數據輸出來(lái)發(fā)現其中的規律或異常。一旦發(fā)現任何異常，一定要深入地理解并回溯其根源，直到解決為止。
10.利用初學(xué)者的思維
有人這樣說(shuō)過(guò):“有些事情在初學(xué)者的腦子里可能有各種各樣的情況，可在專(zhuān)家的頭腦里可能就很單一”。有時(shí)候，有些簡(jiǎn)單的問(wèn)題會(huì )被想的很復雜，有些簡(jiǎn)單的系統別設計的很復雜，就是由于你的“專(zhuān)家思維”。當你被問(wèn)題難住時(shí)，關(guān)掉電腦，出去走走，把你的問(wèn)題和你的朋友甚至你的小狗說(shuō)說(shuō)，或許他們可以給你意想不到的啟發(fā)。
總結:嵌入式調試也是一門(mén)藝術(shù)。就想其它的藝術(shù)一樣，如果你想取得成功，你必須具備智慧、經(jīng)驗并懂得使用工具。只要我們能夠很好地領(lǐng)悟Oracle這十條秘訣，我相信我們在嵌入式測試方面就能夠取得成功。
