嵌入式軟件測試的10條秘訣

XYD李

很多年前，一位開發人員為了在對嵌入式有更深層次的理解，詢問了這樣的一個問題：我怎么才能知道并懂得我的系統到底在干些什么呢？

面對這個問題有些吃驚，因為在當時沒有人這么問過，而同時代的嵌入式開發人員問的最多的大都圍繞“我怎么才能使程序跑得更快”、“什么編譯器最好”等膚淺的問題。

所以，面對這個不同尋常卻異乎成熟的問題，信盈達小編感到欣喜并認真回復了他：你的問題很有深度很成熟，因為只有不斷地去深入理解才有可能不斷地提高水平。為了鼓勵這位執著的程序員，把10條關于嵌入式軟件開發測試的秘訣告訴了他。下面我們一起來看看。

這10條秘訣在業界廣為流傳，使很多人受益。本文圍繞這10條秘訣展開論述。

1、懂得使用工具

通常嵌入式系統對可靠性的要求比較高。嵌入式系統安全性的失效可能會導致災難性的后果，即使是非安全性系統，由于大批量生產也會導致嚴重的經濟損失。這就要求對嵌入式系統，包括嵌入式軟件進行嚴格的測試、確認和驗證。隨著越來越多的領域使用軟件和微處理器控制各種嵌入式設備，對日益復雜的嵌入式軟件進行快速有效的測試愈加顯得重要。

就像修車需要工具一樣，好的程序員應該能夠熟練運用各種軟件工具。不同的工具，有不同的使用范圍，有不同的功能。使用這些工具，你可以看到你的系統在干些什么，它又占用什么資源，它到底和哪些外界的東西打交道。讓你郁悶好幾天的問題可能通過某個工具就能輕松搞定，可惜你就是不知道。

那么為什么那么多的人總是在折騰個半死之后才想到要用測試工具呢？原因很多，主要有兩個：

一個是害怕；

另一個是惰性；

害怕是因為加入測試工具或測試模塊到代碼需要技巧同時有可能引入新的錯誤，所以他們總喜歡寄希望于通過不斷地修改重編譯代碼來消除bug，結果卻無濟于事。

懶惰是因為他們習慣了使用printf之類的簡單測試手段。

2、盡早發現內存問題

內存問題危害很大，不容易排查，主要有三種類型：內存泄露、內存碎片和內存崩潰。對于內存問題態度必須要明確，那就是早發現早“治療”。在軟件設計中，內存泄露的“名氣”最大，主要由于不斷分配的內存無法及時地被釋放，久而久之，系統的內存耗盡。

即使細心的編程老手有時后也會遭遇內存泄露問題。有測試過內存泄露的朋友估計都有深刻地體驗，那就是內存泄露問題一般隱藏很深，很難通過代碼閱讀來發現。有些內存泄露甚至可能出現在庫當中。有可能這本身是庫中的bug，也有可能是因為程序員沒有正確理解它們的接口說明文檔造成錯用。

在很多時候，大多數的內存泄露問題無法探測，但可能表現為隨機的故障。程序員們往往會把這種現象怪罪于硬件問題。如果用戶對系統穩定性不是很高，那么重啟系統問題也不大；但，如果用戶對系統穩定很高，那么這種故障就有可能使用戶對產品失去信心，同時也意味著你的項目是個失敗的項目。

由于內存泄露危害巨大，現在已經有許多工具來解決這個問題。這些工具通過查找沒有引用或重復使用的代碼塊、垃圾內存收集、庫跟蹤等技術來發現內存泄露的問題。每個工具都有利有弊，不過總的來說，用要比不用好。總之，負責的開發人員應該去測試內存泄露的問題，做到防患于未然。

內存碎片比內存泄露隱藏還要深。隨著內存的不斷分配并釋放，大塊內存不斷分解為小塊內存，從而形成碎片，久而久之，當需要申請大塊內存是，有可能就會失敗。如果系統內存夠大，那么堅持的時間會長一些，但最終還是逃不出分配失敗的厄運。在使用動態分配的系統中，內存碎片經常發生。

目前，解決這個問題最效的方法就是使用工具通過顯示系統中內存的使用情況來發現誰是導致內存碎片的罪魁禍首，然后改進相應的部分。由于動態內存管理的種種問題，在嵌入式應用中，很多公司干脆就禁用malloc/free的以絕后患。

內存崩潰是內存使用最嚴重的結果，主要原因有數組訪問越界、寫已經釋放的內存、指針計算錯誤、訪問堆棧地址越界等等。這種內存崩潰造成系統故障是隨機的，而且很難查找，目前提供用于排查的工具也很少。

總之，如果要使用內存管理單元的話，必須要小心，并嚴格遵守它們的使用規則，比如誰分配誰釋放。

3、深入理解代碼優化

講到系統穩定性，人們更多地會想到實時性和速度，因為代碼效率對嵌入式系統來說太重要了。知道怎么優化代碼是每個嵌入式軟件開發人員必須具備的技能。就像女孩子減肥一樣，起碼知道她哪個地方最需要減，才能去購買減肥藥或器材來減掉它。

可見，代碼優化的前提是找到真正需要優化的地方，然后對癥下藥，優化相應部分的代碼。

總之，提高運行效率的前提是你必須要知道CPU到底干了些什么干的怎么樣。

4、不要讓自己大海撈針

大海撈針只是對調試的一種生動比喻。經常聽到組里有人對自己正在調試的代碼說shit！可以理解，因為代碼不是他寫的，他有足夠的理由去 shitbug百出的代碼，只要他自己不要寫出這種代碼，否則有一天同組的其它人可能同樣會shit他寫的代碼。為何會有大海撈針呢？肯定是有人把針掉到海里咯；那針為何會掉在海里呢？肯定是有人不小心或草率唄。

所以當你在抱怨針那么難找的時候，你是否想過是你自己草率地丟掉的。同樣，當你調試個半死的時候，你是否想過你要好好反省一下當初為了尋求捷徑可能沒有嚴格地遵守好的編碼設計規范、沒有檢測一些假設條件或算法的正確性、沒有將一些可能存在問題的代碼打上記號呢？

怎么來做呢？

盡可能對每個函數調用失敗作出處理，盡可能檢測每個參數輸入輸出的有效性，包括指針以及檢測是否過多或過少地調用某個過程。錯誤跟蹤能夠讓你知道你大概把針掉在哪個位置。

5、重現并隔離問題

如果你不是把針掉在大海了，而是掉在草堆里，那要好辦些。因為至少我們可以把草堆分成很多塊，一塊一塊的找。對于模塊獨立的大型項目，使用隔離方法往往是對付那些隱藏極深bug的最后方法。

如果問題的出現是間歇性的，我們有必要設法去重現它并記錄使其重現的整個過程以備在下一次可以利用這些條件去重現問題。如果你確信可以使用記錄的那些條件去重現問題，那么我們就可以著手去隔離問題。

怎么隔離呢？

我們可以用#ifdef把一些可能和問題無關的代碼關閉，把系統最小化到仍能夠重現問題的地步。如果還是無法定位問題所在，那么有必要打開“工具箱”了。可以試著用ICE或數據監視器去查看某個可疑變量的變化；可以使用跟蹤工具獲得函數調用的情況包括參數的傳遞；檢查內存是否崩潰以及堆棧溢出的問題。

6、以退為進

獵人為了不使自己在森林里迷路，他常常會在樹木上流下一些標記，以備自己將來有一天迷路時可以根據這些標記找到出路。對過去代碼的修改進行跟蹤記錄對將來出現問題之后的調試很有幫助。

假如有一天，你最近一次修改的程序跑了很久之后忽然死掉了，那么你這時的第一反映就是我到底改動了些什么呢，因為上次修改之前是好的。那么如何檢測這次相對于上次的修改呢？沒錯，代碼控制系統SCS或稱版本控制系統 VCS可以很好地解決這個問題。

7、確定測試的完整性

你怎么知道你的測試有多全面呢？覆蓋測試可以回答這個問題。覆蓋測試工具可以告訴你CPU到底執行了哪些代碼。好的覆蓋工具通常可以告訴你大概20%到40% 代碼沒有問題，而其余的可能存在bug.覆蓋工具有不同的測試級別，用戶可以根據自己的需要選擇某個級別。

8、提高代碼質量意味著節省時間

有研究表明軟件開發的時間超過80%被用在下面幾個方面：調試自己的代碼（單元測試）。調試自己和其他相關的代碼（模塊間測試）。調試整個系統（系統測試），更糟糕的是你可能需要花費10-200倍的時間來找一個 bug，而這個bug在開始的時候可能很容易就能找到。

一個小bug可能讓你付出巨大的代價，即使這個bug對整個系統的性能沒有太大的影響，但很可能會影響讓那些你可以看得到的部分。所以我們必須要養成良好的編碼和測試手段以求更高的代碼質量，以便縮短調試的代碼。

9、發現它，分析它，解決它

這世界沒有萬能的膏藥。profile再強大也有力不從心的時候；內存監視器再好，也有無法發現的時候；覆蓋工具再好用，也有不能覆蓋的地方。

一些隱藏很深的問題即使用盡所有工具也有可能無法查到其根源，這時我們能做的就是通過這些問題所表現出來的外在現象或一些數據輸出來發現其中的規律或異常。一旦發現任何異常，一定要深入地理解并回溯其根源，直到解決為止。

10、請利用初學者思維

有人這樣說過：“有些事情在初學者的腦子里可能有各種各樣的情況，可在專家的頭腦里可能就很單一”。有時候，有些簡單的問題會被想得很復雜，有些簡單的系統被設計得很復雜，就是由于你的“專家思維”。當你被問題難住時，關掉電腦，出去走走，把你的問題和你的朋友甚至你的小狗說說，或許他們可以給你意想不到的啟發。

總結

嵌入式調試也是一門藝術。就想其它的藝術一樣，如果你想取得成功，你必須具備智慧、經驗并懂得使用工具。只要我們能夠很好地領悟Oracle這十條秘訣，我相信我們在嵌入式測試方面就能夠取得成功。

課程咨詢：C語言，單片機，Linux電路設計，PCB軟件測試，python，JAVA，C++，QT等課程培訓提升，面授線上學習，有需要加18025267692（微信）私聊