嵌入式軟件的覆蓋測試(3)

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

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

　　*初始化代碼。

　　例如，當被測程序運行進入到一條if(……)語句時，整個過程如圖4所示。

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

　　*將收集和發送覆蓋信息的主循環線程作為在目標機端運行的應用程序中的特殊任務;

　　*對串口的驅動采用LambdaTOOL BSP(板級支持包)中的串口驅動代替，對網絡的驅動，用DeltaCORE的配套組件DeltaNET中的驅動程序實現;

　　*利用DeltaCORE的信箱機制實現消息隊列的創建和管理，插裝代碼向這些信箱發送覆蓋消息塊;

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

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

　　5.2 對DeltaCORE的覆蓋測試過程及結果

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

　　*指令塊IBs(Instruction Blocks)

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

　　*MCDC(Modified Condition/Decision)

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

　　*過程到過程路徑PPP(Procedure-to-Procedure Path)

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

　　測試的具體過程是：

　?、倮貌逖b分析器對DeltaCORE的源代碼進行插裝，并生成插裝信息文件。

　?、趯⒁浦埠蟮腖ogiscope目標機端程序與插裝后的內核源代碼一同編譯鏈接成庫，以替代原來的內核庫，供應用程序使用。

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

　?、茉谒拗鳈C端啟動覆蓋信息收集和分析程序，用LambdaTOOL的調試器下載并啟動應用程序。DeltaCORE的覆蓋信息被傳遞到宿主機上，分析程序動態顯示覆蓋率的增長情況，并將這些信息記錄在一個文件中。

　?、輵贸绦驁绦型戤吅?，啟動Logiscope的事后分析工具，將覆蓋信息記錄文件與插裝信息文件(在源代碼插裝在生成的附屬文件)進行比較，幫助測試人員清晰地了解每個被測函數內部的路徑覆蓋情況，借此可為測試案例的改進提供幫助。

　?、逌y試人員修改測試案例，并重新進行整個測試過程;各項測試的結果可以疊加，覆蓋率將得到增長。

　　經過2個多月的時間，我們對DeltaCORE 1.1版本79個文件共計115個函數進行了覆蓋測試，覆蓋率已經達到了70.55%。編寫測試用例89個，主要的60個API函數均已獲得較高的覆蓋，覆蓋率達100%的約占51.3%。

　　6 小結

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

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

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

原文轉自：http://www.anti-gravitydesign.com