嵌入式開發下的單元測試問題--框架解析

　　1.單元測試的必要性

　　單元測試是軟體開發的重要一環，尤其對嵌入式開發。因為嵌入式開發受限於開發環境、除錯工具等因素，不能和純PC軟體開發一樣使用很多先進的工具。這就需要開發者在開發過程中，進行更細的模組劃分，更明確的介面，更詳盡的測試。

　　傳統的開發先出設計方案，然後跟著寫出程式碼，最後在做測試---常被叫做bug除錯，所以在程式碼“寫完”之後，還有一半左右的開發量。人都會犯錯，在設計和編碼中也會犯錯，如果後期除錯程式設計去解決設計和編碼中引入的錯誤，那麼可能已經過了幾天幾周幾個月，反饋如此只晚，已經不能從錯誤中吸取經驗了，下次還會犯同樣的錯誤。此外根據軟體工程理論，1個bug越是在後期越是花費巨大的成本去修復，並且隨著系統複雜度的增長，在一個大的系統中去查詢某一個細節具體的問題，相比於在小的模組中去查詢問題會花費多倍的時間成本。

　　2.單元測試框架解剖

　　一般地單元測試需要實現以下幾個基本功能：

　　1. assert

　　各種assert，比如AssertTrue、比如AssertFail、AssertStrEquals、AssertIntEquals......

　　條條大路通羅馬，這些Assert有各種功能，其實就是包裝了斷言的函式。比如AssertStrEquals(str, "open")，進行str和字串“open”的比較，如果不相同則會報錯。

　　根據框架的結構，在assert失敗時候，有的進行長跳轉longjmp，有的對類似failCount的全域性的變數進行加1並記錄錯誤位置。

　　2. 錯誤位置記錄

　　得益於C語言的LINE、FILE宏，這是2個ANSI C標誌支援的內建宏定義，可以得到當前的的行數和檔名。 在斷言失敗的地方，記錄檔名和行號，以供使用者查詢錯誤的位置。

　　3. 測試case管理

　　這是測試框架區別於自己寫的assert測試函式最根本的地方。 測試框架為了提高函式利用率，減少重複，方便測試例程彙總等，都會進行各種封裝。比如以下幾條。

　　1)setup和teardown

　　大部分的測試框架都提供這兩個函式，主要是因為有些測試case，有大量重複的程式碼，比如準備輸入資料，測試完畢後清理現場等通用的功能。

　　2)測試例子彙總

　　有的叫做TestSuit，有的叫做TestFixtures。把一類相似功能的測試case進行彙總，方便更高層次的呼叫，也方便使用者管理測試例程。

　　3)測試的呼叫

　　多個測試例程彙總後，構成一個陣列(表格)，啟動執行，一般由xxxRun函式負責。

　　在嵌入式c中，一般都有一個函式指標來操作，這也是為什麼所有的測試case的函式名稱都使用相同的宣告，test_case需要和呼叫該測試的指標同型別。

　　4. 測試的執行

　　測試的執行本質就是函式的長跳轉。可以看做在父函式中呼叫子函式，這個子函式如果是測試例程的話，子函式就會包含assert相關的語句，而assert語句在出錯後，會記錄錯位位置和錯誤訊息，然後進行長跳轉(longjmp)，longjmp和setjmp(buf)成對出現，返回到呼叫的位置，然後進行下一個測試case。

　　for (i = 0 ; i < testSuite->count ; ++i)

　　    {

　　        Test* testCase = testSuite->list[i];

　　        TestRun(testCase);

　　        if (testCase->failed) {

　　        testSuite->failCount += 1; 

　　        }

　　    }

　　3. 測試框架的本質

　　1)為了更好的組織測試，提供的測試組的批次處理功能，一般由for迴圈遍歷一個table陣列實現;

　　2)為了減少重複進行測公用函式提取，比如準備測試環境和清理現場;

　　3)測試需要的各種斷言;

　　4)斷言失敗後的跳轉、記錄錯誤位置-FILE-, -LINE-宏的使用;

　　5)測試case執行的監控和結果的彙總。

　　綜上，如果你實現了上面的幾個功能，那麼也就自己完成了一個測試框架。

　　其實測試框架是一個很簡單的事情，如今測試框架有很多，像VS這樣的IDE已經整合了單體測試，所以對於一個開發者怎麼規劃測試才是測試工作的第一要務。

　　如何恰當的寫測試用例，既不延誤開發又不會造成工程臃腫，還能儘可能的覆蓋測試範圍，這才是測試中最花費功夫的地方。

　　本文作者：啊哈彭

　　原文連結：https://www.cnblogs.com/pingwen/p/9206406.html