探測故障的最佳時機是在開發(fā)過程的早期。如果使用統(tǒng)一建模語言（UML），甚至在分析和設(shè)計期間就可以發(fā)現(xiàn)故障。 　　然而，軟件的集成和測試十分困難，嵌入式系統(tǒng)更困難，由于輸入和輸出少，系統(tǒng)的可操作性和可見性都很有限。反常的系統(tǒng)狀態(tài)尤其難以測試，因為在確定系統(tǒng)在某一狀態(tài)下的行為前，必須使系統(tǒng)進(jìn)入該狀態(tài)。 　　本文提出將測試儀器（instrumentation）代碼注入UML模型實現(xiàn)中的觀點，目的是提升系統(tǒng)的可控性、可觀察性和易測性。測試儀器可應(yīng)用在開發(fā)和目標(biāo)環(huán)境中，并可在模型級進(jìn)行交互式系統(tǒng)調(diào)試。在批處理模式下，測試儀器是數(shù)據(jù)采集、初始化和測試自動化的基礎(chǔ)。本文旨在：簡要介紹基于模型的軟件工程以及這些模型的實現(xiàn);概述基于模型的軟件的集成測試方法;確定模型系統(tǒng)內(nèi)重要的運行時間數(shù)據(jù)和執(zhí)行關(guān)鍵點;闡述在運行時間采集和操作模型數(shù)據(jù)的幾種方案;使測試儀器能自動進(jìn)行測試。 　　軟件故障是指程序中的錯誤指令或計算，軟件故障的執(zhí)行將導(dǎo)致軟件狀態(tài)出錯。當(dāng)錯誤傳到輸出，并作為一個異常結(jié)果呈現(xiàn)在系統(tǒng)外時，故障就會發(fā)生。程序的可控性是指一套測試系統(tǒng)強迫被測程序遵循一個特定執(zhí)行路徑的能力，也有可能沿這條路徑的執(zhí)行出錯。程序的可觀察性是指這套測試系統(tǒng)發(fā)現(xiàn)錯誤狀態(tài)繼而指出故障所在的能力。 　　系統(tǒng)的內(nèi)部狀態(tài)對于確定測試的正確性至關(guān)重要。系統(tǒng)的輸出是由系統(tǒng)的初始狀態(tài)及其輸入決定的。初始狀態(tài)不同的系統(tǒng)，即便輸入相同，輸出也會不同。系統(tǒng)的最終狀態(tài)也必須作為評估測試正確性的一部分予以考慮，因為不正確的內(nèi)部狀態(tài)最終會傳到系統(tǒng)的輸出，并導(dǎo)致錯誤。系統(tǒng)的復(fù)雜性也使得預(yù)測系統(tǒng)的正確輸出變得愈加困難。 初始狀態(tài)+輸入——->最終狀態(tài)+輸出 　　在“黑匣子”測試方法中，只有系統(tǒng)的外部輸入和輸出可知。需要用一個特殊的測試激勵序列將錯誤傳給輸出，以便區(qū)分錯誤和正確的程序。所需的特殊序列越長，程序的可測性就越小。與“黑匣子”相似，嵌入式系統(tǒng)的可控性和可觀察性也較低。評估最終系統(tǒng)內(nèi)部狀態(tài)的結(jié)果能縮短檢測誤差所需的特殊輸入序列，從而產(chǎn)生更小、更易處理的測試案例。測試儀器力求同時提高軟件程序的可控性和可觀察性，以獲得更具可測性的程序。 　　在應(yīng)用代碼中使用測試支持儀器的技術(shù)是一種“玻璃匣”測試方法。在開發(fā)系統(tǒng)的UML模型時，開發(fā)者必須了解系統(tǒng)將要完成的任務(wù)?；跍y試儀器的錯誤隔離策略可以將UML模型的知識運用于集成測試。系統(tǒng)的操作和狀態(tài)在分析級比在編碼級更具可見性，因為后者受到實現(xiàn)細(xì)節(jié)的影響。 　　僅從外部輸入設(shè)置測試的初始系統(tǒng)狀態(tài)需要特定的外部激勵序列。異常狀態(tài)下的系統(tǒng)操作是很多嵌入式應(yīng)用中驗證的關(guān)鍵，但生成這些初始狀態(tài)并不簡單。本文所描述的技術(shù)可利用測試手段，大大提高可控性和可觀察性。 集成測試的步驟 　　集成測試可分成兩個重要階段，即動態(tài)驗證和目標(biāo)集成。動態(tài)驗證是在開發(fā)環(huán)境下運行UML模型，其目的在于確定模型的正確性。目標(biāo)集成涉及到在目標(biāo)環(huán)境中集成軟件和硬件。動態(tài)驗證和目標(biāo)集成兩者都是在分析級上進(jìn)行的，均使用同樣的工具，即測試支持儀器。 　　要盡可能多地進(jìn)行動態(tài)驗證測試，其原因有很多：硬件的可用性、硬件/軟件的分離、更短的調(diào)試周期，以及工具的使用。如果在動態(tài)驗證的運行測試后，可以確信模型沒有問題，目標(biāo)集成的調(diào)試就可以集中在系統(tǒng)組件之間的接口上，或特定平臺問題上。 　　a. 用UML建立嵌入式系統(tǒng)模型 　　將UML模型有效地用于嵌入式應(yīng)用的軟件工程，要求開發(fā)進(jìn)程能確保：模型是嚴(yán)格而完整的;在不影響模型的情況下優(yōu)化所生成的系統(tǒng)實現(xiàn);系統(tǒng)的整體結(jié)構(gòu)由進(jìn)程通過多個版本及要求的升級來維持。 　　為達(dá)到這些目標(biāo)，基于模型的軟件工程采用一種轉(zhuǎn)換方法，重點討論采用這種轉(zhuǎn)換方法在代碼中添加測試支持，但該技術(shù)也可應(yīng)用于手工實現(xiàn)的UML模型。這種轉(zhuǎn)換方法的特點將在下文介紹。 　　b. 分析模型 　　分析是針對問題本身為其建立與實現(xiàn)無關(guān)的模型方案的過程。有效的分析模型是嚴(yán)密而完整的，而且與實現(xiàn)方法無關(guān)。UML是由OMG定義的一種標(biāo)準(zhǔn)符號，主要用于表達(dá)分析建模。分析過程可以產(chǎn)生： 　　域（domain）模型：這是一種UML類圖，它將系統(tǒng)分解成獨立的主題區(qū)域，稱為域。這些域由包和從屬箭頭顯示橋表示，其中后者是域之間的需求流（flow of requirement）?？梢詫τ蜻M(jìn)行分析，或者用其它方法開發(fā)，如人工編寫的代碼、繼承代碼、從其它源生成、從某個庫導(dǎo)入等等。域服務(wù)是組成域接口的方法。由于域為某個問題區(qū)定義了完整的規(guī)范，所以可以獨立對其測試，然后再與其它域結(jié)合以便進(jìn)一步測試。 　　信息模型：對于每一個要分析的域來說，UML類圖可用于定義組成該域結(jié)構(gòu)的類（class）。類之間互相關(guān)聯(lián)，還可繼承其它類。 　　情境（scenario）模型：UML序列表或UML協(xié)作圖捕獲某個特定域的主要情境，用于表現(xiàn)域服務(wù)（操作）、類服務(wù)（方法）、類事件消息及該域引用的域外服務(wù)之間的相互作用。 　　狀態(tài)模型：對于接受事件消息的每一個類來說，UML狀態(tài)圖可用于捕捉類周期，并定義該類與狀態(tài)有關(guān)的特性。 　　行為模型：對于每個域服務(wù)、類服務(wù)和狀態(tài)行為，都會生成一個詳細(xì)而明確的行為描述。這由一種行為語言來表達(dá)，這種分析級“編程”語言提供了完整的分析級執(zhí)行基元，而不會影響實現(xiàn)。用行為語言來表示行為細(xì)節(jié)，可以在實現(xiàn)分析基元的轉(zhuǎn)換階段之前保留極大的自由度，這對于優(yōu)化至關(guān)重要。 　　c. 設(shè)計 　　設(shè)計是產(chǎn)生可將分析構(gòu)造映射到運行時間環(huán)境中的策略和機制的過程。其概念與分析不同，大部分初步設(shè)計工作可以在與分析活動無關(guān)的情況下進(jìn)行。 　　d. 轉(zhuǎn)換 　　轉(zhuǎn)換是用設(shè)計策略將每一個要分析域的UML模型映射到實現(xiàn)的過程。設(shè)計分兩個階段進(jìn)行： 　　結(jié)構(gòu)設(shè)計：識別系統(tǒng)的執(zhí)行單元（線程/任務(wù)/進(jìn)程），將其分配至處理器，并將域分配至單元。 　　機械設(shè)計：開發(fā)將分析映射到實現(xiàn)的詳細(xì)模式（用模板描述），并建立基本機制以支持這一實現(xiàn)。