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

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

探測故障的最佳時機是在開發過程的早期。如果使用統一建模語言(UML)，甚至在分析和設計期間就可以發現故障。然而，軟件的集成和測試十分困難，嵌入式系統更困難，由于輸入和輸出少，系統的可操作性和可見性都很有限。反常的系統狀態尤其難以測試，因為在確定系統在某一狀態下的行為前，必須使系統進入該狀態。

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

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

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

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

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

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

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

集成測試的步驟

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

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

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

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

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

b. 分析模型

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

　域(domain)模型：這是一種UML類圖，它將系統分解成獨立的主題區域，稱為域。這些域由包和從屬箭頭顯示橋表示，其中后者是域之間的需求流(flow of requirement)?？梢詫τ蜻M行分析，或者用其它方法開發，如人工編寫的代碼、繼承代碼、從其它源生成、從某個庫導入等等。域服務是組成域接口的方法。由于域為某個問題區定義了完整的規范，所以可以獨立對其測試，然后再與其它域結合以便進一步測試。
　信息模型：對于每一個要分析的域來說，UML類圖可用于定義組成該域結構的類(class)。類之間互相關聯，還可繼承其它類。
　情境(scenario)模型：UML序列表或UML協作圖捕獲某個特定域的主要情境，用于表現域服務(操作)、類服務(方法)、類事件消息及該域引用的域外服務之間的相互作用。
　狀態模型：對于接受事件消息的每一個類來說，UML狀態圖可用于捕捉類周期，并定義該類與狀態有關的特性。
　行為模型：對于每個域服務、類服務和狀態行為，都會生成一個詳細而明確的行為描述。這由一種行為語言來表達，這種分析級“編程”語言提供了完整的分析級執行基元，而不會影響實現。用行為語言來表示行為細節，可以在實現分析基元的轉換階段之前保留極大的自由度，這對于優化至關重要。

c. 設計

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

d. 轉換

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

　結構設計：識別系統的執行單元(線程/任務/進程)，將其分配至處理器，并將域分配至單元。
　機械設計：開發將分析映射到實現的詳細模式(用模板描述)，并建立基本機制以支持這一實現。

測試儀器與源代碼調試器相似

由于UML模型表示的是完整的可執行系統模型，因而可自動轉換成實現。對模型應用一套轉換法則，其情況與編譯器轉換高級編程語言相似。

語言編譯器和模型編譯器的相似之處在于：模型編譯器可在所生成的代碼中加入測試儀器代碼，正如語言編譯器可以為可執行程序加入符號表和調試信息一樣。為兩種編譯器加入測試儀器可以使開發者在開發的同一抽象級進行測試和調試。高級語言的開發人員大都不愿在調試應用程序時查看匯編或機器代碼。類似地，對于UML模型，開發者也希望在模型的較高抽象級進行調試，而不愿調試實現代碼。

除程序代碼外，轉換方法還要利用UML模型信息來生成代碼，以支持測試。測試儀器代碼并未給軟件增加額外的功能，只是提高了可測試性。測試儀器只提供對測試的支持，但在軟件正常運行時卻不能使用。

由于模型轉換期間加入的測試儀器僅遵循UML模型執行語義，因而它可提供適用于任何應用的通用測試工具?？梢栽诰幾g時將測試儀器分離出來，也可以在沒有測試儀器的情況下重新生成代碼，情況與編譯器處理調試信息類似。

在人工實現的系統中，所需的測試儀器級別依賴于應用的復雜度、測試方法、目標環境、可用內存和其它工具的支持，以及可用的時間等。因此，必須權衡這些因素以按期推出高質量的產品。在UML模型中，必須識別重要的數據值、屬性、輸入和控制點。對每一項都應加入相應的測試儀器訪問接口。下文將敘述如何利用轉換方法添加測試儀器，其原理對手工實現同樣適用。

使用測試儀器的應用結構

UML測試結構分成兩個部分，即動態驗證用戶接口(DVUI)和測試儀器代理程序。DVUI負責為用戶顯示信息并接受用戶命令，可由自動化批接口(batch interface)代替。

測試儀器代理程序是應用系統和DVUI之間的接口。代理程序和DVUI間的通訊機制可能是任何協議，如TCP/IP、RS-232等。代理程序通過所生成的測試儀器代碼匯集信息和通信。它與測試儀器相連，以設置和獲取實例數據，并支持DVUI關于中斷和蹤跡點的通知。它還與事件處理相連，可提供執行控制、系統激勵、中斷點和步進等功能。

數據測試儀器代碼是在轉換過程添加到應用系統的，用以監視和更新目標實例的數量、屬性值、事件隊列數量、事件數據項值和服務參數。

數據訪問

在集成測試和調試期間，評價系統狀態是一個重要步驟。由于系統狀態分布在很多類實例中，DVUI應能獲取系統的所有實例及屬性值。

比較直接的方法是列出系統中實例的清單。每個類必須包括一些結構來保存該類的實例，通常是鏈接清單。在構造器(constructor)內，新的實例加入清單，而在解構器(destructor)內，實例則從清單中刪除。

為了查看實例的狀態，實例還可支持ASCII串行化，與“Java toString()”方法類似?！皌oString()”方法將每一實例的屬性值和與之有關的實例放入字串中。然后，字串就由應用的代理程序傳送至DVUI進行顯示。為了設置實例的數據，還要支持“fromString()”方法以打開數據并正確地進行轉換為屬性賦值。

實例狀態機的狀態在調試過程中也應引起注意，因為它代表了系統控制流程的一個方面。由于它可影響實例對事件的響應，所以很特殊。將狀態機的當前狀態與其它類屬性分開也很有用。

動態行為

在系統執行過程中進行著很多活動：生成和刪除實例并交換事件；生成和刪除關聯；調用域服務；設置并觸發定時器。所有這些活動都應在集成測試中注意。根據實現的不同，每個活動都會觸發交互的中斷點或蹤跡輸出。

DVUI應能將中斷狀態發送給代理程序。中斷可讓DVUI在執行過程中交互式地瀏覽該點的系統狀態，并在必要時調整實例和屬性。蹤跡點也可由DVUI設置。在蹤跡點，描述觸發活動的信息傳送給DVUI并存在日志文件中。蹤跡點是在高層追蹤系統執行情況的好方法。它們甚至可以后處理，以生成描述執行情境的序列圖，也可用于回歸測試。

中斷和蹤跡點控制可以通過發布-訂閱模式實現。代理程序可支持所有類型的應用執行活動的注冊。DVUI可以訂閱這些活動，如某一特定實例的生成或狀態機變換的初始化。當活動發生時，應用代碼內的測試儀器通知代理程序，代理程序再通知訂閱者執行相應的動作、中斷或蹤跡。

用通信狀態機建模的系統實現包含一個事件隊列，由對象從域外發送的事件放在隊列中。事件環不斷執行，將下一事件拉出隊列，并傳送至執行特定行為的目的實例。采用這一實現方法，事件環成為監控系統執行的中樞。

在事件環內加入測試儀器接口可監視經過的事件并查出接收實例應執行的下一狀態。這些狀態可與DVUI設置的中斷和蹤跡點狀態相比較。

事件環中的測試儀器還應支持單事件步進模式。在這種模式下，DVUI命令應用執行一個動作，并在下一動作之前停止。

如果用分析級的執行語句描述UML模型動作和服務，可以用相似的方法編寫代碼，將分步執行事件擴展成分步執行語句。每一句執行語句跟隨一條測試儀器指令，記錄行數和局域變量值。當然，如果用手工操作將非常費時費力，但是通過轉換則很容易實現。

測試的執行

這一部分將闡述在應用中使用測試儀器使測試和故障隔離更簡單的不同方法。

a. 初始化

可以使用測試儀器將系統設置到已知的初始狀態。用代理程序生成和初始化類實例，測試案例可以直接設置狀態。這樣就不必使用一個輸入序列使它達到某種難以到達的狀態，從而簡化了這種狀態下的測試。實例數據越過通信信道串行輸入至代理程序，在這里生成新實例并將其初始化。

軟復位功能還可使系統清零、用其它初始狀態重新初始化，或運行其它測試案例。

b. 激勵

激勵通過測試儀器代理程序從DVUI施加到系統。事件可由DVUI初始化并通過測試儀器代理程序和事件隊列傳送到目標實例，此外，還要派生出事件和數據的一個編碼方案。通過一些額外的編碼，域服務還可以作為系統激勵調用。這一機制與CORBA和RPC在跨越進程調用函數時所用的參數編碼相似。

嵌入式系統中的一大難題是事件的時序或位序引起的故障重現性。通過控制事件在隊列中傳輸的位序，可以測試和重現動作的排序。當然，除觀察事件外，事件隊列的接口還要允許事件的重新排序。

c. 數據采集

數據采集接口可用于考察測試案例之前和之后的狀態。這對于確定和驗證系統的最終狀態(這是評價測試結果的一部分)特別有用。

測試儀器的另一優點是能捕捉真正的目標激勵并在動態驗證環境中重現。如果將測試儀器的某一部分留在最終產品中，它就可以像飛機上的“黑匣子”一樣記錄系統狀態和輸入。

d. 模仿

為了在動態驗證過程中有效地單獨測試域，必須完全了解域邊緣的接口。針對域定義的測試案例通常會使用這一接口作為域的初始激勵。測試案例和激勵數據顯然是專用的，但它使用的是由測試儀器提供的測試工具。

圖1示出了一個測試驅動器，DVUI或其它與測試儀器代理程序相連的程序可模仿域的目標環境。作為測試一部分的類實例由驅動器進行初始化。測試驅動器施加測試激勵并捕捉響應，還可通過捕獲服務調用和替代返回值模仿其它域的響應。從被測域的角度講，調用是一種輸出，測試驅動器的響應能為被測域提供更多輸入。測試驅動器利用被測域中的測試儀器捕獲和替代消息。

從單個域到系統測試

這一測試方案可從單個域擴展到多個域的集合，并直至系統測試(圖2)。利用測試驅動器模仿被測域的環境，單獨域首先被隔離測試。然后，通過域服務的集合將多個域結合起來進行測試，測試驅動器仍然模仿被測域的環境。域之間以服務調用的形式相互聯系的假設現在得到了驗證。對測試邊界間的接口和數據流應有充分的認識。

由于可以確信低級域中很少出現問題，可以在這些域中禁用測試支持儀器，以減少檢測點的數目及提高吞吐量。一旦發現問題，可以重新起用測試支持，以收集個別測試案例的更多數據。

潛在的利用價值

在實現UML模型的過程中使用測試儀器，使得模型可在開發的測試階段得以利用。開發者可以在模型級編寫測試案例、執行和調試模型。在理想情況下，測試儀器應能在分析級提供充分的調試環境，應能對實例、事件和數據進行完全的互動操作，也應有主動激勵系統的方法，而不僅僅是觀察系統。測試儀器在UML建模階段可以充分訪問系統，因此可提高嵌入式系統的透明度，使集成測試更具可觀察性、可控性和可測性。增強的可觀察性可以探測到內部錯誤狀態，而不會將錯誤傳送到輸出端。這樣可將錯誤在離故障點更近的地方隔離出來，從而簡化測試案例的開發，并縮短調試時間。

一旦出現可充分互動的分析調試器，就有可能通過增加批處理功能進一步提高質量和生產率。這種批處理能力可以進行自動回歸測試、自動采集故障測試案例的數據或應用隨機的測試和事件隊列獲取更多的分析結果。

作者簡介：

Gregory Eakman是Pathfinder Solutions公司的首席顧問，現在波士頓大學攻讀基于模型的軟件自動化測試博士學位。他已成功地將基于模型的軟件工程運用到不同的應用中?？赏ㄟ^grege@pathfindersol.com與其聯系。

適用于目標管理結構的統一建模語言UML

統一建模語言(UML)對軟件系統進行詳細說明、形象化處理、架構建立和文擋管理的語言，也適用于業務建模和其他非軟件系統。UML是在大型和復雜系統建模過程中形成的行之有效的最佳工程語言的集合。

目前，下列公司推出支持UML語言的產品：Rational Software、Microsoft、Hewlett-Packard、Oracle、Sterling Software、MCI Systemhouse、Unisys、ICON Computing、IntelliCorp、i-Logix、IBM、ObjecTime、Platinum Technology、Ptech、Taskon、Reich Technologies 以及Softeam。

在構造或創新面向工業控制的軟件系統之前，建立軟件模型恰如為大型建筑規劃藍圖一樣。

優良的模型不僅對于項目組之間的溝通非常重要，而且能夠確保結構的堅固性。隨著系統的復雜性不斷增加，建模技術的重要性也日益增加。影響項目成敗的原因很多，但是嚴格的建模語言標準是項目開發成功所必需的條件之一。

在UML誕生之前，實際上并沒有明確的主導建模語言。用戶要選擇在表達能力上差異很小的多種相似的建模語言。大部分建模語言具備共同的表達符號，盡管它們之間存在細微的差異。

這些差異并沒有提升建摸語言的能力，相反，它妨礙用戶采用形象化的建模語言。

UML之所以適用于目標管理結構OMG(Object Management Architecture)，是因為它通過標準化的技術支持與互操作性和便攜性有關的基本設計任務。

UML建立在OMT、Booch、OSSE和其它重要的建模語言的基礎之上，只要掌握OMT、Booch和OSSE三種語言之一，經過短期培訓就能夠掌握UML。UML的主要好處在于：確保軟件開發項目的成功；不必因項目或組織變更而重新接受培訓和重新選擇設計工具，降低成本；為工具、過程和域的集成提供了一個環境；讓開發工程師能集中精力考慮設計問題。

參考文獻

　Pathfinder Solutions, “MBSE Software Engineering Process”， February 2000: www.pathfindersol.com/download.html.
　Pressman, Roger S.，“Software Engineering-A Practitioner''s Approach”, 3rd Edition. New York: McGraw-Hill, 1992.
　Object Management Group, “The Unified Modeling Language" Specfication”, November 1999: www.omg.org.

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