嵌入式軟件的覆蓋測試

關(guān)鍵詞：嵌入式操作系統 覆蓋測試 軟件測試工具

1 概述

軟件測試是很廣的概念。從其貫穿軟件生命周期全過(guò)程來(lái)看，測試可分為模塊測試、集成測試、系統測試等階段。測試還可分為靜態(tài)檢查和動(dòng)態(tài)運行測試兩大類(lèi)。在動(dòng)態(tài)運行測試中，又可有基于程序結構的白盒測試（或稱(chēng)為覆蓋測試）和基于功能的黑盒測試。測試不僅關(guān)注程序的功能，還有性有測試、強度測試等等。

要達到比較好的測試效果，除了要有周全的測試計劃、可控的測試過(guò)程、測試人員豐富的經(jīng)驗外，還需要借助一些行之有效的輔助工具，尤其在當今軟件規模日益龐大、測試工作量成倍增加的情況下。對應上述的測試分類(lèi)情況，測試工具可劃分為：支持對程序源代碼進(jìn)行靜態(tài)規則檢查和質(zhì)量評估的靜態(tài)分析工具、支持對程序單元進(jìn)行動(dòng)態(tài)覆蓋測試的工具、對軟件系統的整體運行性能進(jìn)行測試的工具。另外，還有一些特殊用途的或專(zhuān)用工具，如協(xié)議測試儀、內存檢測工具等。這些工具都有較為成熟的商業(yè)化產(chǎn)品，也可通過(guò)自行開(kāi)發(fā)的方式獲得。

本文具體討論了對一類(lèi)特殊的系統軟件――嵌入式實(shí)時(shí)操作系統――進(jìn)行覆蓋測試的情況。內容涉及對這類(lèi)軟件特性的研究、測試的難點(diǎn)和特點(diǎn)、對現有測試工具的適應性改造和測試實(shí)例說(shuō)明。

2 軟件覆蓋測試

覆蓋是一種白盒測試方法，測試人員必須擁有程序的規格說(shuō)明和程序清單，以程序的內部結構為基礎，來(lái)設計測試案例。其基本準則是則測試案例來(lái)盡可能多地覆蓋程序的內部邏輯結構，發(fā)現其中的錯誤和問(wèn)題。所以，覆蓋測試一般應用在軟件測試的早期，即單元測試階段。

覆蓋的幾種方法或策略如表1所列。

表1 幾種典型的覆蓋策略

從以上簡(jiǎn)要介紹可看出，這幾種覆蓋策略的嚴格程序有如下趨勢：

其它一些覆蓋策略還包括：修改的條件/判斷覆蓋（通常簡(jiǎn)稱(chēng)為MCDC）、路徑覆蓋、函數覆蓋、調用覆蓋、線(xiàn)性代碼順序和跳轉覆蓋、數據流覆蓋、目標代碼分支覆蓋、循環(huán)覆蓋、關(guān)系操作符覆蓋等。隨著(zhù)軟件規模的增長(cháng)，實(shí)現全面的覆蓋所需的測試案例的數目也越來(lái)越龐大，因此根據被測軟件對象的特點(diǎn)選擇適當的覆蓋策略是非常重要的；同時(shí)，要確定合理測試目標，達到100%的覆蓋往往要付出很大的代價(jià)，應該同形式化評審等方法結合，以發(fā)現更多的軟件故障。

3 覆蓋測試工具

要取得較好的覆蓋測試效果，需要借助一定的工具軟件。這些工具軟件一般具備如下的功能特點(diǎn)，可彌補人為測試的缺陷：

①分析軟件內部結構，幫助制定覆蓋策略及設計測試案例；

②與適當的編譯器結合，對被測軟件實(shí)施自動(dòng)插裝，以便在其運行過(guò)程中生成覆蓋信息并收集這些信息；

③根據搜集的覆蓋信息計算覆蓋率，幫助測試人員找到未被覆蓋的軟件部位，以改進(jìn)測試案例提高覆蓋率。

在利用工具進(jìn)行動(dòng)態(tài)覆蓋測試時(shí)，需要3個(gè)要素：測試用例、插裝過(guò)的被測代碼、搜集覆蓋信息并進(jìn)行分析的工具本身。代碼插裝由工具自動(dòng)完成，通過(guò)執行測試用例，再由工具搜集覆蓋信息并進(jìn)行分析，就可以看到覆蓋率指標了。圖1展示實(shí)現覆蓋測試的基本過(guò)程。

4 嵌入式軟件的覆蓋測試原理

嵌入式軟件的開(kāi)發(fā)與通用軟件很大的不同點(diǎn)在于，需要采用交叉開(kāi)發(fā)的方式：開(kāi)發(fā)工具運行在軟硬件配置豐富的宿主機上，而嵌入式應用程序運行在軟硬件資源相對缺乏的目標機上。對于這類(lèi)軟件的測試也存在著(zhù)同樣的問(wèn)題：測試工具運行在宿主機上，測試所需要的信息在目標機上產(chǎn)生，并通過(guò)一定的物理/邏輯連接傳輸到縮主機上，由測試工具接收。因此，嵌入式軟件測試的一個(gè)重要問(wèn)題是建立宿主機與目標機之間的物理/邏輯連接，解決數據信息的傳輸問(wèn)題。

嵌入式軟件覆蓋測試的基本原理如圖2所示。

在目標機方，插裝過(guò)的被測應用程序將覆蓋信息發(fā)送到消息隊列中，一個(gè)專(zhuān)門(mén)的任務(wù)負責在適當的時(shí)候將這些信息發(fā)送到宿主機方?？s主機方有專(zhuān)門(mén)的模塊負責接收覆蓋信息。并交給分析工具分析和在線(xiàn)動(dòng)態(tài)顯示覆蓋率的增長(cháng)情況。

支持嵌入式軟件覆蓋測試的工具應解決如下2方面的關(guān)鍵問(wèn)題：

*與嵌入式操作系統的結合

覆蓋測試工具與嵌入式操作系統的結合體現在3方面。首先，在目標機方，應用任務(wù)與專(zhuān)門(mén)負責收集/上傳覆蓋信息的任務(wù)是通過(guò)消息隊列來(lái)傳遞數據的，該消息隊列可使用嵌入式操作系統的相應機制實(shí)現。其次，這個(gè)專(zhuān)門(mén)任務(wù)也可以被看作一個(gè)特殊的應用任務(wù)，也必須有嵌入式操作系統的支持，因為任務(wù)管理是后者的基本功能之一。最后，目標機與宿主機之間的通信可以采用串口或以太網(wǎng)方式，對串口的驅動(dòng)或網(wǎng)絡(luò )協(xié)議均可使用嵌入式操作系統的相應程序組件。

*與其它嵌入式交叉開(kāi)發(fā)工具的關(guān)系

嵌入式應用程序的開(kāi)發(fā)通常采用交叉開(kāi)發(fā)方式，幾乎所有的開(kāi)發(fā)工具均要解決3部分的問(wèn)題：宿主機部分的功能、目標機部分的功能、宿主機與目標機的連接問(wèn)題。其中，宿主機與目標機的連接是個(gè)瓶頸，如果不同的工具要使用同一物理線(xiàn)路實(shí)現數據傳輸，則要解決對該物理線(xiàn)路（或者說(shuō)硬件端口）的正確共享。比如在圖3所示的環(huán)境中，宿主機方的各種工具通過(guò)統一的接口――目標服務(wù)器（target server）實(shí)現對通信線(xiàn)路的訪(fǎng)問(wèn)，目標機方的調試代理（debug agent）則是各種信息（調試信息、覆蓋信息、時(shí)間信息、對象信息等）的收集與傳遞的核心。

5 Logiscope在嵌入式操作系統DeltaCORE測試中的應用

Logiscope是Verilog公司的CASE產(chǎn)品，對軟件的編碼、測試、維護提供多方面的服務(wù)，并且支持嵌入式軟件的覆蓋測試。

5.1 測試前的準備

測試前的準備即為支持對DeltaCORE的測試所做的移植工作。

目前，Logiscope已經(jīng)為一些成熟的商用嵌入式操作系統提供了支持，比如pSOS。DeltaCORE是我國自主開(kāi)發(fā)的嵌入式強實(shí)時(shí)操作系統內核，為了利用Logiscope實(shí)現對DeltaCORE的應用程序乃至DeltaCORE本身的測試，我們主要解決了第4節中描述的第1個(gè)關(guān)鍵問(wèn)題。

為了支持嵌入式程序的測試，Logiscope提供了運行在目標機方的程序代碼（或稱(chēng)為目標機端的支持庫），里面包含了：

*1個(gè)用來(lái)收集和發(fā)送覆蓋信息的主循環(huán)線(xiàn)程，該線(xiàn)程即是嵌入式應用中的特殊任務(wù)；

*實(shí)現具體數據傳輸的函數，包括對串口或網(wǎng)絡(luò )的驅動(dòng)，它們將被上述線(xiàn)程調用；

*插裝函數的實(shí)現，這些函數被被測代碼調用，向緩沖中放入覆蓋消息塊；

*對緩沖信息隊列的管理；

*初始化代碼。

例如，當被測程序運行進(jìn)入到一條if(……)語(yǔ)句時(shí)，整個(gè)過(guò)程如圖4所示。

為了支持對DeltaCORE的測試，將與這些機制相關(guān)的代碼進(jìn)行移植，包括以下幾方面：

*將收集和發(fā)送覆蓋信息的主循環(huán)線(xiàn)程作為在目標機端運行的應用程序中的特殊任務(wù)；

*對串口的驅動(dòng)采用LambdaTOOL BSP（板級支持包）中的串口驅動(dòng)代替，對網(wǎng)絡(luò )的驅動(dòng)，用DeltaCORE的配套組件DeltaNET中的驅動(dòng)程序實(shí)現；

*利用DeltaCORE的信箱機制實(shí)現消息隊列的創(chuàng )建和管理，插裝代碼向這些信箱發(fā)送覆蓋消息塊；

*在DetaCORE應用程序的根任務(wù)中調用Logiscope的初始化函數，達到創(chuàng )建特殊任務(wù)信箱的目的。

開(kāi)發(fā)DeltaCORE應用程序時(shí)，我們使用了其配套開(kāi)發(fā)工具LambdaTOOL。由于所使用的工具版本沒(méi)有實(shí)現目標服務(wù)器（target server）的調試方式，因此對物理端口的使用采用的獨占方式，即調試工具不能與其它工具共享同一端口。我們可以用網(wǎng)絡(luò )試上載并啟動(dòng)目標應用程序，而通過(guò)串口傳送覆蓋信息。

5.2 對DeltaCORE的覆蓋測試過(guò)程及結果

對于函數內部，Logiscope支持的覆蓋策略有：

*指令塊IBs(Instruction Blocks)

*判斷到判斷的路徑DDPs(Decision-to-Decision Paths)

*MCDC（Modified Condition/Decision）

在項目層次上支持的覆蓋策略是：

*過(guò)程到過(guò)程路徑PPP（Procedure-to-Procedure Path）

在DeltaCORE的測試中，我們采用了較為常用的覆蓋策略――判斷到判斷的路徑，其含義是：DDP是一個(gè)指令序列，它的起點(diǎn)是函數或判斷（if，while，……）的入口點(diǎn)，它的出口是下一個(gè)函數或判斷的退出點(diǎn)，之間不能再有判斷，比如在圖5中包含了5個(gè)DDPs：

測試的具體過(guò)程是：

①利用插裝分析器對DeltaCORE的源代碼進(jìn)行插裝，并生成插裝信息文件。

②將移植后的Logiscope目標機端程序與插裝后的內核源代碼一同編譯鏈接成庫，以替代原來(lái)的內核庫，供應用程序使用。

③編寫(xiě)測試案例，從實(shí)現應用的角度使用DeltaCORE的各種系統功能調用，力求遍歷內核函數所有的判定分支，并將這些案例編譯成可執行程序。

④在宿主機端啟動(dòng)覆蓋信息收集和分析程序，用LambdaTOOL的調試器下載并啟動(dòng)應用程序。DeltaCORE的覆蓋信息被傳遞到宿主機上，分析程序動(dòng)態(tài)顯示覆蓋率的增長(cháng)情況，并將這些信息記錄在一個(gè)文件中。

⑤應用程序執行完畢后，啟動(dòng)Logiscope的事后分析工具，將覆蓋信息記錄文件與插裝信息文件（在源代碼插裝在生成的附屬文件）進(jìn)行比較，幫助測試人員清晰地了解每個(gè)被測函數內部的路徑覆蓋情況，借此可為測試案例的改進(jìn)提供幫助。

⑥測試人員修改測試案例，并重新進(jìn)行整個(gè)測試過(guò)程；各項測試的結果可以疊加，覆蓋率將得到增長(cháng)。

經(jīng)過(guò)2個(gè)多月的時(shí)間，我們對DeltaCORE 1.1版本79個(gè)文件共計115個(gè)函數進(jìn)行了覆蓋測試，覆蓋率已經(jīng)達到了70.55%。編寫(xiě)測試用例89個(gè)，主要的60個(gè)API函數均已獲得較高的覆蓋，覆蓋率達100%的約占51.3%。

6 小結

我們借助Logiscope工具對嵌入式實(shí)時(shí)操作系統DeltaCORE進(jìn)行了覆蓋測試，達到了較好的覆蓋率；發(fā)現并處理了一些缺陷，提高了軟件的質(zhì)量和可靠性，但同時(shí)也存在不足之處：

①測試應好好規劃，包括測試順序的選擇、測試案例的設計、測試文檔的管理等等。

②由于該測試手段依賴(lài)于操作系統的有關(guān)機制，而被測對象又是操作系統本身，因此與這些機制有關(guān)的部分代碼未被插裝和測試，否則就會(huì )出錯。比如，操作系統的初始化函數os_init，在這個(gè)函數運行完畢之前，操作系統的相應機制尚未建立起來(lái)，因此對它進(jìn)行插裝就會(huì )造成問(wèn)題，不能正確地得到覆蓋信息。又比如，出于效率方面的考慮，與系統時(shí)鐘相關(guān)的部分函數未被插裝，因為在程序運行過(guò)程中，時(shí)鐘是最頻繁產(chǎn)生的一種外部事件，如果插裝，就會(huì )產(chǎn)生大量的覆蓋信息，會(huì )對信息緩存、傳遞、收集和處理造成壓力。另外，所用的工具不支持對匯編函數的插裝和測試。綜合上述各種原因，DeltaCORE 1.1的總體覆蓋率還顯得比較低，需要采用其它的方法來(lái)提高它。對于非操作系統組件及應用的測試，由于不存在操作系統本身的問(wèn)題，因此可望達到較高的覆蓋率。

③該方法不能用于時(shí)間性能測試。因此它屬于純軟件的測試方式，大量數據信息的產(chǎn)生、傳遞與收集對被測程序的干擾大，只能做白盒性的功能結構驗證。如果做性能測試，應采用某些軟硬結合方式的工具，比如CodeTEST。

對嵌入式軟件產(chǎn)品的測試是多方面的，除覆蓋測試外，還有時(shí)間性能測試、內存使用測試與分析等，也是我們研究的重要課題。