基于嵌入式軟件的自動化框架結構研究

李亞偉 萬海濤

（北京賽迪軟件測評工程技術中心有限公司 北京市 100048）

目前大部分軟件開發環境都缺乏整合性的軟件測試工具的輔助，或測試工具僅局限于程序中的特定部分，無法有較完整的測試管理提供一套軟件測試的整合環境，嵌入式系統通常比一般桌面型電腦的軟硬件的資源限制多，因此，在測試嵌入式軟件時，測試者需花費更多的心力來測試及改進嵌入式軟件的質量[1]。此外，傳統的單元測試工具主要針對單一平臺，并且使用人工輸入或自動產生的方法產生測試用例及測試數據；但是自動產生測試用例的方法仍然需要加強，因為大多數的單元測試(unit test)工具都只會自動產生測試用例的程序框架，或只能支持原生的數據類型，使得測試工程師需要手動在產生的程序框架內編寫測試代碼及輸入測試數據，人工產生測試用例[2]。然而，測試工作往往需要重復多次的測試動作，造成工作量的負擔，且以手動輸入測試數據進行測試既沒有效率，對被測軟件本身也是一種變更，容易出錯，也很難提升測試的覆蓋率[3]。在測試執行性能部分，測試工程師很難得知軟件在嵌入式平臺上實際執行的狀況，所以執行性能測試也較為困難。為了降低嵌入式平臺執行測試負荷及減少測試工程師的負擔，本研究建構了一個支持交叉測試的自動化測試工具，其主要區分為功能性測試，包含單元測試、覆蓋率測試，和并行程序的性能測試。

1 測試軟件框架

1.1 系統整體框架

宿主機和目標機的測試框架是面向嵌入式系統設計的一種測試方法。在這個框架下，宿主機(Host)和目標機(Target)之間通過串行通信(Serial Communication)進行交互，利用開發板的JTAG(Joint Test Action Group)接口進行實時調試。該測試框架由以下幾部分組成：

（1）聯機調試：使用JTAG 接口將宿主機和目標機連接起來，進行聯機調試。此時，目標機運行實際代碼，而宿主機則控制測試過程并收集測試結果。

（2）異常處理：當測試過程中出現異常時，需要及時排查，找到問題所在，分析原因并進行修復。

（3）結果分析：分析測試結果，得出測試結論，并對測試程序進行優化和改進。

宿主機和目標機的測試框架具有高效、準確、可重復性強等特點，在嵌入式系統的開發和測試中得到廣泛運用。

宿主機本文使用X86 平臺，目標機為ARM11 MPCore平臺。宿主機中本文使用的開源庫包含了GCOV、Cppunit、Jfreechart、Pin tool、TBB。

1.2 系統核心算法

TBB pipeline 可以讓使用者去決定并行化的程度，此為pipeline token 數，對于選擇一個正確的pipeline token 數需要經驗的累積，若所設定的token 數太小則會限制并行的程度，而token 數太大則會耗費不必要的資源[4]。一般若要找出最佳的pipeline token 數量，測試工程師需要多次手動修改pipeline token 的參數，對此我們提出自動建議一個合適的pipeline token 數量，節省使用者花費額外的時間在測試 pipeline 并行化的效率，并能更精準的提升并行程序的性能[5]。

測試工程師需先選取包含TBB pipeline 函數源代碼，本研究將自動測試程序片段來獲取性能信息，如圖1 所示，包含了TBB 所提供的timer 來獲取pipeline 程序執行時間及取代原程序pipeline 執行的參數(ppline.run(int))使其能代入自動產生的管道令牌號測試用例（pipeline token number test case），最后再借由宿主機-目標機機制來實現自動化測試。當程序執行完，在宿主機會顯示出執行時間的分布圖及CPU 每個核心的使用率，最后我們將會自動分析所收集的測試數據，提供測試工程師一個建議并行化門檻值范圍，使pipeline 并行程序達到較好的性能[6]。

圖1：測試代碼至TBB 并行程序

經過我們多次的分析，我們發現測量token 數量對于程序執行時間的分布大都如圖2 所示，因此我們以五個token 數為單位，計算其平均值，并找出一個建議的token 數范圍，測量的token 數為1～10，我們取token 數1～5 執行時間的平均值為17.6 毫秒，token 數2～6 執行時間的平均值為12.4 毫秒，以此類推，當我們發現下一次的平均值大于目前的平均值(Token No. 4～8 的執行時間為12.4 毫秒大于Token No. 3～7 的執行時間為11.8 毫秒)，我們所建議的token 數為3～7。

圖2：TBB 性能測量時間分布范例

2 測試軟件驗證

本實驗將以TBB pipeline 實現圖像處理程序，并使用4 個CPU core 執行，預處理的圖像大小為128*128 像素，共執行10 種不同的圖像處理主要工作為以不同的算法達到圖像的邊緣化(gradient、laplacian、Prewitt)、去噪音(smooth、median)、去除圖像不連續的接點(erosion/dilation)、細線化(thinning)、旋轉(rotation)及二值化(threshold)；在pipeline 中需循序處理的包含讀取圖像、輸出圖像，可并行處理的為gradient、laplacian、Prewitt、thinning、smooth、median、erosion、dilation、rotation、threshold，測量的stage 數量為1～12，在此我們去比較1～12 stage 的執行時間，并測量出一個建議的pipeline token 數[7]。

圖3、表1 為1-12 個stage 分別輸入1-12 個token數的執行時間，由此可以看出，當使用1 個stage 時效率最差，其次為使用2 個stage，且當 stage 的數量大于3 時，程序所執行的時間都是差不多的。

表1：TBB pipeline 1～12 stage 執行時間

圖3：TBB pipeline 1 ～12 stage 性能測量

由于本實驗其中包含圖像的輸入及輸出，因此只使用1 個stage 及2 個stage 執行pipeline，為循序執行，導致執行的時間較慢，如圖3，而其它stage 數執行的時間的差距不大，表2 為本實驗針對 stage1 至stage12所建議的token 數。

表2：TBB pipeline 1～12 stage 建議的token 數

本文的實驗結果說明了我們所開發的系統是可運作的，而且由于自動及半自動的產生測試數據，自動的產生測試用例及測試驅動的機制，且測試都以可視化界面表現測試結果，能方便并減輕使用者的負擔。實驗說明了在程序執行時可動態監控CPU 使用率，使得測試工程師容易得知軟件在嵌入式板上執行的性能，更容易去改進軟件性能，最后實驗為測試 TBB 并行化的效率，讓測試工程師得知一個建議的token 數，使得測試工程師不需花額外時間測試TBB pipeline 并行化的效率。

3 總結

本研究建構了一個支持嵌入式軟件開發的自動化測試環境系統，此系統能根據分析源代碼后的信息，能夠產生測試用例、測試驅動及支持自動產生元類型，結構類型和對象類型的測試數據，但對于C/C++模板(template)類型、指標類型尚未完全支持。本系統能提供單元測試、覆蓋測試及并行程序(TBB)性能測量及監控，測試結果也能以可視化圖形顯示。此外，我們在ARM11 的多核平臺上做實際的測試，在實驗中，我們針對C/C++數據結構范例程序進行測試，測試結果呈現我們所發展的系統是可運作的；實驗為TBB pipeline 并行效率自動化測試，可使測試工程師不需花額外的時間手動輸入測試數據來測試TBB pipeline 效率，利用我們所開發出來的系統，來減少測試的負擔并增加測試的效率。