基于ＳＯＡ的模型驅動測試應用研究

摘要：隨著應用系統規模增大，功能復雜性增強，對于用于保證軟件質量的現有軟件測試技術顯得越來越力不從心。特別是近幾年興起的基于模型驅動架構的分布式并發系統對軟件測試提出了更高的要求。模型驅動測試從系統層面上分析測試系統，根據系統需求說明書和測試任務，設計系統測試模型，生成測試代碼，執行測試過程，大大提高了軟件測試的效率。本論文基于模型驅動架構設計一個功能簡單的貨幣交換Service，闡述模型驅動測試軟件測試過程。

關鍵詞：面向服務架構；模型驅動測試；模型驅動架構；統一建模測試設置

中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)36-2784-03

Abstract: With the scale's increment and functional complexity's rise， it is more difficult to use the existing testing techniques to ensure the qualities of the application systems. Specially in recent years， the distributed concurrent systems based on the Model Driven Architecture are to demand higher requirements on their testing. The methodology of Model Driven Testing should analyze the software system from the system level，design the system testing models ground on the system requirement specification and test task，and then generate test code and execute the system testing. It is proved to raise the software development efficiency. The purpose of the thesis is to describe the detailed process of software testing based on the Model Driven Testing with a simple function Service named Currency Exchange on Model Driven Architecture.

Key words: Service Oriented Architecture; Model Driven Testing; Model Driven Architecture; UML Testing Profile

1 引言

應用系統的規模和功能復雜性在逐年增加，特別是在企業級應用系統中表現的更加突出，中間件技術在解決企業應用系統不同信息管理系統的自治性，異構性，及其之間的交互性以及對以往遺留信息系統的支持方面作出了很大貢獻。然而，隨著多種中間件技術的興起，帶來了跨平臺計算問題。為了實現不同中間件平臺之間的集成和互操作，OMG(Object Management Group)提出了標準的模型驅動架構MDA(Model Driven Architecture)[1]。MDA主要由三部分組成:平臺無關的模型(PIM)，模型轉換器(MT)，特定平臺模型(PSM)，將系統的功能描敘及其系統具體平臺上的實現分離開來，通過模型轉換器實現系統模型到應用代碼的轉換。為了提高對分布式計算和信息系統集成領域的技術支持，OMG提出了功能更加完善的SOA(Service Oriented Architecture)，服務作為一種平臺無關，開放和自治的網絡化構件，使分布式應用具有更好的復用性，靈活性和可擴展性等優勢。伴隨著應用系統的發展變化，為了滿足軟件工程人員對應用系統高質量的保證，軟件測試技術也蓬勃發展起來，軟件測試由最初的全手工輸入的代碼測試，到部分人工參與的半自動化測試及自動化測試(主要是利用各種測試應用工具)，以及近年來逐漸興起的MDT (Model-Driven- Testing)。隨著可視化UML(Unified Modeling- Language)建模工具描述功能的完善和各種功能測試工具的出現，加速了模型驅動測試方法學在現代軟件系統的應用。模型驅動測試極大地減少了軟件生命周期中軟件測試階段的人力勞動和測試時間，縮短了軟件上市時間，提高了軟件質量和開發效率。同時，模型驅動軟件開發和測試方法學都是面向領域建模軟件思想的應用，極大的提高了系統的復用性和軟件開發的生產力。

關于模型驅動測試的研究頗多，其中以AGedis[2]項目研究成果最為突出，文獻[3]提出了模型驅動測試開發方法學和產生了用于模型驅動測試開發的開發工具，文獻[4]側重于用于模型驅動測試開發工具體系架構的研究。雖然基于模型驅動測試的具體應用研究很廣，但多數都是側重于模型驅動測試建模的研究，很少有對模型驅動測試開發應用軟件的研究。然而到目前為止，專門用于模型驅動測試軟件開發的集成開發工具還沒有出現，但應用于模型驅動測試各個開發階段的商業工具卻非常多，基于Eclipse架構面向模型架構軟件開發和模型驅動測試的開源組件和插件工具的發布，使得模型驅動測試軟件開發有了實踐的平臺。本論文就是利

用基于Eclipse架構的OAW和JUnit組件作為應用工具進行模型驅動單個服務測試的研究。下面將分兩大部分來敘述：

2 面向服務架構測試概述

本文是對面向服務架構應用Service的模型驅動測試的研究，所以有必要在這里簡單介紹些面向服務架構和服務及其測試的相關內容。眾所周知，應用系統的測試過程包括下面三個過程：單元測試，集成測試和系統測試。由于面向服務架構的服務具有動態配置，靈活應用的特征，同時，組成應用系統的服務還可能由第三方服務生產廠方提供，這樣使得面向服務應用系統的測試工作難度更大。為了確保應用程序能夠按照預期定義的功能正常運行，我們必須首先對組成服務的單個服務獨立進行測試(即單元測試)，然后對組成業務過程的服務集進行業務處理過程測試(即集成測試，主要是對不同服務之間通信與協作的測試)，最后對整個系統的功能進行測試(即系統測試)。面向服務是指在應用系統業務處理過程當中，系統的整個業務功能被合理的分解成具有一系列相互獨立運行的組件(即服務)，所有的各種服務組成一個服務集合。服務是不依賴于計算機硬件平臺，操作系統及系統開發程序語言的，同時又是異構的，自治的邏輯單元。而我們常提到的面向服務多數指面向web服務，實質上，這只是其得到廣泛應用的一個領域，不能涵蓋其所有內容[1]。面向服務架構是一種分布式，松耦合網絡架構，在這里我們不對它進行詳細全面的介紹，主要介紹其三個最重要標準組件：SOAP(SimpleObjectAccessProtoca-l)，UDDL(UniversalDescription，Definition，an-dIntegration)，WSDL(WebServiceDefinition-Language)。由于本論文側重單個服務的測試，我們將詳細介紹WSDL內容，并在下面以作為案例的agiotagerServices(貨幣兌換服務)進行描述，如下面程序所示。WSDL是一種基于XML的服務描述及服務如何被訪問的定義語言，主要包括下面四個部分:端口類型(portType)，通信消息(message)，類型(types)，端口綁定(bindings)。在一個服務描述文件中，端口通過端口類型元素定義，端口元素描述了服務提供的操作；通信消息用于定義在服務提供方和服務使用方之間傳遞的各種消息；類型描述服務使用的數據類型，端口綁定描敘服務使用的通信協議。面向服務架構軟件系統的單個服務測試包括下面三個方面的內容：1) 測試單個服務的所有服務端口；2) 測試服務端口上的所有操作；3) 測試所有操作使用的數據元素的正確性。

＜?xml version=\"1.0\"?＞

＜definitions name=\"agiotagerServices\"

targetNamespace=\"http://utp.org/agiotagerServices.wsdl\"

xmlns:tns=\"http://utp:org/agiotagerServices.wsdl\"

＜types＞

＜schematargetNamespace=\"http://utp.org/services.xsd\"＞

xmlns:enc=\"http://schemas.xmlsoap.org/soap/encoding/\"

xmlns=\"http://schemas.xmlsoap.org./wsdl/\"＞

＜simpleType name=\"currencyName\"＞

＜restriction base=\"string\"＞

＜enumeration value=\"yuan\"/＞

......

＜/restriction＞

＜simpleType name=\"currencyRate\"＞

＜restriction base=\"float\"＞

＜/restriction＞

＜simpleType name=\"currencyTotal\"＞

＜restriction base=\"float\"＞

＜/restriction＞

＜simpleType name=\"returnCurrency\"＞

＜restriction base=\"float\"＞

＜/restriction＞

＜/types＞

＜message name=\"exchRequest\"＞

＜partname=\"exchingName\"

type=\"tns:currencyName\"＞

name=\"exchedName\" type=\"tns:currencyName\"

name=\"rate\" type=\"tns:currencyRate\"

name=\"total\" type=\"tns:currencyTotal\"

＜/message＞

＜message name=\"exchResponse\"＞

＜part name=\"result\"

type=\"tns:returnCurrency\"＞

＜/message＞

＜portType name=\"agiotagerServices\"＞

＜operation name=\"agiotage\"＞

＜input message=\"exchRequest\"＞

＜output message=\"exchResponse\"＞

＜/operation＞

＜/portType＞

＜/definition＞

3 貨幣交換服務測試

模型驅動測試是指系統分析初期將軟件設計需求分析書與測試規格說明書緊密結合起來產生行為模型，利用測試工具進行自動化測試的過程。系統需求分析說明書詳細定義了系統的功能和系統中各參與角色業務活動，而測試規格說明書描述了系統測試需求及其定義了的一系列測試用例集。軟件測試就是在測試規格說明書的指導下測試應用系統是否滿足它在系統需求分析中的功能定義，并按照預期定義的結果進行顯示。我們在這里將模型驅動測試過程劃分為以下主要三個階段：設計階段，代碼產生階段，和運行階段。在設計階段生成測試規范抽象模型和轉換模板，在代碼產生階段，通過采用代碼產生工具(如TGV，GOTCHA)，將測試規范模型轉換成測試代碼。這兩個過程是獨立于特定平臺，與開發應用系統的特定開發技術無關的。在測試運行階段，則需要利用測試引擎(如JUnit，Fitnesse)去測試給定系統，即測試系統(SUT)。測試系統不單是指一個功能完整的應用系統，有時也可以指單個的功能模塊，或單個的類，甚至類中的一個方法。由于測試系統體系架構，開發語言等的不同直接利用已有的測試引擎去測試各種測試系統是不可能的。這時，我們就需要在選定的測試引擎環境下定義適當的接口類，用于實現測試代碼與測試系統之間的映射，即接口適配器。接口適配器對測試代碼進行了封裝。同時對在軟件測試過程中生成的樁類和仿真類提供支持。在本文中，我們選取一個功能非常簡單的貨幣兌換服務(agiotagerServices)來進行說明，按照前面描述的模型驅動測試的三個階段分三個小節來詳細說明單個服務的測試過程。該服務只有一個不同種貨幣進行兌換的方法，詳細定義如上所示。

3.1 設計階段

在這一階段，我們根據測試系統需求分析說明書對系統測試進行設計，生成測試規范和測試代碼產生模板。其中測試規范模型我們采用OMG對UML進行擴展的UTP(UML Testing Profile)視圖來描述模型驅動測試領域概念：測試系統(SUT)，測試上下文(TestContexts)，測試集(TestSuit)，測試用例(TestCase)。根據模型驅動測試的需要，在遵守U2TP協議的前提下，我們定義了構造型＜＜Assert＞＞，即斷言。它繼承于元類＜＜message＞＞，是模型驅動測試的重要組成部分。斷言擴展了U2TP語義功能，用于判斷測試用例在測試系統下能否通過測試。通過返回的布爾值指示測試成功或測試失敗(情況比較非常復雜，在這不做詳細討論)。在本論文中，測試系統AgiotagerServices是一個只有一個方法的簡單類，構造型＜＜TestContext＞＞用于表示一個包含零到多個測試用例(TestCase)的測試集，定義為AdiotagerTest類。測試用例(TestCase)是指測試系統待測試的方法，被定義成構造型類＜＜TestCase＞＞。每個測試用例都有其對應的行為視圖，如順序圖或活動圖。圖1表示了貨幣兌換的順序圖。

測試用例集中定義的測試用例，在測試運行時通過消息機制依次調用測試系統的相應的功能函數。如在本案例中調用匯率轉換器的方法adiotage(100，dollar，yuan，6.795)，匯率轉換器的一個實例就被創建，它接收傳遞過來的實際參數，執行后將產生的結果傳遞到參與斷言的實例中，參與斷言根據預期設置的值判斷該測試是否通過，輸出測試結果。

3.2 測試代碼產生階段

測試代碼產生階段是利用前一階段生成的測試模型和轉換模板產生測試代碼的過程。然而對于某些測試系統而言，由于產生的測試代碼的不完備性，我們需在測試執行階段定義一些特定數據結構(如多維數組)，保留特定的測試數據值和測試返回值數偶，用以對測試系統進行完備性測試。同時，測試系統本身功能復雜性和及其對測試模型和模板轉換產生不同格式代碼的多功能性，選擇一個功能強大的測試生成工具就變得尤其重要。在本論文中，我們是利用OAW工具集來產生測試代碼。如下所示。

public class AgiotagerTest {

@Test

Public float agiotageTest()

throws RemoteException {

// Definition Bolck

AgiotagerAdaper aper = new AgiotagerAdaper();

// Message Block

assertEquals( 679.5，adiotage(100，dollar，yuan，6.795));

}}

我們可以看到，產生的測試代碼是平臺獨立的。測試集中每個測試用例對應其中一個測試方法，由@Test符號引導。每個測試用例包括兩個部分：定義塊和消息塊。定義塊引用了參與該測試用例順序圖所有類，在需要時創建所需的對象實例。消息塊表示測試用例順序圖參與角色之間調用消息及其傳遞測試結果的斷言。

3.3 測試運行階段

測試運行階段是模型驅動測試的最后一個環節，可以執行在不同平臺上。由于通過測試生成工具產生的測試代碼是不能在測試引擎環境中直接對測試系統進行測試，這就需要我們編寫相應的接口適配器。在這里我們選擇JUnit作為測試引擎，故而我們采用Java語言依照測試代碼編寫agiotagerServices服務接口適配器文件，部分代碼如下所示：

public class AgiotagerAdaper {

private AgiotagerServices agios = 1;

public AgiotagerAdaper () {

_initAgiotagerAdaper();}

private void _initAgiotagerAdaper() {

agios = (new wtp. AgiotagerServicesLocator()).getAgiotagerServices();

if (AgiotagerServices != 1 ) {

if (_endpoint != 1) ((javax.xml.rpc.Stub)AgiotagerServices). _setProperty(\"javax.xml.rpc.service.endpoint.address\"，_endpoint);

else

_endpoint = (String) ((javax.xml.rpc.Stub) converter). _setProperty(\"javax.xml.rpc.service.endpoint.address\");

}

}

Catch (javax.xml.rpx.ServiceException serviceExcption) {}

}

public float adiotage(float currencyTotal，enum currencyName，enum currencyName，float currencyRate) {

if (agios == 1)

_initAgiotagerAdaper();

Return agios. adiotage(float currencyTotal，enum currencyName，enum currencyName，float currencyRate);

}

圖1

測試適配器文件用于對遠程方法調用進行打包，有時也可用于對測試用例初始化進行打包，如數據庫初始化代碼或者對復雜測試狀態判斷的預期值的設定。接口適配器在測試階段的早期，如果測試系統沒有被完整的測試，我們還可以通過接口適配器文件中添加測試內容對其進行補充測試。當然，測試代碼的缺陷我們主要還是通過修改測試模型和測試模板從整體上來進行改進，這也正是模型驅動測試的優勢所在。在軟件測試運行過程中，對于復雜的活動圖，需要根據測試系統的要求，定義參與活動的服務角色樁模塊。在agiotagerServices測試運行過程中，通過在agiotagerServices有目的的修改agiotageTest(float:， enum:， enum:， float:)方法的參數變量，出錯部分都能正確反映輸出的斷言中。

4 結束語

本論文通過一個簡單的貨幣兌換服務，結合模型驅動測試方法學和面向服務架構，對單個服務如何進行模型驅動測試軟件開發過程進行了詳細闡述，為模型驅動測試應用系統開發提供了借鑒作用。然而，本論文主要側重于單個服務的功能測試，而且測試系統簡單，沒有考慮測試系統內部功能模塊及其業務數據結構的復雜性。特別是如何對不同服務組成的業務處理服務集合進行的集成測試，對其的實用性研究還有待后續深入。

參考文獻：

[1] 鮑志云. 解析MDA[M]. 人民郵電出版社，2004.

[2] http://www.agedis.de.

[3] Alan Hartman，Kenneth Nagin. Model Driven Testing-AGEDIS Architecture Interfaces and Tools. IBM Haifa Research Laboratory.

[4] Nuo Li，Qin-qin Ma，Ji Wu，Mao-zhong Jin，Chao Liu. A Framework of Model-Driven Web Application Testing. Proceeding of the 30th Annual international Computer Software and Application Conference 2006 IEEE.