從ＵＭＬ設計模型到測試模型的研究

摘要：為保證軟件測試與設計的一致，分析了UML設計模型和UTP測試模型的異同點，提出了從設計模型到測試模型的映射過程。通過實例說明如何從UML設計模型轉換為UTP測試模型的過程。此方法可為模型驅動體系結構中設計模型和測試模型的自動轉換提供支持。

關鍵詞：標準建模語言的測試擴展;標準建模語言;設計模型;測試模型;映射

中圖分類號：TP311文獻標志碼：A

文章編號：1001－3695(2007)05－0056－04



0引言

隨著軟件系統的規模和復雜性不斷增長，模型已成為軟件開發過程中的重要產物。2003年OMG提出的模型驅動體系結構（Model Driven Architecture， MDA）[1]更以模型為中心，將模型和實現分離，通過模型轉換器生成程序代碼。模型通常是特定領域的模型，如規格說明的模型、代碼生成的模型、測試的模型。這些模型是根據不同目的提取出的實現體的簡化，反映了系統的不同側面。在軟件開發過程中，設計模型和測試模型是不可缺少的部分，無論是V模型、螺旋(Sprial)模型、統一過程(Unified Process)，還是MDE（Model Driven Engineering，模型驅動開發）。其中設計模型描述了系統開發的藍圖，說明系統是如何實現需求的；測試模型表示在測試目標下的被測對象模型（它可以是系統或系統的一部分），包括測試用例、測試過程和測試腳本等與測試相關的描述。設計模型和測試模型都體現了系統需求，只是應用領域、應用目的不同。因此設計模型與測試模型之間存在很多聯系和差異。

軟件開發過程中，測試與設計過程同步進行，并貫穿于整個系統開發過程。為了保證設計與測試的同步和一致，從設計模型到測試模型的轉換方法將為其提供有力的支持。目前從設計模型到測試模型自動轉換的研究成果不多，更多的研究集中在從設計模型直接生成測試代碼。直接生成測試代碼的優勢在于快速生成測試代碼；不足之處在于缺少對測試的描述，很難復用、演化以及根據用戶需求定制測試代碼。隨著MDA興起，模型轉換技術為快速建立可復用、可擴展、可演化的模型提供支持，從設計模型到測試模型的轉換將成為MDA中的研究方向之一。MDA將模型轉換分為水平轉換和垂直轉換[2]。設計模型到測試模型的轉換屬于水平轉換，水平轉換更多關注于模型間概念的區別與聯系。因此分析設計模型與測試模型間的異同是兩個模型轉換的基礎。文獻[3]提出一套方案來擴展和修改UML設計模型并建立測試模型，通過實例說明如何從UML設計模型生成測試模型；但未對設計模型與測試模型間的元素進行分析，也未給出模型間的轉換規則和實現方式。文獻[4]認為UML與測試是完美的結合，綜述已有的基于UML各個圖的測試方法，介紹了如何將UML中的概念映射到UTP（UML for Testing Profile）中，但未從元模型上指出概念間的映射。由于設計模型與測試模型屬于不同領域，本文未明確指出兩者之間存在的差異。為支持從設計模型到測試模型的轉換，本文分析了設計模型與測試模型之間的區別和聯系，并在此基礎上說明如何實現從設計模型到測試模型的映射。

1基本概念

1．1UML設計模型

軟件設計階段是設計人員設計符合需求的設計模型的過程。設計模型說明了系統是如何實現的，它主要從結構、行為、約束三個方面描述系統的功能設計。不同的軟件開發過程，設計模型的表示和描述的系統抽象級別會有所不同，如瀑布型軟件開發過程中，設計主要分為系統設計階段和程序設計階段。其中系統設計階段的設計模型主要包括系統及子系統的結構圖，以及子系統間的交互；RUP中的設計主要集中在細化（Elaboration）階段，產生系統高層體系結構以及系統構件詳細設計的草圖；MDA將設計模型分為PIM（平臺無關模型）和PSM（平臺相關模型）。

OMG推出的UML已成為可視化面向對象建模語言的工業標準，廣泛用于描述軟件模型。它以簡單、易理解、可視化的方式幫助系統相關人員理解系統并促進相互間的交流。RUP、MDA等建議在軟件開發過程中使用UML為系統開發的不同階段建模。2005年推出的UML 2.0吸取了以往UML改進建議的研究成果[5]，在元模型中針對構件圖添加了結構化類屬、連接件、端口等概念，并強化了構件、接口、協作、模板等機制；行為建模方面，改進了對封裝和伸縮性的支持，去掉了從活動圖到狀態圖的映射，活動圖不再是一種特殊的狀態圖，同時允許形式化地表示狀態機；順序圖增加了交互框(Interaction Frame) 標志，通過增加條件分支和循環等標記方法或改進單個的標記方法，使得繪制順序圖更加容易，并能構建更復雜的現象。為使模型更精確，OMG提出對象約束語言(OCL)約束UML模型，使其無二義性。UML為設計模型的結構、行為、約束提供了精確而詳細的描述方法。

1．2UTP測試模型

軟件測試階段主要驗證系統是否實現了所有需求。測試模型是軟件測試工作的框架，它是建立在特定測試目標之上的測試用例集，與設計模型描述的形式類似，描述被測軟件系統的結構和行為。



OMG為了增強UML對測試的支持，2003年接受七個公司的提案，提出UML 2.0的測試擴展（UTP)[6]，目前發布的版本是UTP已采納的版本。UTP是在歐洲電信聯盟ETSI的測試標準TTCN3基礎之上，通過擴展UML來描述測試行為，支持從單元測試到系統集成測試的不同級別的測試建模。UTP主要從四個方面描述測試行為，即測試體系結構(Test Architecture)、測試行為(Test Behavior)、測試數據(Test Data)和時間(Time)，如表1所示。

(1)測試體系結構。它定義了與測試結構和測試配置相關的概念，主要包括與測試用例集有關的測試上下文(Test Context)和測試構件(Test Components)。測試上下文包含測試用例集、仲裁（Arbitration）接口實例、被測系統實例、控制測試用例執行的高層行為等。測試上下文中的被測系統（System Under Test，選擇一個或多個對象作為SUT）、測試構件（測試系統中與SUT交互的部分）和公用部分（Utility Part，與測試構件進行交互）共同完成測試。測試中的測試控制由調度器(Scheduler)負責，它實現測試的創建以及測試系統中測試結果的管理。每次測試執行中測試構件的結果評估由仲裁器來完成。

(2)測試行為。它定義了測試過程中與動態行為相關的概念，主要是對測試上下文中測試行為的描述。測試行為用操作或行為來表示為完成測試目標(Test Objective)所需的行為和評估。測試目標描述了測試的目的，它通常依附于測試用例或者被測件。在測試中最受關注的是測試用例。一個測試用例可以是一個簡單的操作，也可以是用UML行為圖表示的一組操作序列，在行為圖中表示測試模擬(Test Stimuli)、測試控制/調用(Invocations)、協調(Coordination)、交互對象等與測試用例有關的信息。為了提供更全面、抽象的測試模型，UTP引入了缺省行為(Defaults)描述測試用例行為可觀察的事件中未被明確處理的行為，如異常行為。每個測試用例具有返回值Verdict，預示此次測試用例執行的結果，其值至少包含Pass、Fail、Error和Inconclusive。

(3)測試數據。測試模型中另一個重要方面是測試數據的定義和編碼規則。UTP中的測試數據定義了測試過程中與測試數據相關的概念。測試數據包含通配符（Wildcards）、數據池（Data Pools）、數據劃分（Data Partitions）、數據選擇器（Data Selectors）、編碼規則（Coding Rules）等。數據劃分根據等價類劃分測試數據，這些數據與具體數據值一起組成數據池；數據選擇器根據數據選擇策略選擇數據池中的數據提供給測試用例，以便測試用例的重復執行。對于處理未期望事件或事件包含的不同值，通配符是非常有用的。通配符主要是指：①任意值，表示任意可能值的集合；②任意或可省略值，表示任意值或缺乏的值（在重復范圍從0到上限的情況）。同時UTP引入了代碼規則來表示與SUT交互時測試數據的編碼和解碼方式。

(4)時間。為了建立精確完整的測試模型，UTP提供了與時間相關的定時器和時區的概念。其含義是：①定時器描述控制、管理測試行為，保證測試用例中斷；②時區實現在分布式系統內分組構件，只能在同一個時區內比較時間事件。

2UML設計模型與UTP測試模型

MDA以模型為中心，意味著代碼生成、模擬、確認、測試的自動生成。OMG建議使用UML作為設計模型的表示語言，UTP為測試模型的建模語言。UML是基于MOF的設計模型描述語言，UTP是基于UML和MOF元模型的測試模型描述語言。雖然兩者概念不同，但在元模型上有很多共同之處。分析兩者間的異同，可為從開發到測試的自動轉換提供論證和依據。

2．1UML設計模型與UTP測試模型的異同

2．1．1UML設計模型與UTP測試模型的相似點

設計模型和測試模型主要從結構、行為及約束三個方面建立模型。UML設計模型中的結構圖，包括類圖、對象圖、構件圖、包圖等結構視圖；UTP測試模型中的結構圖是測試用例中與SUT交互的類、對象、構件等組成的測試配置，SUT可以對應到設計模型中類、對象、構件等不同粒度的元素。UML設計模型使用活動圖、交互圖、狀態機圖等描述系統的行為，這些行為視圖是UML元模型中行為（Behavior）的泛化。UTP中的行為主要體現在測試用例上，測試用例描述了SUT與測試構件間的交互。測試用例是UML元模型中Operation和Behavior的泛化，因此UTP中的測試用例可以從UML設計模型中行為視圖的演化來獲得。UTP中的約束主要體現在測試數據和時間上。UTP中的測試數據可以簡單地認為是UML行為視圖中某個約束條件下的行為，測試數據是約束條件的等價劃分；對于時間約束條件，設計模型中的時間圖、順序圖等對其提供支持。UTP與UML在元模型級別上的相似概念如表2所示。

2．1．2UTP測試模型中特有的概念

設計模型與測試模型描述的是不同領域內的概念。兩者除了存在相似的概念外，UTP對UML進行擴展來描述測試域。因此UTP中測試目標、測試用例執行結果的評價等與測試相關的部分概念無法從UML演化得到。UTP中特有的概念主要包括：

（1）測試目標。它是生產測試用例的依據，通常測試設計者指定或者應用已有的測試策略，如所有方法覆蓋準則。

（2）判定(Verdicts)和仲裁（Arbiter）。判定是對被測系統正確性的預定義值，其至少包括Pass（通過）、Inconclusive（測試結果不確定）、Fail（測試結果與期望結果不一致）、Error（測試系統有錯誤或異常）四種測試結果，仲裁根據判定結果評估測試過程。

（3）確認動作(Validation Action)。確認行為被本地測試構件執行，其通知判定者判定本地的測試結果。

（4）測試日志(Test Log)和日志行為(LogAction)。測試日志提供測試執行時的日志項，對測試過程、測試結果進行進一步分析。

（5）完成動作(Finish Action)。構件測試用例行為的完成，不終止構件。

（6）缺省行為（Defaults）。測試過程中，觀察到的未處理的測試行為。

2．2從UML設計模型到UTP測試模型的映射

為保證設計模型和測試模型的一致性，充分驗證系統的需求，根據UTP測試模型與UML設計模型之間的相似點和不同點，給出的映射原則是：對于相似點可以直接從UML設計模型演化到UTP測試模型；對于不同點則應用已有的測試策略，或者給出解決方案完善測試模型。從UML設計模型到UTP測試模型的具體映射過程如下：

(1)測試行為

UTP描述的測試用例包括測試輸入、期望結果、執行條件、執行序列等，它是特定測試目標下測試SUT的技術規格說明。測試用例中各元素的交互來自于設計模型的行為視圖，或者是某個圖的特定場景，或者是不同圖的場景組合。實際測試過程采用UML哪種圖描述交互取決于設計模型中采用何種圖描述用例。測試行為具體映射過程是：①選擇被測對象作為SUT；②確定測試目標，如將UML狀態圖中的每個狀態、每個遷移，活動圖中的每個活動，交互圖中的執行順序等作為UTP中的測試目標；③選擇行為設計圖中的相應元素獲得測試用例中SUT和測試構件間的交互序列；④分解UML中狀態、活動、交互的前置條件作為測試用例中的測試數據，其后置條件作為測試期望結果；⑤根據每次執行過程中測試構件和SUT可能出現的結果與期望結果的比較，設置相應的判定值；⑥測試用例中測試構件和SUT的交互序列來自于行為設計模型中的元素間交互順序，可由測試控制器控制其執行。

(2)測試體系結構

在測試模型的靜態結構中首先確定被測對象，作為測試上下文實例中的屬性。被測對象粒度決定了測試類型，即單元測試、集成測試、系統測試。在測試用例中與SUT直接交互的包、構件、類為UTP中的測試構件，與測試構件交互的元素為UTP中的公用部分。這樣一組測試用例所涉及到的被測對象、測試構件、公用部分之間的依賴關系組成測試配置。SUT、測試構件、公用部分的實例變量作為測試上下文中的屬性，測試用例作為測試上下文實例中的操作。

(3)測試數據

UTP中通配符、數據池、數據劃分主要來源于行為圖中的元素約束條件。分解約束條件為數據池中的不同數據范圍，并將不同的數據范圍與不同的測試行為關聯。數據選擇器是根據不同測試策略從相應數據池或數據劃分中獲得數據。其中的測試策略如等價類劃分、隨機測試、邊界值等。

(4)時間

UTP中的時間約束主要完成特定時間值發生時定時器產生超時事件的功能。在設計模型的行為圖中對其元素間的時間進行約束，在默認情況下是無時間約束的。UTP中的定時器主要是從設計模型中的行為圖中獲得。

3案例分析

3．1設計模型

下面以北京航空航天大學軟件工程研究所開發的QESAT/Java為例，說明如何從UML設計模型到測試模型的轉換過程。QESAT/Java是Java軟件的分析和測試工具集，可對源代碼程序進行靜態結構分析和運行時動態分析，并支持軟件開發過程中的多種測試，如開發階段的單元測試和集成測試，同時支持黑盒的功能測試和白盒的覆蓋率測試，提供多種形式的覆蓋率報告，包括語句覆蓋、分支覆蓋、類覆蓋等。QESAT/Java主要由四個構件組成，即結果顯示器（各種測試結果的顯示視圖）、靜態分析器（分析源程序，獲得程序信息）、動態分析器（對程序植入探針，獲得程序執行信息）、用戶界面和項目管理器（負責項目信息管理，協調各個構件完成系統的功能）。如圖1所示，使用構件圖描述系統中各個構件的關系。

圖2是順序圖，描述了系統執行過程中的一個場景。

3．2測試模型

(1)測試體系結構

首先確定SUT為動態分析器，測試目標為所有接口應至少執行一次。在QESAT/Java順序圖中選擇與SUT直接交互的構件，即用戶界面、項目管理器和結果顯示器。將這兩個構件作為測試構件，結果顯示構件依賴和靜態分析器為測試提供支持，將這兩個構件作為公用部分。依據圖1中所描述的這些構件間的關系，對應為如圖3中描述的UTP中構件間的關系。

(2)測試行為

以測試動態分析器中的execute()方法為例，說明如何生成測試用例的描述。在順序圖中，找到從測試構件到SUT發送的消息中的execute()方法，并選擇執行此方法的整個場景作為測試用例，其中的執行條件為dir非空，如圖4所示。如果執行過程中能捕獲到firedRunFinished消息，則將判定設為Pass；否則判定設為Fail，如圖5所示。最后將測試構件和公用部分所引入的方法和執行順序作為測試上下文中的測試用例描述。

(3)測試數據

本文采用等價類劃分作為測試數據的劃分規則。根據設計模型中順序圖交互時的約束條件產生兩類數據：①合法數據，即dir不為空的情況；②不合法數據，即dir為空的情況。在合法數據條件下，測試人員可以根據構件實際功能擴充測試數據，添加如接口文件、循環語句文件等，作為合法數據下的不同劃分，這些數據作為等價類分別放入數據池中，如圖4所示。

4結束語

通過介紹UML和UTP中的相關概念，分析UML設計模型和UTP測試模型的異同。為了保證設計模型與測試模型的一致性，本文提出對兩類模型中相似概念直接提供從設計模型映射到測試模型，對測試模型特有的概念，或者將已有的測試策略應用到映射過程中，或者由測試設計人員指定。通過案例分析顯示了建立測試模型框架的基本過程。北航軟件所以往的研究主要是針對活動圖來生成測試用例，為從設計模型的結構和行為視圖生成測試模型做了基礎性工作。

隨著MDA得到廣泛關注，模型轉換等相關技術和工具應運而生，使從設計模型到測試模型的轉換以及自動生成測試代碼成為可能。在UML設計模型與UTP測試模型建立映射規則的基礎上，形式化描述轉換規則，以及從設計模型到測試模型的自動實現將是下一步主要研究的內容。

參考文獻：

［1］MDA[EB/OL].[2003].http://www.omg.org/mda.

［2］JUDSON S R，FRANCE R B，CARVER D L.Specifying model transformations at the metamodel level:proceedings of the Workshop in Software Model Engineering (WiSME)[C].San Francisco:[s.n.]，2003.

［3］DAI Zhenru，GRABOWSKI J，NEUKIRCHEN H，et al.From design to test with UML:applied to a roaming algorithm for bluetooth devices:TestCom[C].[S.l.]:[s.n.]，2004:33－49.

［4］GROSS H.Testing and the UML:a perfect fit，Fraunhofer IESE Report 110.03E[R].[S.l.]:[s.n.]，2003.

［5］UML 2. 0 superstructure specification[EB/OL].http://www.omg.org/cgi－bin/apps/doc?formal/05－07－04.pdf.

［6］UTP， UML 2.0 testing profile:final adopted specification[EB/OL]. http://www.omg.org/cgi－bin/apps/doc?ptc/04－04－02.pdf.

注：“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”