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

李亞偉 萬海濤

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

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

1 測試軟件框架

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

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

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

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

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

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

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

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

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

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

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

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

圖2：TBB 性能測量時(shí)間分布范例

2 測試軟件驗(yàn)證

本實(shí)驗(yàn)將以TBB pipeline 實(shí)現(xiàn)圖像處理程序，并使用4 個(gè)CPU core 執(zhí)行，預(yù)處理的圖像大小為128*128 像素，共執(zhí)行10 種不同的圖像處理主要工作為以不同的算法達(dá)到圖像的邊緣化(gradient、laplacian、Prewitt)、去噪音(smooth、median)、去除圖像不連續(xù)的接點(diǎn)(erosion/dilation)、細(xì)線化(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í)行時(shí)間，并測量出一個(gè)建議的pipeline token 數(shù)[7]。

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

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

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

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

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

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

3 總結(jié)

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