嵌入式軟件的覆蓋測(cè)試
關(guān)鍵詞:嵌入式操作系統(tǒng) 覆蓋測(cè)試 軟件測(cè)試工具
1 概述
軟件測(cè)試是很廣的概念。從其貫穿軟件生命周期全過(guò)程來(lái)看,測(cè)試可分為模塊測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試等階段。測(cè)試還可分為靜態(tài)檢查和動(dòng)態(tài)運(yùn)行測(cè)試兩大類。在動(dòng)態(tài)運(yùn)行測(cè)試中,又可有基于程序結(jié)構(gòu)的白盒測(cè)試(或稱為覆蓋測(cè)試)和基于功能的黑盒測(cè)試。測(cè)試不僅關(guān)注程序的功能,還有性有測(cè)試、強(qiáng)度測(cè)試等等。
要達(dá)到比較好的測(cè)試效果,除了要有周全的測(cè)試計(jì)劃、可控的測(cè)試過(guò)程、測(cè)試人員豐富的經(jīng)驗(yàn)外,還需要借助一些行之有效的輔助工具,尤其在當(dāng)今軟件規(guī)模日益龐大、測(cè)試工作量成倍增加的情況下。對(duì)應(yīng)上述的測(cè)試分類情況,測(cè)試工具可劃分為:支持對(duì)程序源代碼進(jìn)行靜態(tài)規(guī)則檢查和質(zhì)量評(píng)估的靜態(tài)分析工具、支持對(duì)程序單元進(jìn)行動(dòng)態(tài)覆蓋測(cè)試的工具、對(duì)軟件系統(tǒng)的整體運(yùn)行性能進(jìn)行測(cè)試的工具。另外,還有一些特殊用途的或?qū)S霉ぞ?,如協(xié)議測(cè)試儀、內(nèi)存檢測(cè)工具等。這些工具都有較為成熟的商業(yè)化產(chǎn)品,也可通過(guò)自行開(kāi)發(fā)的方式獲得。
本文具體討論了對(duì)一類特殊的系統(tǒng)軟件——嵌入式實(shí)時(shí)操作系統(tǒng)——進(jìn)行覆蓋測(cè)試的情況。內(nèi)容涉及對(duì)這類軟件特性的研究、測(cè)試的難點(diǎn)和特點(diǎn)、對(duì)現(xiàn)有測(cè)試工具的適應(yīng)性改造和測(cè)試實(shí)例說(shuō)明。
2 軟件覆蓋測(cè)試
覆蓋是一種白盒測(cè)試方法,測(cè)試人員必須擁有程序的規(guī)格說(shuō)明和程序清單,以程序的內(nèi)部結(jié)構(gòu)為基礎(chǔ),來(lái)設(shè)計(jì)測(cè)試案例。其基本準(zhǔn)則是則測(cè)試案例來(lái)盡可能多地覆蓋程序的內(nèi)部邏輯結(jié)構(gòu),發(fā)現(xiàn)其中的錯(cuò)誤和問(wèn)題。所以,覆蓋測(cè)試一般應(yīng)用在軟件測(cè)試的早期,即單元測(cè)試階段。
覆蓋的幾種方法或策略如表1所列。
表1 幾種典型的覆蓋策略
覆蓋策略 | 定 義 |
語(yǔ)句覆蓋 | 在制定測(cè)試案例時(shí),使程序中的每個(gè)語(yǔ)句都至少執(zhí)行1次。其缺點(diǎn)是不能發(fā)現(xiàn)某些邏輯錯(cuò)誤 |
判定覆蓋 | 執(zhí)行足夠的測(cè)試案例,使得程序中每個(gè)判定都獲得一次“真”值和“假”值,或者說(shuō)使每一個(gè)分支都至少通過(guò)1次 |
條件覆蓋 | 執(zhí)行足夠的測(cè)試案例,使得判定中的每個(gè)條件獲得各種可能的結(jié)果 |
判定/條件覆蓋 | 執(zhí)行足夠的測(cè)試案例,使得判定中的每個(gè)條件取得各種可能的值,并使得每個(gè)判定取得各種可能的結(jié)果 |
條件組合覆蓋 | 執(zhí)行足夠的測(cè)試案例,使得每個(gè)判定中的條件的各種組合都至少出現(xiàn)1次。其特點(diǎn)是覆蓋較充分,滿足條件組合覆蓋的測(cè)試案例也一定滿足判定覆蓋、條件覆蓋和判定/條件覆蓋。 |
從以上簡(jiǎn)要介紹可看出,這幾種覆蓋策略的嚴(yán)格程序有如下趨勢(shì):
其它一些覆蓋策略還包括:修改的條件/判斷覆蓋(通常簡(jiǎn)稱為MCDC)、路徑覆蓋、函數(shù)覆蓋、調(diào)用覆蓋、線性代碼順序和跳轉(zhuǎn)覆蓋、數(shù)據(jù)流覆蓋、目標(biāo)代碼分支覆蓋、循環(huán)覆蓋、關(guān)系操作符覆蓋等。隨著軟件規(guī)模的增長(zhǎng),實(shí)現(xiàn)全面的覆蓋所需的測(cè)試案例的數(shù)目也越來(lái)越龐大,因此根據(jù)被測(cè)軟件對(duì)象的特點(diǎn)選擇適當(dāng)?shù)母采w策略是非常重要的;同時(shí),要確定合理測(cè)試目標(biāo),達(dá)到100%的覆蓋往往要付出很大的代價(jià),應(yīng)該同形式化評(píng)審等方法結(jié)合,以發(fā)現(xiàn)更多的軟件故障。
3 覆蓋測(cè)試工具
要取得較好的覆蓋測(cè)試效果,需要借助一定的工具軟件。這些工具軟件一般具備如下的功能特點(diǎn),可彌補(bǔ)人為測(cè)試的缺陷:
①分析軟件內(nèi)部結(jié)構(gòu),幫助制定覆蓋策略及設(shè)計(jì)測(cè)試案例;
②與適當(dāng)?shù)木幾g器結(jié)合,對(duì)被測(cè)軟件實(shí)施自動(dòng)插裝,以便在其運(yùn)行過(guò)程中生成覆蓋信息并收集這些信息;
③根據(jù)搜集的覆蓋信息計(jì)算覆蓋率,幫助測(cè)試人員找到未被覆蓋的軟件部位,以改進(jìn)測(cè)試案例提高覆蓋率。
在利用工具進(jìn)行動(dòng)態(tài)覆蓋測(cè)試時(shí),需要3個(gè)要素:測(cè)試用例、插裝過(guò)的被測(cè)代碼、搜集覆蓋信息并進(jìn)行分析的工具本身。代碼插裝由工具自動(dòng)完成,通過(guò)執(zhí)行測(cè)試用例,再由工具搜集覆蓋信息并進(jìn)行分析,就可以看到覆蓋率指標(biāo)了。圖1展示實(shí)現(xiàn)覆蓋測(cè)試的基本過(guò)程。
4 嵌入式軟件的覆蓋測(cè)試原理
嵌入式軟件的開(kāi)發(fā)與通用軟件很大的不同點(diǎn)在于,需要采用交叉開(kāi)發(fā)的方式:開(kāi)發(fā)工具運(yùn)行在軟硬件配置豐富的宿主機(jī)上,而嵌入式應(yīng)用程序運(yùn)行在軟硬件資源相對(duì)缺乏的目標(biāo)機(jī)上。對(duì)于這類軟件的測(cè)試也存在著同樣的問(wèn)題:測(cè)試工具運(yùn)行在宿主機(jī)上,測(cè)試所需要的信息在目標(biāo)機(jī)上產(chǎn)生,并通過(guò)一定的物理/邏輯連接傳輸?shù)娇s主機(jī)上,由測(cè)試工具接收。因此,嵌入式軟件測(cè)試的一個(gè)重要問(wèn)題是建立宿主機(jī)與目標(biāo)機(jī)之間的物理/邏輯連接,解決數(shù)據(jù)信息的傳輸問(wèn)題。
嵌入式軟件覆蓋測(cè)試的基本原理如圖2所示。
在目標(biāo)機(jī)方,插裝過(guò)的被測(cè)應(yīng)用程序?qū)⒏采w信息發(fā)送到消息隊(duì)列中,一個(gè)專門(mén)的任務(wù)負(fù)責(zé)在適當(dāng)?shù)臅r(shí)候?qū)⑦@些信息發(fā)送到宿主機(jī)方??s主機(jī)方有專門(mén)的模塊負(fù)責(zé)接收覆蓋信息。并交給分析工具分析和在線動(dòng)態(tài)顯示覆蓋率的增長(zhǎng)情況。
支持嵌入式軟件覆蓋測(cè)試的工具應(yīng)解決如下2方面的關(guān)鍵問(wèn)題:
*與嵌入式操作系統(tǒng)的結(jié)合
覆蓋測(cè)試工具與嵌入式操作系統(tǒng)的結(jié)合體現(xiàn)在3方面。首先,在目標(biāo)機(jī)方,應(yīng)用任務(wù)與專門(mén)負(fù)責(zé)收集/上傳覆蓋信息的任務(wù)是通過(guò)消息隊(duì)列來(lái)傳遞數(shù)據(jù)的,該消息隊(duì)列可使用嵌入式操作系統(tǒng)的相應(yīng)機(jī)制實(shí)現(xiàn)。其次,這個(gè)專門(mén)任務(wù)也可以被看作一個(gè)特殊的應(yīng)用任務(wù),也必須有嵌入式操作系統(tǒng)的支持,因?yàn)槿蝿?wù)管理是后者的基本功能之一。最后,目標(biāo)機(jī)與宿主機(jī)之間的通信可以采用串口或以太網(wǎng)方式,對(duì)串口的驅(qū)動(dòng)或網(wǎng)絡(luò)協(xié)議均可使用嵌入式操作系統(tǒng)的相應(yīng)程序組件。
*與其它嵌入式交叉開(kāi)發(fā)工具的關(guān)系
嵌入式應(yīng)用程序的開(kāi)發(fā)通常采用交叉開(kāi)發(fā)方式,幾乎所有的開(kāi)發(fā)工具均要解決3部分的問(wèn)題:宿主機(jī)部分的功能、目標(biāo)機(jī)部分的功能、宿主機(jī)與目標(biāo)機(jī)的連接問(wèn)題。其中,宿主機(jī)與目標(biāo)機(jī)的連接是個(gè)瓶頸,如果不同的工具要使用同一物理線路實(shí)現(xiàn)數(shù)據(jù)傳輸,則要解決對(duì)該物理線路(或者說(shuō)硬件端口)的正確共享。比如在圖3所示的環(huán)境中,宿主機(jī)方的各種工具通過(guò)統(tǒng)一的接口——目標(biāo)服務(wù)器(target server)實(shí)現(xiàn)對(duì)通信線路的訪問(wèn),目標(biāo)機(jī)方的調(diào)試代理(debug agent)則是各種信息(調(diào)試信息、覆蓋信息、時(shí)間信息、對(duì)象信息等)的收集與傳遞的核心。
5 Logiscope在嵌入式操作系統(tǒng)DeltaCORE測(cè)試中的應(yīng)用
Logiscope是Verilog公司的CASE產(chǎn)品,對(duì)軟件的編碼、測(cè)試、維護(hù)提供多方面的服務(wù),并且支持嵌入式軟件的覆蓋測(cè)試。
5.1 測(cè)試前的準(zhǔn)備
測(cè)試前的準(zhǔn)備即為支持對(duì)DeltaCORE的測(cè)試所做的移植工作。
目前,Logiscope已經(jīng)為一些成熟的商用嵌入式操作系統(tǒng)提供了支持,比如pSOS。DeltaCORE是我國(guó)自主開(kāi)發(fā)的嵌入式強(qiáng)實(shí)時(shí)操作系統(tǒng)內(nèi)核,為了利用Logiscope實(shí)現(xiàn)對(duì)DeltaCORE的應(yīng)用程序乃至DeltaCORE本身的測(cè)試,我們主要解決了第4節(jié)中描述的第1個(gè)關(guān)鍵問(wèn)題。
為了支持嵌入式程序的測(cè)試,Logiscope提供了運(yùn)行在目標(biāo)機(jī)方的程序代碼(或稱為目標(biāo)機(jī)端的支持庫(kù)),里面包含了:
*1個(gè)用來(lái)收集和發(fā)送覆蓋信息的主循環(huán)線程,該線程即是嵌入式應(yīng)用中的特殊任務(wù);
*實(shí)現(xiàn)具體數(shù)據(jù)傳輸?shù)暮瘮?shù),包括對(duì)串口或網(wǎng)絡(luò)的驅(qū)動(dòng),它們將被上述線程調(diào)用;
*插裝函數(shù)的實(shí)現(xiàn),這些函數(shù)被被測(cè)代碼調(diào)用,向緩沖中放入覆蓋消息塊;
*對(duì)緩沖信息隊(duì)列的管理;
*初始化代碼。
例如,當(dāng)被測(cè)程序運(yùn)行進(jìn)入到一條if(……)語(yǔ)句時(shí),整個(gè)過(guò)程如圖4所示。
為了支持對(duì)DeltaCORE的測(cè)試,將與這些機(jī)制相關(guān)的代碼進(jìn)行移植,包括以下幾方面:
*將收集和發(fā)送覆蓋信息的主循環(huán)線程作為在目標(biāo)機(jī)端運(yùn)行的應(yīng)用程序中的特殊任務(wù);
*對(duì)串口的驅(qū)動(dòng)采用LambdaTOOL BSP(板級(jí)支持包)中的串口驅(qū)動(dòng)代替,對(duì)網(wǎng)絡(luò)的驅(qū)動(dòng),用DeltaCORE的配套組件DeltaNET中的驅(qū)動(dòng)程序?qū)崿F(xiàn);
*利用DeltaCORE的信箱機(jī)制實(shí)現(xiàn)消息隊(duì)列的創(chuàng)建和管理,插裝代碼向這些信箱發(fā)送覆蓋消息塊;
*在DetaCORE應(yīng)用程序的根任務(wù)中調(diào)用Logiscope的初始化函數(shù),達(dá)到創(chuàng)建特殊任務(wù)信箱的目的。
開(kāi)發(fā)DeltaCORE應(yīng)用程序時(shí),我們使用了其配套開(kāi)發(fā)工具LambdaTOOL。由于所使用的工具版本沒(méi)有實(shí)現(xiàn)目標(biāo)服務(wù)器(target server)的調(diào)試方式,因此對(duì)物理端口的使用采用的獨(dú)占方式,即調(diào)試工具不能與其它工具共享同一端口。我們可以用網(wǎng)絡(luò)試上載并啟動(dòng)目標(biāo)應(yīng)用程序,而通過(guò)串口傳送覆蓋信息。
5.2 對(duì)DeltaCORE的覆蓋測(cè)試過(guò)程及結(jié)果
對(duì)于函數(shù)內(nèi)部,Logiscope支持的覆蓋策略有:
*指令塊IBs(Instruction Blocks)
*判斷到判斷的路徑DDPs(Decision-to-Decision Paths)
*MCDC(Modified Condition/Decision)
在項(xiàng)目層次上支持的覆蓋策略是:
*過(guò)程到過(guò)程路徑PPP(Procedure-to-Procedure Path)
在DeltaCORE的測(cè)試中,我們采用了較為常用的覆蓋策略——判斷到判斷的路徑,其含義是:DDP是一個(gè)指令序列,它的起點(diǎn)是函數(shù)或判斷(if,while,……)的入口點(diǎn),它的出口是下一個(gè)函數(shù)或判斷的退出點(diǎn),之間不能再有判斷,比如在圖5中包含了5個(gè)DDPs:
測(cè)試的具體過(guò)程是:
①利用插裝分析器對(duì)DeltaCORE的源代碼進(jìn)行插裝,并生成插裝信息文件。
②將移植后的Logiscope目標(biāo)機(jī)端程序與插裝后的內(nèi)核源代碼一同編譯鏈接成庫(kù),以替代原來(lái)的內(nèi)核庫(kù),供應(yīng)用程序使用。
③編寫(xiě)測(cè)試案例,從實(shí)現(xiàn)應(yīng)用的角度使用DeltaCORE的各種系統(tǒng)功能調(diào)用,力求遍歷內(nèi)核函數(shù)所有的判定分支,并將這些案例編譯成可執(zhí)行程序。
④在宿主機(jī)端啟動(dòng)覆蓋信息收集和分析程序,用LambdaTOOL的調(diào)試器下載并啟動(dòng)應(yīng)用程序。DeltaCORE的覆蓋信息被傳遞到宿主機(jī)上,分析程序動(dòng)態(tài)顯示覆蓋率的增長(zhǎng)情況,并將這些信息記錄在一個(gè)文件中。
⑤應(yīng)用程序執(zhí)行完畢后,啟動(dòng)Logiscope的事后分析工具,將覆蓋信息記錄文件與插裝信息文件(在源代碼插裝在生成的附屬文件)進(jìn)行比較,幫助測(cè)試人員清晰地了解每個(gè)被測(cè)函數(shù)內(nèi)部的路徑覆蓋情況,借此可為測(cè)試案例的改進(jìn)提供幫助。
⑥測(cè)試人員修改測(cè)試案例,并重新進(jìn)行整個(gè)測(cè)試過(guò)程;各項(xiàng)測(cè)試的結(jié)果可以疊加,覆蓋率將得到增長(zhǎng)。
經(jīng)過(guò)2個(gè)多月的時(shí)間,我們對(duì)DeltaCORE 1.1版本79個(gè)文件共計(jì)115個(gè)函數(shù)進(jìn)行了覆蓋測(cè)試,覆蓋率已經(jīng)達(dá)到了70.55%。編寫(xiě)測(cè)試用例89個(gè),主要的60個(gè)API函數(shù)均已獲得較高的覆蓋,覆蓋率達(dá)100%的約占51.3%。
6 小結(jié)
我們借助Logiscope工具對(duì)嵌入式實(shí)時(shí)操作系統(tǒng)DeltaCORE進(jìn)行了覆蓋測(cè)試,達(dá)到了較好的覆蓋率;發(fā)現(xiàn)并處理了一些缺陷,提高了軟件的質(zhì)量和可靠性,但同時(shí)也存在不足之處:
①測(cè)試應(yīng)好好規(guī)劃,包括測(cè)試順序的選擇、測(cè)試案例的設(shè)計(jì)、測(cè)試文檔的管理等等。
②由于該測(cè)試手段依賴于操作系統(tǒng)的有關(guān)機(jī)制,而被測(cè)對(duì)象又是操作系統(tǒng)本身,因此與這些機(jī)制有關(guān)的部分代碼未被插裝和測(cè)試,否則就會(huì)出錯(cuò)。比如,操作系統(tǒng)的初始化函數(shù)os_init,在這個(gè)函數(shù)運(yùn)行完畢之前,操作系統(tǒng)的相應(yīng)機(jī)制尚未建立起來(lái),因此對(duì)它進(jìn)行插裝就會(huì)造成問(wèn)題,不能正確地得到覆蓋信息。又比如,出于效率方面的考慮,與系統(tǒng)時(shí)鐘相關(guān)的部分函數(shù)未被插裝,因?yàn)樵诔绦蜻\(yùn)行過(guò)程中,時(shí)鐘是最頻繁產(chǎn)生的一種外部事件,如果插裝,就會(huì)產(chǎn)生大量的覆蓋信息,會(huì)對(duì)信息緩存、傳遞、收集和處理造成壓力。另外,所用的工具不支持對(duì)匯編函數(shù)的插裝和測(cè)試。綜合上述各種原因,DeltaCORE 1.1的總體覆蓋率還顯得比較低,需要采用其它的方法來(lái)提高它。對(duì)于非操作系統(tǒng)組件及應(yīng)用的測(cè)試,由于不存在操作系統(tǒng)本身的問(wèn)題,因此可望達(dá)到較高的覆蓋率。
③該方法不能用于時(shí)間性能測(cè)試。因此它屬于純軟件的測(cè)試方式,大量數(shù)據(jù)信息的產(chǎn)生、傳遞與收集對(duì)被測(cè)程序的干擾大,只能做白盒性的功能結(jié)構(gòu)驗(yàn)證。如果做性能測(cè)試,應(yīng)采用某些軟硬結(jié)合方式的工具,比如CodeTEST。
對(duì)嵌入式軟件產(chǎn)品的測(cè)試是多方面的,除覆蓋測(cè)試外,還有時(shí)間性能測(cè)試、內(nèi)存使用測(cè)試與分析等,也是我們研究的重要課題。