但是，profile工具在分析實(shí)時(shí)系統性能方面還是有不夠的地方。一方面，人們使用profile工具往往是在系統出現問(wèn)題即CPU耗盡之后，而profile工具本身對CPU占用較大，所以profile對這種情況很可能不起作用。根據Heisenberg效應，任何測試手段或多或少都會(huì )改變系統運行，這個(gè)對profiler同樣適用! 總之，提高運行效率的前提是你必須要知道CPU到底干了些什么干的怎么樣。
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)題的代碼打上記號呢?
如果你確實(shí)已經(jīng)把針掉在海里是，為了防止在找到之前刺到自己，你必須要做一些防范工作，比如戴上安全手套。同樣，為了盡能地暴露和捕捉問(wèn)題根源，我們可以設計比較全面的錯誤跟蹤代碼。怎么來(lái)做呢?盡可能對每個(gè)函數調用失敗作出處理，盡可能檢測每個(gè)參數輸入輸出的有效性包括指針以及檢測是否過(guò)多或過(guò)少地調用某個(gè)過(guò)程。錯誤跟蹤能夠讓你知道你大概把針掉在哪個(gè)位置。
5.重現并隔離問(wèn)題
如果你不是把針掉在大海了，而是掉在草堆里，那要好辦些。因為至少我們可以把草堆分成很多塊，一塊一塊的找。對于模塊獨立的大型項目，使用隔離方法往往是對付那些隱藏極深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ā)現任何異常，一定要深入地理解并回溯其根源，直到解決為止。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
