李亞偉 萬(wàn)海濤

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

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

1 測(cè)試軟件框架

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

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

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

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

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

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

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

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

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

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

圖1：測(cè)試代碼至TBB 并行程序

經(jīng)過(guò)我們多次的分析，我們發(fā)現(xiàn)測(cè)量token 數(shù)量對(duì)于程序執(zhí)行時(shí)間的分布大都如圖2 所示，因此我們以五個(gè)token 數(shù)為單位，計(jì)算其平均值，并找出一個(gè)建議的token 數(shù)范圍，測(cè)量的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 性能測(cè)量時(shí)間分布范例

2 測(cè)試軟件驗(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，測(cè)量的stage 數(shù)量為1～12，在此我們?nèi)ケ容^1～12 stage 的執(zhí)行時(shí)間，并測(cè)量出一個(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 性能測(cè)量

由于本實(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)針對(duì) stage1 至stage12所建議的token 數(shù)。

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

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

3 總結(jié)

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