针对模型转换程序的蜕变测试方法研究*

余　恒，贲可荣

海军工程大学 计算机工程系，武汉 430033

针对模型转换程序的蜕变测试方法研究*

余恒，贲可荣+

海军工程大学 计算机工程系，武汉 430033

YU Heng,BEN Kerong.Research on metamorphic testing for model transformation program.Journal of Frontiers of Computer Science and Technology,2016,10(7):915-923.

模型驱动架构中模型转换结果正确与否常常难以判断（即测试Oracle问题），而蜕变测试通过验证多个执行结果之间是否满足蜕变关系可以部分地解决测试Oracle问题。为有效地解决模型转换测试中的Oracle问题，以UML到Java模型转换程序为例，应用蜕变测试，依据转换规则，从增加、删除、修改、替换4个方面设计并构造出一组蜕变关系。最后对待测程序植入在实际测试中常见的两种错误，设计并执行测试用例后验证蜕变关系，发现违反了蜕变关系，暴露出程序缺陷，从而说明了蜕变测试的有效性。

模型转换；软件测试；测试Oracle；蜕变测试；蜕变关系

1　引言

模型驱动架构（model driven architecture，MDA）[1-2]是国际管理组织OMG提出的一种以模型为中心的软件开发框架。模型转换是MDA的关键技术[3]，也是MDA的研究热点,它将模型在不同语言或者不同抽象等级之间进行转换。在这种方式下，模型能够自动转换、提取，直到生成最终的软件代码。MDA的成功依赖于正确的模型转换程序，因为错误的模型转换程序会导致生成错误的模型，以致最终生成错误的软件代码。

软件测试[4]是一种辅助验证模型转换程序正确性的技术。模型转换测试中一大挑战就是测试Oracle问题：通常难以获得模型转换程序的测试Oracle[5]。蜕变测试（metamorphic testing，MT）可以部分解决软件测试中的Oracle问题[6]，它通过检测输出之间的某种关系来测试程序。模型转换测试方法中，MT与其他测试方法最主要的区别在于：MT通过检测多个执行结果之间是否满足预先依据被测程序的功能和性质构造出来的关系（即蜕变关系）来验证程序的正确性，而其他传统方法焦点在于单一地执行输入和验证输出。此外，模型转换测试中，蜕变关系（metamorphic relation，MR）可以根据非正式的软件规格说明书构造，而大多数其他测试方法依赖正式的规格说明书。

蜕变测试关键步骤和难点是蜕变关系[7]的构造，它将直接影响测试的效果。本文针对UML到Java模型转换程序，依据转换规则，从4个方面设计并构造出一组蜕变关系，并通过案例分析说明了蜕变测试的有效性。

2　模型转换

模型转换是模型驱动工程（model driven engineering，MDE）中一项至关重要的活动[8]，它将源模型通过转换程序转化为目标模型。一个典型的模型驱动框架结构如图1所示，其中Ma是源模型，Mb是目标模型。Ma符合其元模型MMa，Mb符合其元模型MMb。MMa和MMb分别描述了对应Ma和Mb的静态信息，模型转换过程中，依据这些信息来引导模型进行正确转换。Mt是一个模型转换实例，它也是一种模型，符合模型转换的元模型MMt。Ma和Mb分别代表模型转换程序中的输入模型和输出模型。

Fig.1　Framework of model transformation图1　模型转换框架

目前存在很多不同的模型转换语言，ATLAS转换语言（ATLAS transformation language，ATL）是其中一种应用最为广泛的语言[9]，本文案例研究使用的UML2Java.atl就是一种基于ATL的模型转换程序，它在ATL Transformation Zoo（http://www.eclipse.org/atl/ atlTransformations）中是一个开源的程序。

在UML2Java模型转换中，源模型是UML模型，目标模型是Java模型，它们分别符合各自的UML和Java元模型，如图2和图3所示。为了分析的方便，本文已将模型进行了简化。在UML模型中，DataType代表基本数据类型，每个类都有各自的类名以及一些属性。在Java模型中，每个Java类都包含一些方法和域，每种方法都有一种类型作为返回值的类型，每个域也有各自的类型，它们都属于一个Java包。通过修饰符（Modifier）来限定类、方法、域的类型。

模型转换需要制定转换规则，UML2Java.atl转换规则非形式化描述如下：

（1）每个UML包生成一个Java包，包名一一对应。与UML简单包名不同的是，Java的包名包含了全路径信息。

Fig.2　Metamodel of UML图2　UML元模型

Fig.3　Metamodel of Java图3　Java元模型

（2）每个UML类生成一个Java类，它们的类名、所属包、所属修饰符均一一对应。

（3）每个UML数据类型（DataType）生成一个Java基本类型，它们的名字、所属包均一一对应。

（4）每个UML属性生成一个Java域，它们的名字、类型、修饰符、所属类均一一对应。

（5）每个UML操作生成一个Java方法，它们的名字、类型、修饰符、所属类均一一对应。

使用对象约束语言（object constraints language，OCL）[10]可以对以上规则进行描述，生成对应的模型转换程序UML2Java.atl。

可以看出在以上模型转换的过程中规则并不复杂，UML描述的类、属性、操作等概念与目标java代码中的相应概念一一对应，可以通过人工方式逐一验证输出模型正确性。但是，模型的复杂程度以及规则的繁琐性使得验证模型转换正确性工作量巨大。

3　蜕变测试相关工作

与传统测试方法不同，蜕变测试（metamorphic testing，MT）无需构造预期输出，通过比较程序执行结果之间是否满足对应的蜕变关系来测试程序的正确性[11]。蜕变测试的实用性使得它在一些特定领域中广泛应用。路晓丽等人将蜕变测试方法应用于面向服务软件的单元测试和集成测试中[12]。姚奕等人利用蜕变测试技术发现由于整型错误产生的隐错，有效地提高了检测整型错误的效率[13]。在模型转换蜕变测试中，文献[8]通过类到关系模型转换特点构造了一组蜕变关系，但该方法仅考虑类模型中的属性元素，并未考虑其他元素及元素之间关系对模型转换的影响，构造出的蜕变关系单一。在此基础上，本文以UML模型到Java模型转换为例，考虑其基本元素及其关系，从元素增加、删除、修改、替换4个方面构造出了一组蜕变关系，并给出了模型转换蜕变关系一般性构造方法。

假设 f是待测程序P的实现函数。为了测试P，首先利用一些测试用例选择策略（如黑盒测试、白盒测试和随机测试等）生成测试用例集T={t1,t2,…, tn}，集合T中的ti作为原始测试用例。基于函数 f的特性，可以构造出一些蜕变关系MRs。对于构造的每条MR，均作用于集合T中生成衍生测试用例集，表示为T′={t1′,t2′,…,tn′}，(ti,ti′)构成蜕变测试组[14]，蜕变测试通过执行原始和衍生测试用例来检测它们的输出之间是否满足对应的蜕变关系，而不需要构造和验证单一测试用例的预期输出。

4　基于模型转换程序的蜕变测试

4.1模型转换蜕变测试流程

模型转换蜕变测试的一般性流程如下：首先，通过模型转换规则构造MRs，并设计原始测试模型。其次，对于每个MR，生成基于原始测试模型的衍生测试模型，通过输入原始、衍生测试模型执行模型转换程序，并获取它们的输出模型。最后，验证输出模型是否满足每条蜕变关系MR，一旦不满足，就表明转换程序有误。

由于UML2Java.atl规则较为简单，且对于UML中重要的关联关系的转换并未给出定义，本文在原规则[15]基础上增加UML中隐式一对多关联变换规则，增加的规则非形式化描述如下：

（1）重数为1端。重数大于1的关联端的类名作为重数为1端Java类的reference属性名（每个关联端类包含指引reference属性，通过该属性可以访问相关联的类），类型为Set，产生Java类的Get方法，返回值类型为Set，参数为空，该方法用于获取关联另一端的类；产生Java类的Set方法，返回值类型为void，参数名为重数大于1的关联端的类名，参数类型为Set，该方法用于设置关联另一端的类。

（2）重数大于1端。重数为1的关联端的类名作为重数大于1端Java类的reference属性名，类型为String，产生Java类的Get方法，返回值类型为String，参数为空，该方法用于获取关联另一端的类；产生Java类的Set方法，返回值类型为void，参数名为重数为1的关联端的类名，参数类型为String，该方法用于设置关联另一端的类。

4.2蜕变关系的构造

模型转换蜕变测试中最关键的活动在于构造基于转换规则的蜕变关系。本节将以UML2Java转换程序规则为例，构造一组蜕变关系。

UML2Java模型中，Java输出模型有以下基本元素：基本类型（Type）、属性（Attribute）、类（Class）、方法（Method）、包（Package）。测试转换程序的正确性是要验证输出模型中以上基本元素以及多个类之间的关联关系是否符合转换规则。假设U1、U2分别为原始测试模型和衍生测试模型，它们通过转换程序分别生成对应的输出模型J1、J2。下文将使用X.Y表示模型X中元素Y的集合；X.#Y表示模型X中元素Y的个数；X.Z￥Y.Z表示X.Z∪Y.Z-X.Z∩Y.Z，其中∪、∩分别为交、并。

基于UML2Java转换规则，可以构造出以下几种类别的蜕变关系：

（1）增加原始测试模型中的某些基本元素

MR1.1通过在U1中增加一种基本类型T1得到U2，则

J2.#Classes=J1.#Classes

J2.#Packages=J1.#Packages

J2.#Types=J1.#Types+1

MR1.2通过在U1中类C1中添加属性A1得到U2。

MR1.2.1若A1不引入新的基本类型，则

J2.#Classes=J1.#Classes

J2.#Packages=J1.#Packages

J2.#Types=J1.#Types

J2.Classes1=J1.Classes1

J2.Attributes￥J1.Attributes=J2.A1

MR1.2.2若A1引入新的基本类型，则

J2.#Classes=J1.#Classes

J2.#Packages=J1.#Packages

J2.#Types=J1.#Types+1

J2.Classes1=J1.Class

J2.Attributes￥J1.Attributes=J2.A1

其中Classes1表示不包含A1的类。

MR1.3通过在U1中类C1中添加操作O1得到U2，O1对应U2中方法M1，则

J2.#Classes=J1.#Classes

J2.#Packages=J1.#Packages

J2.#Methods=J1.#Methods+1

J2.Methods￥J1.Methods=J2.M1

MR1.4通过在U1中增加一个类C1得到U2，且C1属于P1。

MR1.4.1C1与其他类之间不存在一对多关联关系，若C1为抽象类（isAbstract），则

J2.P1.#Classes0=J1.P1.#Classes0+1

J2.Classes2=J1.Classes2

J2.#Packages=J1.#Packages

若C1为非抽象类，则

J2.P1.#Classes1=J1.P1.#Classes1+1

J2.#Packages=J1.#Packages

J2.#Attributes>J1.#Attributes

J2.#Types=J1.#Types

J2.Classes2=J1.Classes2

其中Classes0表示抽象类，Classes1表示非抽象类，Classes2表示不包括C1的其他类。

MR1.4.2 C1与U1中C2之间存在一对多关联关系，且C1是重数为1的一端，则

J2.#Classes=J1.#Classes+1

J2.#Attributes=J1.#Attributes+2

J2.#Methods=J1.#Methods+4

J2.#Packages=J1.#Packages

J2.C2￥J1.C2={X|X为reference属性、Get、Set函数的集合，其中reference属性类型为String，Get函数返回值类型为String，Set函数形参名为C1类名，形参类型为String，返回值类型为Void}

J2.Classes1=J1.Classes1

其中Classes1表示不包括C1和C2的其他类。

MR1.4.3 C1与U1中C2之间存在一对多关联关系，且C1是重数为n的一端，则

J2.#Classes=J1.#Classes+1

J2.#Attributes=J1.#Attributes+2

J2.#Methods=J2.#Methods+4

J2.#Packages=J1.#Packages

J2.C2￥J1.C2={Y|Y为reference属性、Get、Set函数的集合，其中reference属性类型为Set，Get函数返回值类型为Set，Set函数形参名为C2类名，形参类型为Set，返回值类型为Void}

J2.Classes1=J1.Classes1

其中Classes1表示不包括C1和C2的其他类。

MR1.5在U1中增加一个包P2得到U2，则

J2.#Packages=J1.#Packages+1

J2.Classes=J1.Classes

（2）删除原始测试模型中的基本元素

通过删除与通过增加构造的蜕变关系类似，区别在于元素个数是增加还是减少，在此仅介绍删除关联端类所构造的蜕变关系。

MR2.1删除U1中类C1，C1与U1中C2存在一对多关联关系，且C1为重数为1的一端，则

J2.#Classes=J1.#Classes-1

J2.#Attributes=J1.#Attributes-2

J2.#Methods=J2.#Methods-4

J1.C2￥J2.C2={X|X为reference属性、Get、Set函数的集合，其中reference属性类型为String，Get函数返回值类型为String，Set函数形参名为C1类名，形参类型为String，返回值类型为Void}

J2.Classes1=J1.Classes1

其中Classes1表示不包括C1和C2的其他类。

MR2.2删除U1中类C1，C1与U1中类C2存在一对多关联关系，且C1为重数为n的一端，则

J2.#Classes=J1.#Classes-1

J2.#Attributes=J1.#Attributes-2

J2.#Methods=J2.#Methods-4

J1.C2￥J2.C2={Y|Y为reference属性、Get、Set函数的集合，其中reference属性类型为Set，Get函数返回值类型为Set，Set函数形参名为C2类名，形参类型为Set，返回值类型为Void}

J2.Classes1=J1.Classes1

其中Classes1表示不包括C1和C2的其他类。

MR2.3同时删除U1中类C1、C2，C1与C2间存在一对多关联关系。

MR2.3.1 C1、C2与U1中其他类不存在一对多关联关系，则

J2.#Classes=J1.#Classes-2

J2.#Attributes=J1.#Attributes-2

J2.#Methods=J2.#Methods-4

J2.Classes1=J1.Classes1

其中Classes1表示不包括C1和C2的其他类。以此类推，可以得到同时删除n对一对多关联关系类时有：

J2.#Classes=J1.#Classes-2n

J2.#Attributes=J1.#Attributes-2n

J2.#Methods=J2.#Methods-4n

MR2.3.2 C1、C2中仅有一个类与U1中类C3存在一对多关联关系，则

J2.#Classes=J1.#Classes-2

J2.#Attributes=J1.#Attributes-4

J2.#Methods=J2.#Methods-6

J2.Classes1=J1.Classes1

J2.C3￥J1.C3={X|X为reference属性、Set、Get函数的集合}

其中Classes1表示不包括C1和C2的其他类。

MR2.3.3 C1、C2均与U1中其他类存在一对多关联关系，则

J2.#Classes=J1.#Classes-2

J2.#Attributes=J1.#Attributes-6

J2.#Methods=J2.#Methods-8

J2.Classes1=J1.Classes1

其中Classes1表示不包括C1和C2及与它们相关联的其他类。

（3）修改原始测试模型中的基本元素

MR3.1修改U1中属性A1（属性值类型）得到U2，则

J2.#Classes=J1.#Classes

J2.#Packages=J1.#Packages

J2.#Attributes=J1.#Attributes

J2.#Methods=J1.#Methods

J2.#Types=J1.#Types

J2.Attributes1=J1.Attributes1

其中Attributes1表示不包括A1的其他属性。

MR3.2修改U1中类C1、C2，使得C1与C2之间存在一对多关联关系，则

J2.#Classes=J1.#Classes

J2.#Packages=J1.#Packages

J2.#Attributes=J1.#Attributes+2

J2.#Methods=J1.#Methods+4

J2.Classes1=J1.Classes1

其中Classes1表示不包括C1、C2的其他类。

（4）交换原始测试模型中的基本元素

MR4.1假设C1、C2是U1中的两个类，它们分别属于U1中包P1、P2，且它们之间不存在一对多关联关系，交换C1、C2得到U2，使得U2中C1、C2分别属于P2、P1，则

J2.P1.#Classes=J1.P1.#Classes

J2.P2.#Classes=J1.P2.#Classes

J2.Attributes=J1.Attributes

J2.#Packages=J1.#Packages

J2.#Types=J1.#Types

J2.Classes=J1.Classes

MR4.2假设C1、C2是U1中的两个类，它们之间存在一对多关联关系，C1为重数为1关联端，C2为重数为n关联端，交换C1、C2得到U2，使得C1、C2之间的关系为多对一，则

J2.#Classes=J1.#Classes

J2.#Packages=J1.#Packages

J2.#Attributes=J1.#Attributes

J2.#Methods=J1.#Methods

J2.C1￥J1.C1={X|X为reference属性类型，Get函数返回值，Set函数形参类型的集合}

J2.C2￥J1.C2={X|X为reference属性类型，Get函数返回值，Set函数形参类型的集合}

J2.Classes1=J1.Classes1

其中Classes1表示不包括C1和C2的其他类。

注：交换与修改操作本质区别在于交换元素后模型的整个元素集合中元素或元素关系不发生变化，而修改操作会导致元素或元素关系与修改前不完全一致。

需要说明的是，以上蜕变关系中各情况的修改均为合法操作，等式两边基本元素必须一一对应。本节构造出的蜕变关系覆盖了模型中的基本元素以及类之间的关联关系，将以上构造出来的蜕变关系应用到基于新规则的蜕变测试中，若输出模型J1、J2之间违背了其中任意一条蜕变关系MRi，则表明模型转换程序出错。

5　案例分析

下面以一个简化的学生与学校关联UML模型为例进行分析，如图4所示。

Fig.4　Simplified UML model of student and school图4　简化的学生与学校关联UML模型

该UML模型中，学生类（Student）包含姓名（name）、学号（number）、班级（class）、年级（grade）基本属性以及学分管理（ScoreManagement）、课程管理（CourseManagement）操作，它属于人员信息包，学校类包含校名（name）属性。若转换规则代码正确无误，则该UML模型经过变换后，得到图5所示Java模型。

Fig.5　Java model of implicit association图5　隐式关联Java模型

下文将通过两个模型转换[16]变异分析案例说明蜕变测试的有效性。

变异1删除转换程序中关联关系的转换代码。

根据蜕变关系MR3.2，将图4所示模型作为本次蜕变测试的衍生测试用例模型，它由不包含学生类与学校类关联关系的原始测试用例模型所构造，如图6所示。将图4、图6所示衍生、原始测试模型分别通过模型转换程序，得到Java模型J1、J2，通过比较J1、J2，会得到J2.#Attributes=J1.#Attributes，J2.#Methods=J1.#Methods,这一结果违背蜕变关系MR3.2中“J2.#Attributes=J1.#Attributes+2，J2.#Methods=J1. #Methods+4”，则通过本次蜕变测试就能暴露出转换程序缺少关联关系转换代码的问题。

Fig.6　UML model of student and school without association图6　不包含关联关系的学生与学校UML模型

变异2删除代码中关于重数为1端关联类的代码部分。

原始测试用例使用图4所示模型，根据蜕变关系MR3.2修改学生类与学校类，使得学生类为重数为1的关联端（实际中不存在此关系模型，但仅作为蜕变测试用例是合理的），如图7所示衍生测试用例模型。

Fig.7　Modified UML model of association of student and school图7　修改后的学生与学校关联UML模型

将图4、图7所示原始、衍生测试模型分别通过此程序后，得到Java模型J1、J2。通过比较可以发现，J1 中Student类与J2中Student类之间差异部分为reference属性、Get函数、Set函数的集合，J1中School类与J2中School类之间差异为reference属性、Get函数、Set函数的集合。而蜕变关系MR4.2中，J2.C1 ￥J1.C1={X|X为reference属性类型，Get函数返回值，Set函数形参类型的集合}，J2.C2￥J1.C2={X|X为reference属性类型，Get函数返回值，Set函数形参类型的集合}，输出模型J1、J2之间不满足蜕变关系。因此转换程序中缺少重数为1关联端转换的缺陷将会通过本次蜕变测试被发现。

关联变换是MDA中模型转换的难点[15]，也是容易出错的地方。上文变异分析中植入的变异在实际模型转换中具有代表性，若对含有上述缺陷的程序使用常规测试方法，需要将输出模型中每个元素里所有参数进行一一验证，这样测试效率会大大降低，而蜕变测试方法通过比较两个输出模型中差异部分可以有效地提高测试效率。

如第1章所描述，本文介绍的模型转换程序可以通过手工测试来验证其正确性，但实际应用特别是商业领域中获取模型转换测试Oracle的代价高（模型庞大或者转换程序规则复杂），而通过蜕变测试比较不同输出之间是否满足蜕变关系可在一定程度上解决这一问题。

6　结束语

随着面向模型驱动架构的应用越来越广泛，对使用模型转换生成应用代码的软件开发工具，模型转换的正确与否影响着最终软件质量的好坏，因此确保面向模型转换程序的质量尤为重要。由于获取模型转换程序的测试Oracle代价高，本文提出将蜕变测试方法用于UML到Java模型测试过程中，依据转换规则，从4个不同方面构造出一组蜕变关系，并通过案例分析对4个不同方面的蜕变关系进行了蜕变测试分析，介绍说明了蜕变测试的有效性。未来将重点研究其他面向模型转换程序的蜕变关系构造，比较、总结这些蜕变关系之间的联系，并进一步通过模型转换变异分析，比较各蜕变关系的有效性。

[1]Papajorgji P J,Pardalos P M.The model-driven architecture approach[M]//Software Engineering Techniques Applied to Agricultural Systems.Springer US,2014:135-178.

[2]Zhu Liming.Model-driven architecture[M]//Essential SoftwareArchitecture.Berlin,Heidelberg:Springer,2011:201-217.

[3]Zeng Yi,Xu Lin,Huang Xingyan,et al.Method of high-order model transformation combined with MDA[J].Application Research of Computers,2012,29(12):4584-4588.

[4]Meenakshi D,Naik J S,Reddy M R.Software testing techniques in software development life cycle[J].International Journal of Computer Science and Information Technologies, 2014,5(3):3729-3731.

[5]Mottu J M,Baudry B,Traon Y L.Model transformation testing:Oracle issue[C]//Proceedings of the 2008 IEEE International Conference on Software Testing Verification and Validation Workshop,Lillehammer,Norway,Apr 9-11, 2008.Piscataway,USA:IEEE,2008:105-112.

[6]Wang Rong,Ben Kerong.Researches on basic criterion and strategy of constructing metamorphic relations[J].Computer Science,2012,39(1):115-119.

[7]Asrafi M,Liu H,Kuo F C.On testing effectiveness of metamorphic relations:a case study[C]//Proceedings of the 2011 5th International Conference on Secure Software Integration and Reliability Improvement,Jeju Island,Korea,Jun 27-29,2011.Piscataway,USA:IEEE,2011:147-156.

[8]Jiang M,Chen T Y,Kuo F C,et al.Testing model transformation programs using metamorphic testing[C]//Proceedings of the 26th International Conference on Software Engineering and Knowledge Engineeing,Vancouver,Canada,2014:94-99.

[9]Jouault F,Allilaire F,Bézivin J,et al.ATL:a model transformation tool[J].Science of Computer Programming,2008, 72(1):31-39.

[10]Cao Liu,Cao Chun.Validation environment of software architecture based on OCL[J].Computing Science,2012,39 (11A):409-414.

[11]Chen Leilei.The optimization of meta-morphic testing based on equivalence classes partition[D].Shanghai:East China University of Science and Technology,2013:6-10.

[12]Lu Xiaoli,Dong Yunwei.Testing of service-oriented software:a metamorphic testing approach[J].Journal of ComputerApplications,2011,31(7):1756-1758.

[13]Yao Yi,Huang Song,Ji Mengyu.Research on the metamorphic testing for integer bugs detection[J].Computer Engineering and Science,2012,34(4):53-56.

[14]Xie Xiaoyuan,Wong W E,Chen T Y,et al.Metamorphic slice:an application in spectrum-based fault localization[J]. Information and Software Technology,2013,55(5):866-879.

[15]Xia Lei,Ouyang Song.Association transformation from UML model to Java model in MDA[J].Computer Engineering and Design,2006,27(16):3078-3081.

[16]Mottu J M,Baudry B,Le Traon Y.Mutation analysis testing for model transfomations[C]//LNCS 4066:Proceedings of the 2nd European Conference on Model Driven Architecture Foundations and Applications,Bilbao,Spain,Jul 10-13,2006.Berlin,Heidelberg:Springer,2006:376-390.

附中文参考文献：

[3]曾一,许林,黄兴砚,等.一种结合MDA的高阶模型转换方法[J].计算机应用研究,2012,29(12):4584-4588.

[6]王瑢,贲可荣.蜕变关系构造基本准则与策略研究[J].计算机科学,2012,39(1):115-119.

[10]曹流,曹春.一种基于OCL的体系结构一致性验证环境[J].计算机科学,2012,39(11A):409-414.

[11]陈蕾蕾.基于等价类划分的蜕变测试方法优化[D].上海:华东理工大学,2013:6-10.

[12]路晓丽,董云卫.面向服务软件的蜕变测试方法[J].计算机应用,2011,31(7):1756-1758.

[13]姚奕,黄松,稽孟雨.面向整数错误检测的蜕变测试方法研究[J].计算机工程与科学,2012,34(4):53-56.

[15]夏雷,欧阳松.MDA中关联从UML模型到Java模型的转换[J].计算机工程与设计,2006,27(16):3078-3081.

YU Heng was born in 1991.He is an M.S.candidate at Naval University of Engineering.His research interest is software quality assurance.

余恒（1991—），男，湖北钟祥人，海军工程大学硕士研究生，主要研究领域为软件质量保证。

BEN Kerong was born in 1963.He is a professor and Ph.D.supervisor at Naval University of Engineering.His research interests include software engineering and artificial intelligence.

贲可荣（1963—），男，江苏海安人，海军工程大学教授、博士生导师，主要研究领域为软件工程，人工智能。

Research on Metamorphic Testing for Model Transformation Programƽ

YU Heng，BEN Kerong+
Department of Computer Engineering,Naval University of Engineering,Wuhan 430033,China +Corresponding author:E-mail:benkerong08@163.com

The results of model transformation of model driven architecture(MDA)are often difficult to judge correct or wrong(that is,test Oracle problem),whereas metamorphic testing partially solves the Oracle problem by verifying whether the result of multiple executions satisfies the metamorphic relationships or not.To solve the Oracle problem of model transformation testing effectively,metamorphic testing is applied to the case of model transformation from UML to Java.Based on transformation rules,a set of metamorphic relations is constructed from four different aspects: add,delete,modify and replace.Finally,two common faults are transplanted in the program under test,the test cases are designed and executed to verify the metamorphic relations.The faults are exposed because the metamorphic relations are violated,which shows the effectiveness of metamorphic testing.

model transformation;software testing;test Oracle;metamorphic testing;metamorphic relations

2015-06,Accepted 2015-08.

10.3778/j.issn.1673-9418.1507050

A

TP311.5

*The National Natural Science Foundation of China under Grant No.61272108(国家自然科学基金).

CNKI网络优先出版:2015-08-28,http://www.cnki.net/kcms/detail/11.5602.TP.20150828.1503.002.html