2.盡早發現內存問題[52RD.com]
[52RD.com]
內存問題危害很大，不容易排查，主要有三種類型:內存泄露、內存碎片和內存崩潰。對于內存問題態度必須要明確，那就是早發現早“治療”。在軟件設計中，內存泄露的“名氣”最大，主要由于不斷分配的內存無法及時地被釋放，久而久之，系統的內存耗盡。即使細心的編程老手有時后也會遭遇內存泄露問題。有測試過內存泄露的朋友估計都有深刻地體驗，那就是內存泄露問題一般隱藏很深，很難通過代碼閱讀來發現。有些內存泄露甚至可能出現在庫當中。有可能這本身是庫中的bug，也有可能是因為程序員沒有正確理解它們的接口說明文檔造成錯用。[52RD.com]
[52RD.com]
在很多時候，大多數的內存泄露問題無法探測，但可能表現為隨機的故障。程序員們往往會把這種現象怪罪于硬件問題。如果用戶對系統穩定性不是很高，那么重啟系統問題也不大;但，如果用戶對系統穩定很高，那么這種故障就有可能使用戶對產品失去信心，同時也意味著你的項目是個失敗的項目。由于內存泄露危害巨大，現在已經有許多工具來解決這個問題。這些工具通過查找沒有引用或重復使用的代碼塊、垃圾內存收集、庫跟蹤等技術來發現內存泄露的問題。每個工具都有利有弊，不過總的來說，用要比不用好�？傊�，負責的開發人員應該去測試內存泄露的問題，做到防患于未然。[52RD.com]
[52RD.com]
內存碎片比內存泄露隱藏還要深。隨著內存的不斷分配并釋放，大塊內存不斷分解為小塊內存，從而形成碎片，久而久之，當需要申請大塊內存是，有可能就會失敗。如果系統內存夠大，那么堅持的時間會長一些，但最終還是逃不出分配失敗的厄運。在使用動態分配的系統中，內存碎片經常發生。目前，解決這個問題最效的方法就是使用工具通過顯示系統中內存的使用情況來發現誰是導致內存碎片的罪魁禍首，然后改進相應的部分。[52RD.com]
[52RD.com]
由于動態內存管理的種種問題，在嵌入式應用中，很多公司干脆就禁用malloc/free的以絕后患。[52RD.com]
[52RD.com]
內存崩潰是內存使用最嚴重的結果，主要原因有數組訪問越界、寫已經釋放的內存、指針計算錯誤、訪問堆棧地址越界等等。這種內存崩潰造成系統故障是隨機的，而且很難查找，目前提供用于排查的工具也很少。[52RD.com]
[52RD.com]
總之，如果要使用內存管理單元的話，必須要小心，并嚴格遵守它們的使用規則，比如誰分配誰釋放。[52RD.com]
[52RD.com]
3.深入理解代碼優化[52RD.com]
[52RD.com]
講到系統穩定性，人們更多地會想到實時性和速度，因為代碼效率對嵌入式系統來說太重要了。知道怎么優化代碼是每個嵌入式軟件開發人員必須具備的技能。就象女孩子減肥一樣，起碼知道她哪個地方最需要減，才能去購買減肥藥或器材來減掉它�？梢�，代碼優化的前提是找到真正需要優化的地方，然后對癥下藥，優化相應部分的代碼。前面提到的profile(性能分析工具，一些功能齊全IDE都提供這種內置的工具)能夠記錄各種情況比如各個任務的CPU占用率、各個任務的優先級是否分配妥當、某個數據被拷貝了多少次、訪問磁盤多少次、是否調用了網絡收發的程序、測試代碼是否已經關閉等等。[52RD.com]
[52RD.com]
但是，profile工具在分析實時系統性能方面還是有不夠的地方。一方面，人們使用profile工具往往是在系統出現問題即CPU耗盡之后，而profile工具本身對CPU占用較大，所以profile對這種情況很可能不起作用。根據Heisenberg效應，任何測試手段或多或少都會改變系統運行，這個對profiler同樣適用![52RD.com]
[52RD.com]
總之，提高運行效率的前提是你必須要知道CPU到底干了些什么干的怎么樣。[52RD.com]
[52RD.com]
4.不要讓自己大海撈針[52RD.com]
[52RD.com]
大海撈針只是對調試的一種生動比喻。[52RD.com]
[52RD.com]
經常聽到組里有人對自己正在調試的代碼說shit!可以理解，因為代碼不是他寫的，他有足夠的理由去shit bug百出的代碼，只要他自己不要寫出這種代碼，否則有一天同組的其它人可能同樣會shit他寫的代碼。為何會有大海撈針呢?肯定是有人把針掉到海里咯;那針為何會掉在海里呢?肯定是有人不小心或草率唄。所以當你在抱怨針那么難找的時候，你是否想過是你自己草率地丟掉的。同樣，當你調試個半死的時候，你是否想過你要好好反省一下當初為了尋求捷徑可能沒有嚴格地遵守好的編碼設計規范、沒有檢測一些假設條件或算法的正確性、沒有將一些可能存在問題的代碼打上記號呢?關于如何寫高質量請參考林銳的《高質量c++/c編程指南》或《關于C的0x8本“經書”》。[52RD.com]
[52RD.com]
如果你確實已經把針掉在海里是，為了防止在找到之前刺到自己，你必須要做一些防范工作，比如戴上安全手套。同樣，為了盡能地暴露和捕捉問題根源，我們可以設計比較全面的錯誤跟蹤代碼。怎么來做呢?盡可能對每個函數調用失敗作出處理，盡可能檢測每個參數輸入輸出的有效性包括指針以及檢測是否過多或過少地調用某個過程。錯誤跟蹤能夠讓你知道你大概把針掉在哪個位置。[52RD.com]
[52RD.com]
5.重現并隔離問題[52RD.com]
[52RD.com]
如果你不是把針掉在大海了，而是掉在草堆里，那要好辦寫。因為至少我們可以把草堆分成很多塊，一塊一塊的找。對于模塊獨立的大型項目，使用隔離方法往往是對付那些隱藏極深bug的最后方法。如果問題的出現是間歇性的,我們有必要設法去重現它并記錄使其重現的整個過程以備在下一次可以利用這些條件去重現問題。如果你確信可以使用記錄的那些條件去重現問題，那么我們就可以著手去隔離問題。怎么隔離呢?我們可以用#ifdef把一些可能和問題無關的代碼關閉，把系統最小化到仍能夠重現問題的地步。如果還是無法定位問題所在，那么有必要打開“工具箱”了�？梢栽囍肐CE或數據監視器去查看某個可疑變量的變化;可以使用跟蹤工具獲得函數調用的情況包括參數的傳遞;檢查內存是否崩潰以及堆棧溢出的問題。[52RD.com]
[52RD.com]
6.以退為進[52RD.com]
[52RD.com]
獵人為了不使自己在森林里迷路，他常常會在樹木上流下一些標記，以備自己將來有一天迷路時可以根據這些標記找到出路。對過去代碼的修改進行跟蹤記錄對將來出現問題之后的調試很有幫助。假如有一天，你最近一次修改的程序跑了很久之后忽然死掉了，那么你這時的第一反映就是我到底改動了些什么呢，因為上次修改之前是好的。那么如何檢測這次相對于上次的修改呢?沒錯，代碼控制系統SCS或稱版本控制系統VCS(Concurrent Version Control,CVS是VCS的演化版本)。將上個版本check in下來后和當前測試版本比較。比較的工具可以是SCS/VCS/CVS自帶的diff工具或其它功能更強的比較工具，比如BeyondCompare和ExamDiff。通過比較，記錄所有改動的代碼，分析所有可能導致問題的可疑代碼。[52RD.com]
[52RD.com]
7.確定測試的完整性[52RD.com]
[52RD.com]
