一个基于UML协作图的集成测试用例生成方法(转贴)
上一篇 / 下一篇 2007-01-18 13:32:06 / 个人分类:测试用例
Tv6ShU`K0
G5TA:D9\ek%qp{0中图分类号 : TP311 文献标识码 : 文章编号 :51Testing软件测试网 V F)`iy
oK\yLj@Wa0An Approach to Generate Integration Test Cases based on UML Collaboration Diagrams Linzhang Wang, Xuandong Li,Guoliang Zheng (CS Department , Nanjing University, Hankou Road 22 P.O. Box 419, 210093, Nanjing) Abstract: UML collaboration diagrams represent the structure relationship and interactive behavīor of the objects involving in a collaboration of the software system, whether they are correctly implemented or not can be validated by integration testing. This paper propose an approach to generate integration test cases based on UML collaboration diagrams, take collaboration diagram as test model, from which we can extract information to generate integration test cases for testing the behavīor. Firstly, the method identifies all the scenario paths in the diagram which represent use case realization by traverse the direct successors of each message. Then it selects and traverses each scenario path to get the method call sequence, path condition and parameters. Lastly, it applies category partition method to generate rational combination of input parameters, environmental conditions, as well as the corresponding output and method call sequence, to form a test case for each scenario path, thus we can test the interactive behavīor of the software. This method completely base on UML, combine white-box and black-box test method to generate fewer test cases to test the gray-box behavīor. In this paper, we apply this approach to an example of constructing sessions between cardholder and the bank through ATM, proving its feasibility and practicability, also propose a corresponding tool framework to facilitate its automation, thus to easily be deployed into the UML –based software development process. Keywords: test cases generation, integration testing, UML collaboration diagram, scenario path 1、引言 面向对象的技术因为能够解决传统程序设计语言的问题,自提出后,一度成为研究热点,事实上采用面向对象技术减少了不少错误的发生,对于提高软件质量起到了很大的作用,但是面向对象技术本身在任何情况下都不会排除软件测试的动机,同时面向对象语言的本质特征,如继承、封装、和多态等,也带来了新的故障风险,并给软件测试提出了新的挑战。[1,2,9] 区别于传统软件的功能分解,面向对象软件是通过合成来构造软件的,因而集成是面向对象软件开发中最重要的工作,面向对象软件构造过程中有的不同层次的集成,包括:从方法到类的集成,类通过继承集成,类通过容器集成,类到组件的集成,组件到应用系统的集成。在面向对象的迭代式增量开发过程中,通过不断的集成产生系统的可执行的版本,但每一个集成的环节都可能引入错误,导致软件中存在缺陷,为了能够发现软件集成中的问题,面向对象软件的集成测试非常重要。[4] 对于传统软件的集成测试,可以根据设计阶段形成的功能分解树,采用自顶向下或自底向上逐步测试用经过测试的单元组装成系统的过程中有无错误。[3]而面向对象软件采用的是通过组合实现系统的功能,没有一个功能分解树可用,所以传统的基于功能分解的集成测试策略不适合面向对象软件。要检验最终实现中各种集成是否与设计的集成一致,则需要对每一个集成层次进行测试,而这里的集成分为结构集成和行为集成,所以面向对象软件的集成测试包含结构集成测试和行为集成测试。结构集成测试主要测试类的继承、类的容器、类的接口、组件的接口中有无错误;行为集成测试主要是类内方法交互、类间方法交互、组件间交互是否被错误地实现。测试工作的核心主要是生成测试用例,在面向对象软件开发过程中系统的规约、设计、代码是生成测试的信息来源,是软件在其生命周期不同阶段的变体,当然规约、设计、代码在每一阶段的测试中都起相应的作用,特别地,系统规约是生成系统测试的测试用例的基础和系统测试的检验依据,软件代码是生成单元测试用例的基础和单元测试的检验依据,系统设计是生成集成测试用例和集成测试的检验依据。系统的设计信息有助于理解系统功能和结构,设计模型包含规约和程序结构的信息,同时也描述了系统的相应功能片断的行为,因此也被称为灰盒。可以结合白盒测试和黑盒测试方法,从设计信息生成集成测试用例,测试设计模型表示的软件系统的灰盒行为。 UML是面向对象系统分析、设计的标准的建模语言,自从在1997年成为建模语言事实上的标准后,就得到学术界的推崇和工业界的支持,使得UML广为使用,基于UML的方法和实用技术的研究成为将来的发展趋势。UML对面向对象软件开发全生命周期的支持也使得软件开发人员优先用它来描述系统。[8]正像集许多优点的面向对象技术不能免除软件测试一样,使用UML进行面向对象软件开发,在提高软件质量的同时,仍然需要测试来确认软件分析、设计、实现的一致性和正确性。同时基于UML开发的软件系统,软件开发的分析、设计阶段工作成果多为各种模型图,系统的可用信息都在这些模型图中,给信息的提取带来了新的问题,从而也给测试带来新的课题。对测试而言,原先的基于规约或者是基于程序的方法都不能直接使用,对基于UML模型的测试,要将问题转换到原来传统测试方法可以处理的问题空间中加以解决,转换工作主要解决信息提取问题,然后用常规测试方法生成测试。面向对象的软件中,对象通过交互来实现行为,UML的交互图[6,7]是描述一组对象间的结构关系和交互行为设计的最佳选择,主要有顺序图和协作图两种,顺序图关注全局的时序,协作图关注协作对象之间的关系,本文主要研究协作图。UML协作图描述了系统的一个协作中参与对象之间如何交互,集成测试正是要验证这些对象是否正确交互,所以我们研究基于UML协作图的集成测试用例生成方法。本文中我们使用UML协作图作为系统功能片断的高级描述,用来作为生成测试的基础,使得在系统设计阶段一开始就可以计划集成测试阶段的测试。在软件开发早期准备软件测试,在软件的系统分析、设计阶段,利用每一阶段的人工制品(artifact)生成软件测试各个阶段所需的测试用例,在代码阶段结束后便可以开始测试工作,而且对分析设计模型进行分析的同时也能发现分析、设计本身的缺陷,以便及时排除,以防缺陷随着软件开发过程的进展而被放大。由于UML在工业界的使用越来越普遍,而相应支持在分析设计阶段基于模型生成测试用例的实用方法和支持工具还不多见。我们希望能够研究出仅从UML分析、设计模型图自动生成测试用例的方法,而且不需要使用者的除UML外其他方面专业的知识,能够实现自动化而不增加用户额外的工作量,这样的测试方法容易被已经使用UML的工业界采用。[8,10] 本文研究如何通过面向对象软件设计阶段的UML协作图选择合适的集成测试用例的方法,第2部分对协作图的语法和语义作了详细的介绍,并回顾了测试模型、协作集成测试模式、协作故障模型等知识;第3部分对基于协作图生成测试用例的方法作了总体介绍,详细描述了从协作图生成测试用例的具体算法和支撑工具框架原型,第4部分是相关工作的介绍,最后是结束语和将来工作的构想
/~r9w5N/JJA-A"Y0OafEbN:xL:z0Ir02、协作图与集成测试51Testing软件测试网P$kVQ%Z*v){(Y
2.1协作图的语法和语义51Testing软件测试网#D,Cfz(_;al/^
UML协作图[7]就是用来表示一组通过交互来实现某些行为的对象,可以用来可视化、详细描述、构造和文档化一个特定的对象群体的动态方面,也可以用来按交互中的角色及其关系对一个用例的特定的场景或控制流的实现进行建模。协作图描述了特定行为的参与对象的静态结构,以及参与对象之间的动态交互,可以用于不同的规约抽象级别,规约级协作图表示了类元角色、关联角色和消息,表示对象之间的可能的关系,而实例级协作图表示对象、链和激励,表示特定对象之间的关系。两者都描述了协作参与者之间的结构关系。如果要表示可能事件,一般用规约级协作图,其中没有条件和循环,实例没有取值范围或有许多可能的路径。实例级协作图用于描述属性或参量有具体的值的对象和链,可变大小多重性的对象和链的具体数目,或者是执行中的分支或循环的特定选择。协作图可以用来表示用例的实现或操作的实现,描述操作和用例的执行实现所处的语境、交互中行为序列。当协作图用于表示用例的实现时,只描述外部可见的动作及其顺序,用对象之间的消息交换来描述一个用例实现的场景。当协作图用来表示一个对象的操作的实现时,提供了更详细的信息,如操作的参数及其用途、参与变量的特征、关联上的约束、操作实现过程中对象的创建和破坏等。本文主要研究用于表示用例实现的实例级协作图,下面介绍实例级协作图符号及其语义。51Testing软件测试网ppx~u@H7T
协作描述了在一定的语境中一组对象以及用以实现某些行为的这些对象之间的相互作用。协作由静态部分和动态部分组成,静态部分描述在协作实例中对象和链可能担任的角色,是角色集合和其间关系,这些关系定义了结构方面的内容,动态部分是一个消息集合,包括一个和多个动态交互,表示在执行计算过程中不同时间里协作中的消息流, 这些消息定义了行为方面的内容。角色表示协作中对象和链的目的,类元角色定义了参与协作执行的对象在一个协作中扮演的角色,关联角色定义了一个类元角色和其他角色之间的关系,是参与协作执行的关联的描述,关联角色是链的子集,链是两个或多个对象之间的单向连接,是关联的实例。对象必须是位于关联相应位置的类的直接或间接实例。关联是两个或多个特定描述其实例间连接的类元之间的关系,参与关联的类元在关联内有有序的位置。在运行时,对象和链与协作中的角色绑定,在不同的协作中一个对象可以绑定到一个或多个角色。
6n"c{-k+o,t0交互是由在一个实现特定目标的协作内一组对象之间通信序列组成的行为规约。每个交互包含消息的偏序集,这些消息由类元角色通过关联角色交换。消息是激励的规约,是发送者和接受者之间的通信。消息指定了发送者对象和接受者对象扮演的角色,说明发送者对象对接受者对象应用何种操作。激励是传递消息期望发生的两个对象之间的通信,激励导致一个操作被激活、发出一个信号、导致一个对象被创建或终止。51Testing软件测试网BC N3| uUH
本部分介绍一个客户通过ATM上验证用户卡和PIN有效性、建立会话的用例片断[9]的实例级协作图,如图1所示。协作图上存在条件消息说明考虑到许多不同的用例场景,涉及到多个对象之间的交互,其中每一个场景都对应协作图上的一条执行路径,这正是测试所要尝试的。图2表示了在这个协作中参与对象相应的类图。51Testing软件测试网U'b&K%[8EUIc
51Testing软件测试网{K8}-E?+f
51Testing软件测试网3Al)o,RS's f)c ["Ku.D一个描述用例实现的实例级协作图上用于建模的元模型包括:类元角色名、关联角色名、对象符号、链接符号、消息符号、链上的约束等。对象框能够表示参与协作中交互的对象,链表示这些对象之间的结构关系,消息的箭头形状表示协作对象间的通信模式和对象的执行特征, 消息标签表示对一个对象的操作调用的允许顺序的实例、操作的语义。在实际的建模活动中有些元素并不在模型上反映,例如图1的协作图只表示了协作中参与的对象和对象之间的消息,这是表示对象交互的最小元素集。本文关注协作图表示的动态行为的测试,前面提到协作图上表示交互的主要元素是消息,下面详细介绍消息。
T|9@m9OU|3c0协作图中的消息用带有消息标签的箭头表示,附在连接发送者和接受者的链上,链用于访问目标对象,箭头沿着链指向接受者,一个链上可以有多个消息,沿着相同或不同方向传递,消息的相关顺序由消息标签中的顺序号表示。按照UML1.5[5]中提出消息箭头有三种形状表示对象之间的通信方式和控制流类型:实线实心箭头表示同步消息,用于表示过程调用和嵌套控制流,每次调用增加一个嵌套层次;刺状箭头表示平面控制流,是异步通信,无嵌套,表示前驱-后继关系,指向下一步骤;虚线刺状箭头表示从过程调用返回。图1中的消
4B5WIeP!?0
n}BE~a_5c&Ev0图1 ATM建立一次会话的实例的协作图51Testing软件测试网 Rt
Q-\U
息都是带有刺状箭头的实线,表示前驱/后继关系。消息标签说明发送的消息、发送的条件、由消息激活的方法、相应的参量和返回值,以及交互中的消息顺序,包括调用嵌套、迭代、分支、并行和同步,完全格式消息标签的语法[5]中有详细的定义。其语法如下:51Testing软件测试网1\(K Euw'?.p$^
[predecessor][guardcondition][sequence-expression][return-value-list]:=message-name(argument)
Ixr/A3^0[predecessor]表示前驱,在协作中前驱是用逗号隔开的顺序号列表,并后跟“/”;[guardcondition]表示线程同步的卫式条件;[sequence-expression]表示顺序项列表每一项表示交互中的一个嵌套层次,如果所有的控制并行则无嵌套;整数表示过程调用中的相邻高层中的消息的顺序,同一整数项中的不同消息在嵌套层是顺序相关的,同一前缀的消息顺序号构成序列。循环表示条件或迭代执行,表示根据条件执行零个或多个消息;[return-value-list]在有返回值的情况下表示消息返回值的名称,名称之间用逗号隔开,可以作为后续消息的参量;message-name 表示目标对象中引发的事件名称,可以用不同的方式实现,如操作调用;Argument 是消息引发的方法的参量列表。51Testing软件测试网.?%r aq-D-d mM
图2 图1 ATM用户验证的类图
&f0[.CnA"yZ0 消息上的条件增加了消息的表达能力,也增加的消息复杂度,消息上的条件有几种形式:在一个新的调用层次开始,如图1中消息标签4.1[isMemberCard]feeAmount:=getfeeAmount()所示:4.1表示一个新的调用序列,条件成真时该层次的消息顺序发送,否则都不发送;在顺序发送的消息上,例如消息1.3中,[!isATMCard]条件表示二值条件,条件成真时其后的消息eject()执行一次,否则不执行,对其他消息没有影响;在一个表示迭代的嵌套调用消息开始,如消息3.1.1表示了一个迭代执行多个消息的情况,根据validPIN和n的取值可能发送1或2次消息。51Testing软件测试网TwX6XSQ"o!BT
这些协作图上的模型元素所表示的软件系统的不同方面的信息,都是系统的本质信息,需要在软件从设计到实现过程中必须保持的,因而软件实现中的行为的本质方面都会在设计中表示,所以可以从设计表示中获取行为方面的信息,用于确认软件实现中是否正确实现。 51Testing软件测试网_MW,t)b|m
2.2场景路径51Testing软件测试网-I
xi7gQ?
u
一个表示用例实现的协作图实现了用例的不同事件流,包括正常流和异常流,每个事件流称为一个场景,这些场景都被相应的协作图实现。一个协作图所表示的协作正是从一个外部事件触发开始,在参与协作的对象之间完成一系列的交互,最后正确的协作结束时都导致一个外部输出 ,对应于一个实际场景,也是一个线程执行的路径。要找到这些路径,一般的方法是将协作图转换为流图,然后在流图上使用图遍历的方法达到路径覆盖从而得到所有的路径。本文为了避免复杂流图的转换和不可行路径的遍历开销,试图直接从协作图上获取这些路径。我们从Paul C. Jorgenson[4]定义原子系统功能(ASF)和方法/消息路径(MM-path)得到启发,本文定义了一个场景路径(scenario-path):
6Mv8T1|B0定义 场景路径(scenario-path,s-path)是协作图上从一个没有前驱消息的消息开始,沿着消息的偏序执行序列,到达一个没有后继的消息结束的由消息相连的方法执行序列。
d
w
N%{]6i*lQ\&F&C0由于面向对象软件的事件驱动特性,软件的执行由事件开始,反映场景执行的场景路径由一个外部事件触发的消息(没有前驱消息)开始,表示路径入口,通过消息传递访问协作图中参与一个协作场景实现交互的对象的方法序列,达到一个引发端口输出事件的方法且该方法自己不再发出新的消息(没有后继)结束,到达路径出口,这时系统处于静止状态,等待另一个系统级端口输入事件开始进一步的处理。一个场景路径的线程的执行是一个原子执行,场景路径表示了协作图中的一个场景的线程执行的完整的踪迹,也是参与协作的对象之间的交互的踪迹,消息的传递激活对象方法的执行是对象之间控制流的转移,而路径中通过消息激活的方法调用的参数定义和使用、对象的创建、使用和撤销明显表示了一条在控制流上执行的数据流。
~L?Oz9m6{a0由于协作图在表示用例实现时,协作图上的场景路径是从第一条入口消息开始到所有能触发端口输出事件或没有后继消息的出口消息之间的所有可能的消息流。要获取场景路径上的消息流,可以通过消息之间的偏序关系以及决定消息流分支和循环的条件来实现。回顾协作图上消息及其顺序号的定义,整数表示过程调用中相邻高层中的消息顺序,同一整数项下的不同消息是表示一个前驱-后继式的平面控制流,嵌套的消息顺序号表示过程的调用控制流。消息顺序号隐含地表示了消息之间的偏序关系,因此可以在协作图上提根据消息的发送条件及其顺序号来跟踪场景路径。协作图中通过消息顺序号跟踪消息执行的顺序比顺序图中通过自上而下的生命线跟踪消息执行的顺序困难得多,但由于协作图更容易表示对象之间的动态连接关系,协作图不关注全局的消息执行顺序,只关注一个场景的执行路径上的消息顺序,这为我们识别场景路径提供了方便。协作图上的分支和循环导致了许多可能的路径,极端的情况下路径的数目可能到达一个庞大的数字,我们要达到协作图上的路径覆盖,采用简单的方法达到判定/循环覆盖。我们先将循环消息看作条件消息,在遍历场景路径的过程中,访问一条消息后,先找出该消息可能的直接后继,然后采用深度优先的方法选择一个直接后继继续遍历,当到达一个没有后继的消息时,就完成一个场景路径的遍历,回溯到下一个直接后继,继续遍历,只到所有的直接后继都已被访问,则完成了所有的场景路径的遍历。这样我们实现每条消息至少遍历一次,每个条件分支都至少遍历了一次,也避免了路径的穷尽覆盖。然后处理协作图上的循环,一般是给出绕过循环、循环一次、循环最多次以达到循环路径的覆盖。对于存在分支和循环的场景路径,例如图1所示的协作图上有7个条件判断和一个最大次数为2的循环,可能的路径有2*2*2*2*3*2*2*2=192条,但由于有5个条件判定各有一个分支直接导致场景路径结束,所以实际的场景路径应为1+1+1+1+1+3*2+2=13条,这13条场景路径对应相应软件功能的13个执行场景。
0?&F^*\ma3J A(q^O0我们在协作图上遍历生成场景路径的同时,很容易基于路径覆盖准则获取相应场景执行过程中的控制流和数据流、覆盖路径的条件,然后可以确定每一路径所需要的输入和状态条件,当满足所有路径条件时线程就会沿着该路径执行,这正是我们定义集成测试用例所需要的信息,因此我们考虑将场景路径作为基于协作图的集成测试的基础。下面我们分析协作图表示的协作在实现中通过参与者之间的集成完成时可能发生的故障,这样便于我们研究针对检错为目的的测试。
,cff{ })jGT]@02.3基于协作图的协作集成测试模式51Testing软件测试网W!Z9l:@V.^
k/^ |]t:` m2t
协作图上描述的软件系统的消息的错误实现可能导致协作中表现的行为发生偏差,从而使最终实现与设计不一致,偏离软件规约规定的功能。例如由于消息名的编码错误、错误的参数、不正确的参数值、不正确的或缺少输出以及非预期的运行时绑定导致的错误方法调用;消息前驱约束实现错误导致发送者对象发送违反接受者对象前提条件的消息或者发送者对象发送违反接受者对象的顺序约束的消息;消息的发送者或接受者对象错误导致错误的对象和消息的绑定;参与者缺少功能或特征导致错误的对象引起正确的异常、正确的对象产生错误的异常。所以链上的消息箭头和约束、消息标签、对象等协作图上的元素未按设计正确实现会导致最终的软件与设计不一致,如果协作图的实现中存在错误,肯定在协作图至少一条路径上,要达到该错误,在未知该错误在那条路径上时,只能通过协作图上选择所有可能的执行路径,并导出能够跟踪这些路径的测试用例,并用它们来执行软件,来确定错误在哪条路径上,即哪条路径被错误实现了,从而可以调试软件,改正错误,以保证实现与设计一致。
9gf2n
to+vO[H9U0这些可能发生的错误都是在参与协作的对象之间交互时发生,也就是系统在通过不同类的对象的方法之间集成实现系统的行为时发生,这种错误通常由集成测试来发现。软件集成测试有几种常用的集成测试模式(integration testing pattern):一次性组装、自底向上集成、自顶向下集成、协作集成、基干集成、层次集成等,但是考虑到面向对象软件时有的模式不一定有用,在面向对象的系统中,很难找到一个控制的层次结构,使得方便定义自底向上集成、自顶向下集成、层次集成等策略。在面向对象的环境中我们可以通过基于线程或基于使用的测试技术测试类的交互。这里交互的类可以是单个类及其实例、类簇、组件、子系统或系统。用协作图描述的系统协作在集成测试时,协作集成是最佳的测试模式[9],通过在协作中参与的组件来决定集成测试所有参与的对象。基于协作的集成测试需要检测协作的参与者之间的接口和交互,通过协作组织集成。每次处理一个协作,直到协作图上的所有协作都被测试。当所有构件的接口和构件之间的交互都测试完时集成测试完成。协作中包括的构件按照在一个处理线程、一个事件-响应路径来选择,要求系统中每个构件之间的消息已经被至少测试一次。我们前面定义场景路径正是一个线程完成协作执行的一个事件-响应路径,所以可能发生的错误会出现一条或多条场景路径上。51Testing软件测试网|f&k}
MA&^,Bh
测试模式是一个测试策略,是建立在测试模型基础上的,而测试模型应该是被测软件系统的一个表示,能够从测试模型上获取测试需求,导出测试规约,从而生成测试用例。协作图是对象、组件、子系统、系统范围需求的良好来源,对系统的一个有限片断来说,提供了实现的抽象视图,它通常是过多或过少细节之间的一个良好的折中,可以用于在不同抽象级别和粒度级别建立软件系统的模型。由于协作图是描述的对象之间的交互,而系统的功能正是通过这些交互实现的,所以要考虑将设计描述的协作图作为生成集成测试的测试用例的测试模型。协作图上包括了对象间传递的消息及其顺序,这正是设计级的控制流和数据流信息,以往数据流和控制流只能从程序源码中分析得到。数据流和控制流对生成测试有很大的作用,所以我们利用协作图生成测试用例,就是要从协作图上提取出相应的数据流和控制流信息,利用传统的数据流、控制流生成测试用例的方法,生成可用于集成测试的测试用例。所以本文使用作为系统设计描述的协作图作为测试行为的测试模型,避免重新构造测试模型或者进行模型转换。