從ＵＭＬ設(shè)計(jì)模型到測試模型的研究

摘要：為保證軟件測試與設(shè)計(jì)的一致，分析了UML設(shè)計(jì)模型和UTP測試模型的異同點(diǎn)，提出了從設(shè)計(jì)模型到測試模型的映射過程。通過實(shí)例說明如何從UML設(shè)計(jì)模型轉(zhuǎn)換為UTP測試模型的過程。此方法可為模型驅(qū)動(dòng)體系結(jié)構(gòu)中設(shè)計(jì)模型和測試模型的自動(dòng)轉(zhuǎn)換提供支持。

關(guān)鍵詞：標(biāo)準(zhǔn)建模語言的測試擴(kuò)展;標(biāo)準(zhǔn)建模語言;設(shè)計(jì)模型;測試模型;映射

中圖分類號(hào)：TP311文獻(xiàn)標(biāo)志碼：A

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



0引言

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

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

1基本概念

1．1UML設(shè)計(jì)模型

軟件設(shè)計(jì)階段是設(shè)計(jì)人員設(shè)計(jì)符合需求的設(shè)計(jì)模型的過程。設(shè)計(jì)模型說明了系統(tǒng)是如何實(shí)現(xiàn)的，它主要從結(jié)構(gòu)、行為、約束三個(gè)方面描述系統(tǒng)的功能設(shè)計(jì)。不同的軟件開發(fā)過程，設(shè)計(jì)模型的表示和描述的系統(tǒng)抽象級(jí)別會(huì)有所不同，如瀑布型軟件開發(fā)過程中，設(shè)計(jì)主要分為系統(tǒng)設(shè)計(jì)階段和程序設(shè)計(jì)階段。其中系統(tǒng)設(shè)計(jì)階段的設(shè)計(jì)模型主要包括系統(tǒng)及子系統(tǒng)的結(jié)構(gòu)圖，以及子系統(tǒng)間的交互；RUP中的設(shè)計(jì)主要集中在細(xì)化（Elaboration）階段，產(chǎn)生系統(tǒng)高層體系結(jié)構(gòu)以及系統(tǒng)構(gòu)件詳細(xì)設(shè)計(jì)的草圖；MDA將設(shè)計(jì)模型分為PIM（平臺(tái)無關(guān)模型）和PSM（平臺(tái)相關(guān)模型）。

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

1．2UTP測試模型

軟件測試階段主要驗(yàn)證系統(tǒng)是否實(shí)現(xiàn)了所有需求。測試模型是軟件測試工作的框架，它是建立在特定測試目標(biāo)之上的測試用例集，與設(shè)計(jì)模型描述的形式類似，描述被測軟件系統(tǒng)的結(jié)構(gòu)和行為。



OMG為了增強(qiáng)UML對(duì)測試的支持，2003年接受七個(gè)公司的提案，提出UML 2.0的測試擴(kuò)展（UTP)[6]，目前發(fā)布的版本是UTP已采納的版本。UTP是在歐洲電信聯(lián)盟ETSI的測試標(biāo)準(zhǔn)TTCN3基礎(chǔ)之上，通過擴(kuò)展UML來描述測試行為，支持從單元測試到系統(tǒng)集成測試的不同級(jí)別的測試建模。UTP主要從四個(gè)方面描述測試行為，即測試體系結(jié)構(gòu)(Test Architecture)、測試行為(Test Behavior)、測試數(shù)據(jù)(Test Data)和時(shí)間(Time)，如表1所示。

(1)測試體系結(jié)構(gòu)。它定義了與測試結(jié)構(gòu)和測試配置相關(guān)的概念，主要包括與測試用例集有關(guān)的測試上下文(Test Context)和測試構(gòu)件(Test Components)。測試上下文包含測試用例集、仲裁（Arbitration）接口實(shí)例、被測系統(tǒng)實(shí)例、控制測試用例執(zhí)行的高層行為等。測試上下文中的被測系統(tǒng)（System Under Test，選擇一個(gè)或多個(gè)對(duì)象作為SUT）、測試構(gòu)件（測試系統(tǒng)中與SUT交互的部分）和公用部分（Utility Part，與測試構(gòu)件進(jìn)行交互）共同完成測試。測試中的測試控制由調(diào)度器(Scheduler)負(fù)責(zé)，它實(shí)現(xiàn)測試的創(chuàng)建以及測試系統(tǒng)中測試結(jié)果的管理。每次測試執(zhí)行中測試構(gòu)件的結(jié)果評(píng)估由仲裁器來完成。

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

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

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

2UML設(shè)計(jì)模型與UTP測試模型

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

2．1UML設(shè)計(jì)模型與UTP測試模型的異同

2．1．1UML設(shè)計(jì)模型與UTP測試模型的相似點(diǎn)

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

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

設(shè)計(jì)模型與測試模型描述的是不同領(lǐng)域內(nèi)的概念。兩者除了存在相似的概念外，UTP對(duì)UML進(jìn)行擴(kuò)展來描述測試域。因此UTP中測試目標(biāo)、測試用例執(zhí)行結(jié)果的評(píng)價(jià)等與測試相關(guān)的部分概念無法從UML演化得到。UTP中特有的概念主要包括：

（1）測試目標(biāo)。它是生產(chǎn)測試用例的依據(jù)，通常測試設(shè)計(jì)者指定或者應(yīng)用已有的測試策略，如所有方法覆蓋準(zhǔn)則。

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

（3）確認(rèn)動(dòng)作(Validation Action)。確認(rèn)行為被本地測試構(gòu)件執(zhí)行，其通知判定者判定本地的測試結(jié)果。

（4）測試日志(Test Log)和日志行為(LogAction)。測試日志提供測試執(zhí)行時(shí)的日志項(xiàng)，對(duì)測試過程、測試結(jié)果進(jìn)行進(jìn)一步分析。

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

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

2．2從UML設(shè)計(jì)模型到UTP測試模型的映射

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

(1)測試行為

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

(2)測試體系結(jié)構(gòu)

在測試模型的靜態(tài)結(jié)構(gòu)中首先確定被測對(duì)象，作為測試上下文實(shí)例中的屬性。被測對(duì)象粒度決定了測試類型，即單元測試、集成測試、系統(tǒng)測試。在測試用例中與SUT直接交互的包、構(gòu)件、類為UTP中的測試構(gòu)件，與測試構(gòu)件交互的元素為UTP中的公用部分。這樣一組測試用例所涉及到的被測對(duì)象、測試構(gòu)件、公用部分之間的依賴關(guān)系組成測試配置。SUT、測試構(gòu)件、公用部分的實(shí)例變量作為測試上下文中的屬性，測試用例作為測試上下文實(shí)例中的操作。

(3)測試數(shù)據(jù)

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

(4)時(shí)間

UTP中的時(shí)間約束主要完成特定時(shí)間值發(fā)生時(shí)定時(shí)器產(chǎn)生超時(shí)事件的功能。在設(shè)計(jì)模型的行為圖中對(duì)其元素間的時(shí)間進(jìn)行約束，在默認(rèn)情況下是無時(shí)間約束的。UTP中的定時(shí)器主要是從設(shè)計(jì)模型中的行為圖中獲得。

3案例分析

3．1設(shè)計(jì)模型

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

圖2是順序圖，描述了系統(tǒng)執(zhí)行過程中的一個(gè)場景。

3．2測試模型

(1)測試體系結(jié)構(gòu)

首先確定SUT為動(dòng)態(tài)分析器，測試目標(biāo)為所有接口應(yīng)至少執(zhí)行一次。在QESAT/Java順序圖中選擇與SUT直接交互的構(gòu)件，即用戶界面、項(xiàng)目管理器和結(jié)果顯示器。將這兩個(gè)構(gòu)件作為測試構(gòu)件，結(jié)果顯示構(gòu)件依賴和靜態(tài)分析器為測試提供支持，將這兩個(gè)構(gòu)件作為公用部分。依據(jù)圖1中所描述的這些構(gòu)件間的關(guān)系，對(duì)應(yīng)為如圖3中描述的UTP中構(gòu)件間的關(guān)系。

(2)測試行為

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

(3)測試數(shù)據(jù)

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

4結(jié)束語

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

隨著MDA得到廣泛關(guān)注，模型轉(zhuǎn)換等相關(guān)技術(shù)和工具應(yīng)運(yùn)而生，使從設(shè)計(jì)模型到測試模型的轉(zhuǎn)換以及自動(dòng)生成測試代碼成為可能。在UML設(shè)計(jì)模型與UTP測試模型建立映射規(guī)則的基礎(chǔ)上，形式化描述轉(zhuǎn)換規(guī)則，以及從設(shè)計(jì)模型到測試模型的自動(dòng)實(shí)現(xiàn)將是下一步主要研究的內(nèi)容。

參考文獻(xiàn)：

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

［2］JUDSON S R，F(xiàn)RANCE 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，F(xiàn)raunhofer 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.

注：“本文中所涉及到的圖表、注解、公式等內(nèi)容請(qǐng)以PDF格式閱讀原文”