在DeltaCORE的測試中，我們采用了較為常用的覆蓋策略——判斷到判斷的路徑，其含義是：DDP是一個指令序列，它的起點是函數或判斷(if，while，……)的入口點，它的出口是下一個函數或判斷的退出點，之間不能再有判斷，比如在圖5中包含了5個DDPs：
測試的具體過程是：
�、倮貌逖b分析器對DeltaCORE的源代碼進行插裝，并生成插裝信息文件。
�、趯⒁浦埠蟮�Logiscope目標機端程序與插裝后的內核源代碼一同編譯鏈接成庫，以替代原來的內核庫，供應用程序使用。
�、茉谒拗鳈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的總體覆蓋率還顯得比較低，需要采用其它的方法來提高它。對于非操作系統組件及應用的測試，由于不存在操作系統本身的問題，因此可望達到較高的覆蓋率。
�、墼摲椒ú荒苡糜跁r間性能測試。因此它屬于純軟件的測試方式，大量數據信息的產生、傳遞與收集對被測程序的干擾大，只能做白盒性的功能結構驗證。如果做性能測試，應采用某些軟硬結合方式的工具，比如CodeTEST。
對嵌入式軟件產品的測試是多方面的，除覆蓋測試外，還有時間性能測試、內存使用測試與分析等，也是我們研究的重要課題。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
