高質(zhì)量嵌入式系統開(kāi)發(fā)的集成測試技術(shù)

探測故障的最佳時(shí)機是在開(kāi)發(fā)過(guò)程的早期。如果使用統一建模語(yǔ)言(UML)，甚至在分析和設計期間就可以發(fā)現故障。

然而，軟件的集成和測試十分困難，嵌入式系統更困難，由于輸入和輸出少，系統的可操作性和可見(jiàn)性都很有限。反常的系統狀態(tài)尤其難以測試，因為在確定系統在某一狀態(tài)下的行為前，必須使系統進(jìn)入該狀態(tài)。

　　本文提出將測試儀器(instrumentation)代碼注入UML模型實(shí)現中的觀(guān)點(diǎn)，目的是提升系統的可控性、可觀(guān)察性和易測性。測試儀器可應用在開(kāi)發(fā)和目標環(huán)境中，并可在模型級進(jìn)行交互式系統調試。在批處理模式下，測試儀器是數據采集、初始化和測試自動(dòng)化的基礎。本文旨在：簡(jiǎn)要介紹基于模型的軟件工程以及這些模型的實(shí)現；概述基于模型的軟件的集成測試方法；確定模型系統內重要的運行時(shí)間數據和執行關(guān)鍵點(diǎn)；闡述在運行時(shí)間采集和操作模型數據的幾種方案；使測試儀器能自動(dòng)進(jìn)行測試。

　　軟件故障是指程序中的錯誤指令或計算，軟件故障的執行將導致軟件狀態(tài)出錯。當錯誤傳到輸出，并作為一個(gè)異常結果呈現在系統外時(shí)，故障就會(huì )發(fā)生。程序的可控性是指一套測試系統強迫被測程序遵循一個(gè)特定執行路徑的能力，也有可能沿這條路徑的執行出錯。程序的可觀(guān)察性是指這套測試系統發(fā)現錯誤狀態(tài)繼而指出故障所在的能力。

　　系統的內部狀態(tài)對于確定測試的正確性至關(guān)重要。系統的輸出是由系統的初始狀態(tài)及其輸入決定的。初始狀態(tài)不同的系統，即便輸入相同，輸出也會(huì )不同。系統的最終狀態(tài)也必須作為評估測試正確性的一部分予以考慮，因為不正確的內部狀態(tài)最終會(huì )傳到系統的輸出，并導致錯誤。系統的復雜性也使得預測系統的正確輸出變得愈加困難。

　　初始狀態(tài)+輸入--->最終狀態(tài)+輸出

　　在“黑匣子”測試方法中，只有系統的外部輸入和輸出可知。需要用一個(gè)特殊的測試激勵序列將錯誤傳給輸出，以便區分錯誤和正確的程序。所需的特殊序列越長(cháng)，程序的可測性就越小。與“黑匣子”相似，嵌入式系統的可控性和可觀(guān)察性也較低。評估最終系統內部狀態(tài)的結果能縮短檢測誤差所需的特殊輸入序列，從而產(chǎn)生更小、更易處理的測試案例。測試儀器力求同時(shí)提高軟件程序的可控性和可觀(guān)察性，以獲得更具可測性的程序。

　　在應用代碼中使用測試支持儀器的技術(shù)是一種“玻璃匣”測試方法。在開(kāi)發(fā)系統的UML模型時(shí)，開(kāi)發(fā)者必須了解系統將要完成的任務(wù)?；跍y試儀器的錯誤隔離策略可以將UML模型的知識運用于集成測試。系統的操作和狀態(tài)在分析級比在編碼級更具可見(jiàn)性，因為后者受到實(shí)現細節的影響。

　　僅從外部輸入設置測試的初始系統狀態(tài)需要特定的外部激勵序列。異常狀態(tài)下的系統操作是很多嵌入式應用中驗證的關(guān)鍵，但生成這些初始狀態(tài)并不簡(jiǎn)單。本文所描述的技術(shù)可利用測試手段，大大提高可控性和可觀(guān)察性。

　　集成測試的步驟

　　集成測試可分成兩個(gè)重要階段，即動(dòng)態(tài)驗證和目標集成。動(dòng)態(tài)驗證是在開(kāi)發(fā)環(huán)境下運行UML模型，其目的在于確定模型的正確性。目標集成涉及到在目標環(huán)境中集成軟件和硬件。動(dòng)態(tài)驗證和目標集成兩者都是在分析級上進(jìn)行的，均使用同樣的工具，即測試支持儀器。

　　要盡可能多地進(jìn)行動(dòng)態(tài)驗證測試，其原因有很多：硬件的可用性、硬件/軟件的分離、更短的調試周期，以及工具的使用。如果在動(dòng)態(tài)驗證的運行測試后，可以確信模型沒(méi)有問(wèn)題，目標集成的調試就可以集中在系統組件之間的接口上，或特定平臺問(wèn)題上。