嵌入式軟體測試

如何在目標板上實時測試應用程式

為什麼嵌入式系統測試困難？

在目標板上測試面臨的系列問題：

2、如何累積可重複自動執行的測試

3、如何盡可能減少人工工作

4、如何減少記憶體不夠的問題

這些都是經常碰到但難以解決的問題。隨著專案**越來越大，開發人員數量和**數量都變多，完全懂得目標硬體和軟體工作原理的可能僅限於少數工程師。大多數專案中的工程師面對複雜的系統甚至不知如何在目標裝置上執行測試。

測試什麼**？

解決問題的一種方案是在主機端進行軟體測試。對於那些跟硬體或者交叉編譯無關的**，使用主機平台的編譯器構建可執行測試程式然後執行是可行的，這可以一定程度找到一些邏輯錯誤，但對有些與硬體相關的問題卻無能為力。不同的編譯器，不同的處理器，**執行表現可能存在某些差異，實際上，這也是為什麼對於高安全性軟體的測試需要盡可能在最終環境上進行測試。這意味著在你的測試環境中應該使用與軟體產品環境一致的構建工具和處理器。

除非你直接測試配置到嵌入式裝置上的目標**(object code)，你不能確保不會引入諸如編譯器漏洞，資料對齊以及大小端問題。

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

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

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

1. assert

各種assert，比如asserttrue、比如assertfail、assertstrequals、assertintequals......

條條大路通羅馬，這些assert有各種功能，其實就是包裝了斷言的函式。比如assertstrequals（str, "open"），進行str和字串「open」的比較，如果不相同則會報錯。

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

2. 錯誤位置記錄

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

charbuf[huge_string_len];

sprintf(buf,"%s:%d: ", _file_, _line_);

3. 測試case管理

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

1）setup和teardown

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

2）測試例子彙總

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

3）測試的呼叫

多個測試例程彙總後，構成乙個陣列（**），啟動執行，一般由***run函式負責。

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

4. 測試的執行

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

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

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

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

3）測試需要的各種斷言；

4）斷言失敗後的跳轉、記錄錯誤位置-file-, -line-巨集的使用；

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

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

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

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

測試涵蓋設計文案，實現方式，**框架，需求分析。

動態測試：分階段進行**review，白盒測試，已經最後的產品黑盒測試。

嵌入式測試框架中的乙個特點在開始就是一場探索性的測試方式。「探索性」的思考，「探索性」的測試行為貫穿於整個流程中。探索性測試在嵌入式測試的過程中並不等同於free test；也不是沒有計畫的冒險性測試。需要有測試基礎知識和方**的，制定符合專案階段需求的測試計畫，並且有效實施。

這裡提到的框架是產品設計框架。它將決定測試的內容是在產品實現的每個階段，研發需要給測試提供的介面。

嵌入式軟體開發案例

乙個常規嵌入式軟體開發架構包括下面幾個模組：

1．通訊協議

2．實施系統

3．控制裝置

4．事件處理

5． pc端的工具

6．硬體配置

測試需要搞清楚這些模組之間的關係，任務內容，包括這些模組之間的通訊方法之後才能算對產品系統有一定的了解，之後進一步了解產品需求分析奠定好基礎。

為什麼要學習**結構？**結構中包含了對資料最直觀的定義，比需求分析裡面的資料解釋清楚很多。

就這一句話，測試需要查閱：通訊模組中的傳送函式。在這個介面中將定義出傳送資料的資料結構。有**意識的測試人員看資料結構定義比看文件裡面的文字定義速度快。另外乙個好處，幫助研發完成了乙個內部的code review。

理論上unit test是由研發自己完成的純白盒測試。某論壇上的實踐提議是：在研發人員動手寫方法函式之前，需要完成各自方法函式的unit test方法，之後通過自己搭建的unit test框架結構來實現方法，任何的code變數都會因為unit test的存在及時地反饋給研發人員，從而作到高質量的控制。然後實際過程當中，我們多半遇到的是一堆函式介面，沒有文件，沒有code comments，沒有unit test，這個時候怎麼辦？測試人員在前面兩步的基礎上，可以在這裡幫助研發完成一部分unit test。主要考慮全域性變數的穩定性；引數範圍的準確性和一部分**強壯性的測試。

這部分本身需要研發來實現必要的測試介面，但是主要測試目的還是驗證方法實現與否。最好的情況是，在**級別又測試人員設計介面引數和返回值定義。在執行時，提供對應的測試介面執行方式。為何要說是探索性的測試方法，因為考慮到測試人員的**能力和對產品的需求學習是否正確。那麼在過程中，需要進行一步步探索的方式，吃透黑盒需求，搞清楚**關係，才能完美的完成嵌入式級別**的方法測試。

例如：狀態機測試。狀態機，顧名思義，功能而言就是通過狀態變化完成資訊透傳。對於沒有架構觀念的人直接會跳過狀態機功能測試，直接實現所謂的系統測試，就是通過配置工具直接作用於底層產品的功能測試，這樣雖然節約時間，但是架空的狀態機的測試，最終出現問題時會無法定位問題的根本。

只有把整個產品分模組吃透功能測試之後，進行整合管理發布的流程，才能說，此時發布的產品是可以用於進行黑盒系統測試的產品。

這部分實際工作當中需要分別出：verification和validation。為何要分清楚。只有找到完全負責的物件之後，測試行為才能找到重心。verification的負責物件是研發，即使走黑盒測試，主要目的是看**功能是否完成和基本資料流程是否傳遞並工作。validation的負責物件是使用者，走黑盒測試的目的主要是模擬使用者使用產品流程，不帶破壞性操作的情況下完成系統的效能測試和強度（健壯性）測試。這部分的case的生成依賴第二和第四步。問題來了，在黑盒測試階段我們依據工具完成嵌入式測試嗎？是的，需要依附其他工具。現在每一套嵌入式的工具都會攜帶一部分在pc或者移動裝置上的互動軟體實現操作，也有一部分直接攜帶hmi，那麼我們測試時還需要其他工具嗎？需要！這些工具是這一整套產品，並不是用來給測試人員操作測試核心物件的。說白了，這些配置產品也是測試物件。在研發團隊中需要有人來維護對應的測試工具。這樣的測試工具可以作為配置裝置的測試對比。

能走自動化測試團隊是比較厲害的。在短週期專案中，自動化測試部分只能作用於維護，而對於長週期專案來說，自動化是可以期待回歸測試作用的。本身源於pc端，一直輔助功能的技術在嵌入式測試流程中也只能體現出輔助的功能。可以依據產品屬性來定義自動化測試的存在與否。當產品周期短，實現產品內容繁多，操作複雜就不建議使用自動化測試。自動化測試方法的啟動取決於測試物件，測試工具的發展。並不是團隊自動化技能有否。

嵌入式軟體測試

嵌入式軟體測試

嵌入式軟體測試策略

嵌入式測試

相關推薦