论文部分内容阅读
摘要：随着应用系统规模增大，功能复杂性增强，对于用于保证软件质量的现有软件测试技术显得越来越力不从心。特别是近几年兴起的基于模型驱动架构的分布式并发系统对软件测试提出了更高的要求。模型驱动测试从系统层面上分析测试系统，根据系统需求说明书和测试任务，设计系统测试模型，生成测试代码，执行测试过程，大大提高了软件测试的效率。本论文基于模型驱动架构设计一个功能简单的货币交换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 = null;
public AgiotagerAdaper () {
_initAgiotagerAdaper();}
private void _initAgiotagerAdaper() {
agios = (new wtp. AgiotagerServicesLocator()).getAgiotagerServices();
if (AgiotagerServices != null ) {
if (_endpoint != null) ((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 == null)
_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.
关键词：面向服务架构；模型驱动测试；模型驱动架构；统一建模测试设置
中图分类号：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 = null;
public AgiotagerAdaper () {
_initAgiotagerAdaper();}
private void _initAgiotagerAdaper() {
agios = (new wtp. AgiotagerServicesLocator()).getAgiotagerServices();
if (AgiotagerServices != null ) {
if (_endpoint != null) ((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 == null)
_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.