在嵌入式軟件開發(fā)過程中，花在測試和花在編碼的時間比通常在3:1左右（實際上可能更多）。這個比例會隨著工程師編程、測試水平的提高而不斷下降，但無論如何，軟件測試都是嵌入式軟件開發(fā)中至關(guān)重要的部分。

多年前，一位工程師為了對嵌入式擁有更深層次理解的追求，曾發(fā)出這樣的疑問：“我怎么才能知道并懂得我的系統(tǒng)到底在干些什么呢？”。同時代的嵌入式開發(fā)人員問得最多的問題大都圍繞“我怎么才能使程序跑得更快”、“什么編譯器最好”，這個問題雖然不同尋常，但卻異乎成熟。今天就讓我們一起了解10條在業(yè)界廣為流傳的嵌入式開發(fā)測試秘訣。

一、懂得使用工具

嵌入式系統(tǒng)通常對可靠性要求較高，一旦發(fā)生安全問題可能就會導(dǎo)致災(zāi)難性的后果，即使與安全無關(guān)也會帶來嚴重的經(jīng)濟損失，對嵌入式系統(tǒng)及軟件有著嚴格的測試、確認和驗證要求。隨著越來越多的領(lǐng)域的嵌入式設(shè)備開始被軟件和微處理器控制，對日益復(fù)雜的嵌入式軟件進行快速有效的測試顯得愈加重要。

好的修車匠需要好工具，好的程序員應(yīng)該能夠熟練運用各種軟件工具。不同的工具有不同的使用范圍、功能。合適的工具可以讓工程師看到系統(tǒng)在干些什么，它又占用什么資源、到底和外界哪些東西打交道。工程師不應(yīng)該害怕加入測試工具或測試模塊到代碼需要的技巧或可能引入新的錯誤，光靠不斷修改、重新編譯代碼來消除Bug是不夠的；也不應(yīng)該因習(xí)慣使用printf之類的簡單測試手段而不進行新的學(xué)習(xí)和探索。下面是一些嵌入式常用的測試工具。

源碼級調(diào)試器【Source-levelDebugger】：此類調(diào)試器一般提供單步或多步調(diào)試、斷點設(shè)置、內(nèi)存檢測、變量查看等功能，是嵌入式調(diào)試最基本的調(diào)試方法。

簡單實用的打印顯示工具【printf】：printf及類似的打印顯示工具估計是最靈活、最簡單的調(diào)試工具。打印代碼執(zhí)行過程中的各種變量可以讓工程師獲知代碼執(zhí)行的情況，但printf對正常的代碼執(zhí)行干擾比較大（一般printf會占用CPU較長時間），需要慎重使用，最好設(shè)置打印開關(guān)來控制打印。

ICE或JTAG調(diào)試器【In- circuitEmulator】：ICE是用來仿真CPU核心的設(shè)備，可以在不干擾運算器的正常運行情況下，實時檢測CPU內(nèi)部工作情況，也能像桌面調(diào)試軟件一樣提供復(fù)雜的條件斷點、先進的實時跟蹤、性能分析和端口分析等功能。ICE一般都有一個較為特殊的CPU，被稱為外合（bond-out）CPU，是一種被打開了封裝且通過特殊的連接可以訪問CPU內(nèi)部信號的CPU，這些信號在CPU被封裝時是沒法被“看到”的。當(dāng)和工作站上強大的調(diào)試軟件聯(lián)合使用時，ICE就能提供幾乎最全面的調(diào)試功能。然而ICE同樣有著昂貴、不能全速工作的缺點；同樣，并不是所有的CPU都可以作為外合CPU的，從另一個角度說，這些外合CPU也不大可能及時被新出的CPU所更換。JTAG（Joint Test Action Group）最初開發(fā)目的是監(jiān)測IC和電路連接，但其擴展了包括調(diào)試支持在內(nèi)的用途。

ROM監(jiān)視器【ROMMonitor】：一款駐留在嵌入系統(tǒng)ROM中的小程序，通過串行或網(wǎng)絡(luò)連接和運行在工作站上的調(diào)試軟件通信。這是最低端的技術(shù)，相對便宜，除了要求一個通信端口和少量的內(nèi)存空間外，不需要其它任何專門的硬件，提供下載代碼、運行控制、斷點、單步步進，以及觀察、修改寄存器和內(nèi)存等功能。由于ROM監(jiān)控器是操作軟件的一部分，所以如果想要檢查CPU和應(yīng)用程序的狀態(tài)，必須先停下應(yīng)用程序，再次進入ROM監(jiān)控器。

Data監(jiān)視器【DataMonitor】：在不停止CPU運行的情況下不僅可以顯示指定變量內(nèi)容，還可以收集并以圖形形式顯示各個變量的變化過程。

OS監(jiān)視器【Operating System Monitor】：操作系統(tǒng)監(jiān)視器可以顯示諸如任務(wù)切換、信號量收發(fā)、中斷等事件。這些監(jiān)視器能夠呈現(xiàn)事件之間的關(guān)系和時間聯(lián)系，還可以提供對信號量優(yōu)先級反轉(zhuǎn)、死鎖和中斷延時等問題的診斷。

性能分析工具【Profiler】：可以用來測試CPU消耗所在，了解系統(tǒng)瓶頸、CPU的使用率以及需要優(yōu)化之處。

內(nèi)存測試工具【MemoryTeseter】：可以找到內(nèi)存使用的問題所在，比如內(nèi)存泄露、內(nèi)存碎片、內(nèi)存崩潰等問題。如果發(fā)現(xiàn)系統(tǒng)出現(xiàn)不可預(yù)知或間歇性的問題，就應(yīng)該使用內(nèi)存測試工具進行嘗試。

運行跟蹤器【ExecutionTracer】：可以顯示CPU執(zhí)行了哪些函數(shù)、誰在調(diào)用、參數(shù)是什么、何時調(diào)用等情況，主要用于測試代碼邏輯，可在大量事件中發(fā)現(xiàn)異常。

覆蓋工具【CoverageTester】：主要顯示CPU具體執(zhí)行了哪些代碼，便于了解代碼分支未被執(zhí)行的區(qū)域，有助于提高代碼質(zhì)量并消除無用代碼。

GUI測試工具【GUITester】：大多嵌入式應(yīng)用都帶有某種特定形式的圖形用戶交互界面，部分系統(tǒng)的性能測試是根據(jù)用戶輸入響應(yīng)時間來進行的。GUI測試工具可以作為開發(fā)環(huán)境中運行測試用例的腳本工具，其功能包括對操作的記錄和回放、抓取屏幕顯示供后續(xù)分析比較、設(shè)置和管理測試過程（Rational公司的robot和Mercury的Loadrunner工具是之中的杰出代表）。沒有GUI的嵌入式設(shè)備可通過插裝來運行GUI測試腳本，雖然需要更改被測代碼，但是節(jié)省了功能測試和回歸測試的時間。

嵌入式半實物仿真測試開發(fā)環(huán)境【ETest】：是專門針對嵌入式系統(tǒng)進行測試開發(fā)的工具，系統(tǒng)提供圖形化的測試用例開發(fā)環(huán)境，自動生成測試腳本；測試結(jié)果數(shù)據(jù)可以在線監(jiān)控，同時生成測試結(jié)果信息，并自動生成符合要求的測試報告；ETest為開放性平臺，提供C/C , Python, Lua ，JS等API，圖形化監(jiān)控軟件界面可以根據(jù)用戶需求定制；支持各種國產(chǎn)CPU 國產(chǎn)操作系統(tǒng)的部署方案。工程師可基于ETest為嵌入式設(shè)備快速構(gòu)建測控系統(tǒng)，實現(xiàn)對被測件實時、動態(tài)、閉環(huán)、非侵入式的自動化測試。

二、盡早發(fā)現(xiàn)內(nèi)存問題

內(nèi)存問題存在較大危害且不容易排查，主要有三種類型：內(nèi)存泄露、內(nèi)存碎片和內(nèi)存崩潰。對待內(nèi)存問題必須要明確早發(fā)現(xiàn)、早“治療”的態(tài)度。

內(nèi)存泄漏

內(nèi)存泄露是軟件設(shè)計最常見的內(nèi)存難題，指由于不斷分配的內(nèi)存無法及時地被釋放，逐漸耗盡系統(tǒng)內(nèi)存。即使細心的編程老手也會遭遇內(nèi)存泄露問題，因其一般隱藏很深，很難通過代碼閱讀發(fā)現(xiàn)，甚至可能出現(xiàn)在庫當(dāng)中——有可能庫中本就有bug，也有可能是因為工程師沒有正確理解接口說明文檔而造成了錯用。

大多數(shù)的內(nèi)存泄露雖然無法探測，但會表現(xiàn)為隨機的故障，往往會被認為是硬件問題。如果用戶對系統(tǒng)穩(wěn)定性要求較高，此類問題會導(dǎo)致客戶對產(chǎn)品失去信心，項目也會因此失敗。考慮到內(nèi)存泄漏的巨大危害，現(xiàn)在已有眾多解決工具，通過查找沒有被引用或重復(fù)使用的代碼塊、垃圾內(nèi)存收集、庫跟蹤等技術(shù)來發(fā)現(xiàn)內(nèi)存泄露，盡管每款工具都有利有弊，但還是應(yīng)防患于未然，盡量測試內(nèi)存泄漏。

內(nèi)存碎片

內(nèi)存碎片比內(nèi)存泄露有著更深的隱匿性。隨著內(nèi)存不斷被分配并釋放，大塊內(nèi)存被不斷分解為小塊內(nèi)存，從而形成碎片，后續(xù)需要申請大塊內(nèi)存時就有可能會失敗。系統(tǒng)內(nèi)存夠大或許可能可以堅持較長時間，但最終還是逃不出分配失敗的厄運。在使用動態(tài)分配的系統(tǒng)中，內(nèi)存碎片經(jīng)常發(fā)生。

該問題當(dāng)前最為有效的方法便是使用工具，通過顯示系統(tǒng)內(nèi)存使用情況來找到內(nèi)存碎片的罪魁禍首并進行改進。很多公司為避免動態(tài)內(nèi)存管理問題，會選擇在嵌入式應(yīng)用中禁用malloc/free來以絕后患。

內(nèi)存崩潰

內(nèi)存崩潰是內(nèi)存使用最為嚴重的結(jié)果，主要造成原因有數(shù)組訪問越界、指針計算錯誤、重復(fù)釋放同一段內(nèi)存、釋放非動態(tài)內(nèi)存等。此類問題發(fā)生通常是隨機的，極難事先排查，目前也很少有可供排查的工具。

綜上，使用內(nèi)存管理單元必須要小心謹慎，嚴格遵守其使用規(guī)則。

三、深入理解代碼優(yōu)化

人們對嵌入式系統(tǒng)的關(guān)注點通常在于實時性和速度，這兩個要素直接影響著代碼效率，需要對代碼進行優(yōu)化。了解如何優(yōu)化代碼是每個嵌入式軟件開發(fā)人員必須具備的技能，而優(yōu)化代碼的前提和必要條件則是找到真正需要優(yōu)化之處，然后再對癥下藥。

上文提到的profile能夠記錄如各任務(wù)CPU占用率、優(yōu)先級分配、數(shù)據(jù)拷貝次數(shù)、磁盤訪問次數(shù)、是否調(diào)用網(wǎng)絡(luò)收發(fā)程序、測試代碼是否已經(jīng)關(guān)閉等數(shù)據(jù)，但在分析實時系統(tǒng)性能方面仍有不足。一方面，profile的使用往往是在系統(tǒng)出現(xiàn)問題，即CPU耗盡之后，而profile本身對CPU占用較大，所以很有可能不起作用。根據(jù)Heisenberg效應(yīng)，任何測試手段或多或少都會改變系統(tǒng)運行。

四、不要大海撈針

大海撈針是對調(diào)試的生動比喻。尋找bug時應(yīng)先確實是否在開發(fā)時有過為了尋求捷徑而沒有嚴格遵守編碼設(shè)計規(guī)范的情況，或是沒有檢測部分假設(shè)條件或算法的正確性、沒有將可能存在問題的代碼打上記號?？蓞⒄铡陡哔|(zhì)量c /c編程指南》或《關(guān)于C的0x8本“經(jīng)書”》來學(xué)習(xí)。

為了盡可能地暴露和捕捉問題根源，可以設(shè)計較為全面的錯誤跟蹤代碼：盡可能處理每一個函數(shù)調(diào)用失敗，盡可能檢測每個參數(shù)輸入輸出的有效性，包括指針及是否過多或過少地調(diào)用某個過程。錯誤跟蹤能夠了解bug的大概位置。

五、重視并隔離問題

對于模塊獨立的大型項目，如果問題的出現(xiàn)是間歇性的，則有必要設(shè)法去重現(xiàn)并進行記錄完整過程，以備在下一次出現(xiàn)問題是進行復(fù)用。

確保問題重現(xiàn)后可用隔離的方法來解決問題：用#ifdef把一些可能和問題無關(guān)的代碼關(guān)閉，把系統(tǒng)最小化到仍能夠重現(xiàn)問題的地步。如果還是無法定位問題所在，可以考慮打開“工具箱”：試著用ICE或數(shù)據(jù)監(jiān)視器去查看某個可疑變量的變化；使用跟蹤工具獲得函數(shù)調(diào)用的情況（包括參數(shù)的傳遞）；檢查內(nèi)存是否崩潰以及堆棧溢出的問題。

六、以退為進

獵人為了不使自己在森林里迷路常常會在樹木上留下標記，對過去代碼修改進行跟蹤記錄對將來出現(xiàn)問題之后的調(diào)試也很有幫助。代碼控制系統(tǒng)SCS或代碼控制系統(tǒng)SCS可以很好地解決修改回溯問題，將上個版本checkin下來后和當(dāng)前測試版本比較，可采用SCS/VCS/CVS自帶的diff工具或其他功能更強的比較工具，比如BeyondCompare和ExamDiff。通過比較、分析所有改動代碼，可以得到所有可能導(dǎo)致問題的可疑代碼的分析結(jié)果。

七、確定測試的完整性

覆蓋率測試可供確認CPU到底執(zhí)行了哪些代碼，從而確認測試的完整性。覆蓋率工具有不同的測試級別，用戶可以根據(jù)自己的需要選擇某個級別。

即使單元測試已經(jīng)很全面且沒有deadcode，覆蓋率工具還是可以指出一些潛在問題。

以下方代碼為例：

if(i>=0&& (almostAlwaysZero==0 || (last=i)))

如果almostAlwaysZero為非０，那么last=i賦值語句就被跳過，無法完成目標。

此類問題可輕松通過覆蓋率工具的條件測試功能完成解決，覆蓋率測試工具對提高代碼質(zhì)量是很有幫助的。

八、提高代碼質(zhì)量意味著節(jié)省時間

有研究表明，超過80%的軟件開發(fā)時間被用在下面幾個方面：調(diào)試自己的代碼（單元測試）、調(diào)試自己和其他相關(guān)的代碼（模塊間測試）、調(diào)試整個系統(tǒng)（系統(tǒng)測試），更糟糕的則是可能需要花費10-200倍的時間來找一個最開始時很容易就能發(fā)現(xiàn)的bug。

千里之堤毀于蟻穴，即使bug對整個系統(tǒng)的性能沒有太大的影響，但仍然很可能會影響可以被看得到的部分，必須養(yǎng)成良好的編碼習(xí)慣和測試手段，以求更高的代碼質(zhì)量，縮短代碼的調(diào)試。

九、發(fā)現(xiàn)它，分析它，解決它

世界沒有萬能的膏藥，工具再好用也有無法實現(xiàn)之處，對于隱藏很深、用盡所有工具也無法查到其根源的問題，則需要通過問題的外在表現(xiàn)或數(shù)據(jù)輸出來尋找其中規(guī)律，從而找出異常。任何異常的發(fā)現(xiàn)都應(yīng)深入理解并回溯其根源。

十、請利用初學(xué)者思維

“有些事情在初學(xué)者的腦子里可能有各種各樣的情況，可在專家的頭腦里可能就很單一”，簡單問題想復(fù)雜、簡單系統(tǒng)設(shè)計復(fù)雜很可能就是由于“專家思維”。被問題難住時，不妨換個思路，或許就能得到意想不到的啟發(fā)。

測試工具推薦

嵌入式調(diào)試無疑是一門藝術(shù)，和其它藝術(shù)一樣，想要取得成功就必須具備智慧、經(jīng)驗并懂得使用工具。嵌入式系統(tǒng)半實物仿真測試集成開發(fā)環(huán)境ETest，是面向全過程的自動化測試，以向?qū)У姆绞娇焖俳y試用例，并根據(jù)測試用例自動生成測試腳本，系統(tǒng)根據(jù)測試任務(wù)自動進行測試，減輕測試工程的工作強度。ETest既可以可視化創(chuàng)建狀態(tài)機、通信時序、信號處理等多種可執(zhí)行模型，也可以使用腳本編程實現(xiàn)靈活豐富的動態(tài)控制功能，內(nèi)置百余項API和界面組件，讓測控系統(tǒng)開發(fā)變得輕松、簡單，滿足客戶敏捷化與個性化需求。提供全方位的執(zhí)行過程監(jiān)控，測試過程數(shù)據(jù)自動記錄，并生成符合要求的測試報告。實現(xiàn)高效率、高質(zhì)量的的軟件交付。

本文參考文件：網(wǎng)絡(luò)