高質量嵌入式系統開發的集成測試技術

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

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

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

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

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

　　初始狀態+輸入--->最終狀態+輸出

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

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

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

　　集成測試的步驟

　　集成測試可分成兩個重要階段，即動態驗證和目標集成。動態驗證是在開發環境下運行UML模型，其目的在于確定模型的正確性。目標集成涉及到在目標環境中集成軟件和硬件。動態驗證和目標集成兩者都是在分析級上進行的，均使用同樣的工具，即測試支持儀器。

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

　　a.用UML建立嵌入式系統模型

　　將UML模型有效地用于嵌入式應用的軟件工程，要求開發進程能確保：模型是嚴格而完整的；在不影響模型的情況下優化所生成的系統實現；系統的整體結構由進程通過多個版本及要求的升級來維持。

　　為達到這些目標，基于模型的軟件工程采用一種轉換方法，重點討論采用這種轉換方法在代碼中添加測試支持，但該技術也可應用于手工實現的UML模型。這種轉換方法的特點將在下文介紹。

　b.分析模型

　　分析是針對問題本身為其建立與實現無關的模型方案的過程。有效的分析模型是嚴密而完整的，而且與實現方法無關。UML是由OMG定義的一種標準符號，主要用于表達分析建模。分析過程可以產生：

　　域(domain)模型：這是一種UML類圖，它將系統分解成獨立的主題區域，稱為域。這些域由包和從屬箭頭顯示橋表示，其中后者是域之間的需求流(flowofrequirement)。可以對域進行分析，或者用其它方法開發，如人工編寫的代碼、繼承代碼、從其它源生成、從某個庫導入等等。域服務是組成域接口的方法。由于域為某個問題區定義了完整的規范，所以可以獨立對其測試，然后再與其它域結合以便進一步測試。

　　信息模型：對于每一個要分析的域來說，UML類圖可用于定義組成該域結構的類(class)。類之間互相關聯，還可繼承其它類。

　　情境(scenario)模型：UML序列表或UML協作圖捕獲某個特定域的主要情境，用于表現域服務(操作)、類服務(方法)、類事件消息及該域引用的域外服務之間的相互作用。

　　狀態模型：對于接受事件消息的每一個類來說，UML狀態圖可用于捕捉類周期，并定義該類與狀態有關的特性。

　　行為模型：對于每個域服務、類服務和狀態行為，都會生成一個詳細而明確的行為描述。這由一種行為語言來表達，這種分析級“編程”語言提供了完整的分析級執行基元，而不會影響實現。用行為語言來表示行為細節，可以在實現分析基元的轉換階段之前保留極大的自由度，這對于優化至關重要。

　　c.設計

　　設計是產生可將分析構造映射到運行時間環境中的策略和機制的過程。其概念與分析不同，大部分初步設計工作可以在與分析活動無關的情況下進行。

　　d.轉換

　　轉換是用設計策略將每一個要分析域的UML模型映射到實現的過程。設計分兩個階段進行：

　　結構設計：識別系統的執行單元(線程/任務/進程)，將其分配至處理器，并將域分配至單元。

　　機械設計：開發將分析映射到實現的詳細模式(用模板描述)，并建立基本機制以支持這一實現。