基于嵌入式軟件的自動化框架結(jié)構(gòu)研究

李亞偉 萬海濤

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

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

1 測試軟件框架

1.1 系統(tǒng)整體框架

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

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

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

（3）結(jié)果分析：分析測試結(jié)果，得出測試結(jié)論，并對測試程序進行優(yōu)化和改進。

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

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

1.2 系統(tǒng)核心算法

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

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

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

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

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

2 測試軟件驗證

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

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

表1：TBB pipeline 1～12 stage 執(zhí)行時間

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

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

表2：TBB pipeline 1～12 stage 建議的token 數(shù)

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

3 總結(jié)

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