基于UML模型的测试用例设计方案

应用UML2.0模型的测试用例生成方法
张琛;段振华
【期刊名称】《西安交通大学学报》
【年(卷),期】2011(045)008
【摘要】针对软件开发过程中测试自动化程度低的问题,在研究基于模型的测试用例生成技术的基础上,提出了一种基于UML2.0序列图与用例描述的测试用例生成方法.采用事件确定有限自动机来描述系统序列图,通过命题投影时序逻辑的模型检测技术,验证了自动机模型的正确性.使用自动机模型与用例描述来生成测试用例,该用例满足事件与全路径覆盖准则.通过对图书管理系统的分析表明,该方法不仅能够提高软件的测试效率,而且还确保了针对管理员的执行动作所产生的测试用例的正确性.
【总页数】6页(P18-23)
【作者】张琛;段振华
【作者单位】西安电子科技大学计算理论与技术研究所,710071,西安;西安电子科技大学ISN国家重点实验室,710071,西安;西安电子科技大学计算理论与技术研究所,710071,西安;西安电子科技大学ISN国家重点实验室,710071,西安
【正文语种】中文
【中图分类】TP311
【相关文献】
1.一种UML
2.0模型动态特性的一致性验证方法 [J], 雷博;裴磐洁
2.基于UML2.0活动图的车载设备测试用例生成方法研究 [J], 靖焱林;唐涛
3.一种面向形式化表格需求模型的测试用例生成方法 [J], 汪文轩;胡军;胡建成;康介祥;王辉;高忠杰
4.基于模型的测试用例生成方法 [J], 蒲卿路;王月波;刘涛;孙云;李继秀
5.基于运行场景模型的测试用例生成和排序方法 [J], 陈子杭;肖刚;郭晓燕;姚志超;李洪宇
因版权原因，仅展示原文概要，查看原文内容请购买。

实验一：基于UML的用例模型试验实验目的：1、掌握使用visio绘制用例模型2、掌握Ration Rose绘制用例模型的方法实验内容：1、使用vise绘制用例模型2、使用Ration Rose绘制用例模型的方法实验步骤：1、使用Visio绘制用例模型（1）启动Visio中的UML模型绘制开始时需要新建一个文件存放用例模型，首先选择“开始” 一“程序” -Microsoft office visio 2003选项进入Visio启动页面，在“类别”选项区域中才、选择“软件”项：然后在“模板”选项区域中选择UML模型图，即可打开制作UML模型的全部对彖图集，Vise提供了关于制作UML模型所需要的全部图表，支持开发人员进行面向对彖的分析和设计工作。

（2）保存UML模型通过选择菜单File…Save选项或者单机工具栏的Save按钮，来保存系统模型，保存的文件类型是-VSdo(3)新建立用例图(4)建立用例中的角色(5)建立用例(6)建立角色与用例、用例与角色之间的联系(7)建立活动图2、使用Rational Rose绘制用例模型（1）Rational Rose 的启动：选择"开始"---"程序” ---Rational Software---Rational Rose Enterprise Edetion选项，弹出对话框。

这个对话框用来设置本次启动的初始动作，分为New （新建模型）Existing （打开现有模型）和Recent （最近打开模型）三个标签。

（2）新建用例图在Browser窗I I内的树形列表中选中UseCase包并右击，在弹出的快捷菜单中选择New一UseCase Diagram选项。

此时出现New Diagram用例图名称并允许修改，将NewDiagrain更名为“医疗器材管理系统用例图”双击Biowgram窗I I内树形列表中的“医疗器材管理系统用例图”，在Diagram窗I I中出现“Use CaseDiagiain： Use CaseView/医疗器材管理系统用例图”，可以在该窗1 1中绘制用例图。

面向对象方法的系统设计规格系统设计规格说明书基于UML的大学图书馆图书信息管理系统设计实验1、图书信息管理系统课题研究背景及意义随着信息技术和网络技术的迅速发展，信息化和网络化也将成为必然的趋势。

传统的图书管理模式也正经历着无纸化和网络化的飞跃。

计算机的开放性和分布性的特点以及计算能力使得图书管理突破了时间和空间的限制。

基于网络技术的图书管理系统正成为人们的研究热点之一，其中，基于计算机技术的图书管理系统已成为信息管理的重要应用之一，对这个方向的研究具有重要的理论意义和现实意义。

图书管理系统具有降低图书管理成本，解决繁重的还借工作的优点。

它可以免去图书管工作人员大量的馆务工作，图书管工作人员可以不用像以前那样各种信息必须要亲自通知，只需要在系统中发布，图书还借，预约也可以在系统中进行，一是实现了无纸化图书管理，节约了成本；二是提高了各种工作效率。

读者也不必去购买各种书籍，图书管工作人员在资源区可以上传各种新书供读者浏览；读者还借预约等信息是通过系统自动管理，为图书管工作人员免去了繁琐的文案工作。

目前国内各种高校也慢慢地将图书管理进行了信息化改造，这是大势所趋。

图书管理系统作为“质量工程”的先期启动项目，在全国范围内率先开展。

实施图书管理系统建设工程抓住了图书管理质量提高的要件和本质。

国家图书管理系统建设工程的实施，对图书借阅机构整体课程建设起到了积极的推动作用，为高校进一步提高图书管理水平提供了非常好的契机。

作为一个以传播知识为主要职能的机构，图书借阅机构建立一个自己的图书管理系统是十分必要的事情，这不仅能使更多的人享用宝贵的图书管理资源，同时也对于提升图书借阅机构自身的知名度，提高读者的自学能力，有着相当大的帮助。

2、初步设计方法与实施方案软件体系结构方案：采用C/S模式。

C/S结构（Client/Server结构）即客户机/服务器结构。

采用C/S结构是因为该结构在功能拓展和维护方面简单、方便，只需要增加或更改数据，并且C/S结构是以面向对象为主，录入简单。

形考作业3：基于UML的大学图书馆图书信息管理系统设计实验一、实验内容说明对实验2的面向对象分析结果进行系统概要设计和详细设计。

设计系统构架，勾画出整个系统的总体结构，这项工作由全组成员参加，包括主要子系统及其接口，主要的设计类和中间件等系统软件。

设计时要考虑系统的可维护性，以简单为第一原则——简单的类、简单的接口、简单的协议、简单的描述。

使用UML的配置图描述系统的物理拓扑结构以及在此结构上分布的软件元素。

用类图和顺序图对主要用例：借书、还书、处罚进行设计，并对其中的类进行详细说明，包括属性设计和方法设计。

二、实验目的（1）通过本实验使学生掌握UML建模语言的常用图形，面向对象的设计方法和过程。

特别是熟悉包图、顺序图、配置图和类图的应用。

（2）以小组形式完成本实验，锻炼同学之间的协作和沟通能力、自我学习和管理能力。

（3）学生在实验过程中熟练掌握常用的CASE工具。

三、实验学时8学时四、实验步骤（1）根据实验2画出的系统用例图和需求规格说明书规划系统的物理结构。

（2）组长和小组成员共同协商一份设计规范：设计用的图形符号、字体、大小规范，界面设计规范，用语规范等。

（3）对借书用例、还书用例、处罚用例进行用例设计和类设计。

（4）对借书用例、还书用例、处罚用例使用顺序图设计类之间的消息通信。

（5）编写系统设计规格说明书。

五、实验要求4人一组，分工如下：1名组长，负责整个小组的人员安排，工作计划，文档质量，整体项目的协调等工作；2名系统分析员，专门负责需求分析，1名分析员，专门负责系统的验收测试用例。

虽然各有分工，但大家必须协同工作。

使用VISO或IBM Rational ROSE工具软件。

各种说明书使用WORD软件。

六、结果实验结果包括：（1）系统配置图及其说明。

（2）系统体系结构划分及其说明。

（3）借书用例、还书用例、处罚用例的详细设计类图及其属性、方法说明。

（4）用顺序图分别对借书用例、还书用例、处罚用例设计类之间的消息通信说明。

ＵＭＬ在ＡＴＭ自动取款机中的应用(一)Uml 基础知识Uml 概述UML （Unified Modeling Language)是软件界第一个统一的建模语言，该方法结合了Booch ， OMT ，和OOSE 方法的优点，统一了符号体系，并从其它的方法和工程实践中吸收了许多经过实际检验的概念和技术.它是一种标准的表示,已成为国际软件界广泛承认的标准。

是一种基于面向对象的可视化的通用（General ）建模语言。

为不同领域的用户提供了统一的交流标准 — UML 图。

UML 应用领域很广泛,可用于软件开发建模的各个阶段，商业建模（Business Modeling ）, 也可用于其它类型的系统。

UML 是一种定义良好,易于表达，功能强大且普遍实用的建模语言，不是一种方法，它独立于过程。

利用它建模时，可遵循任何类型的建模过程。

建模过程：UML 的主要构成向对象分析与设计的一种UML 是一种标准化的图形建模语言,它是面向对象分析与设计的一种标准表示.由：● 视图（views ）, ● 图(Diagrams ）,● 模型元素（Model elements ） ● 通用机制（general mechanism ）等几个部分构成。

视图(views）一个系统应从不同的角度进行描述，从一个角度观察到的系统称为一个视图（view）。

视图由多个图（Diagrams）构成，它不是一个图表(Graph）,而是在某一个抽象层上，对系统的抽象表示。

如果要为系统建立一个完整的模型图，需定义一定数量的视图,每个视图表示系统的一个特殊的方面。

另外，视图还把建模语言和系统开发时选择的方法或过程连接起来。

图(Diagrams）UML语言定义了五种类型9种不同的图，把它们有机结合起来就可以描述系统的所有视图。

用例图(Use case diagram）从用户角度描述系统功能，并指出各功能的操作者。

静态图（Static diagram)，表示系统的静态结构.包括类图、对象图、包图。

基于UML的用例图模型创建UML（Unified Modeling Language）是现在使用最广泛的软件模型语言，它是一种可以应用于大型软件开发中的标准建模语言。

UML能够帮助软件开发者直观地表达软件设计和规划，同时也能方便地进行软件开发的过程管理。

其中，UML中的用例图是描述软件使用者与软件系统的交互行为的一种图示工具，用于帮助开发人员理解软件系统以及需求管理。

下面将会根据UML的用例图模型创建来讲解用例图的建立方法。

一、确定参与者在开发用例图之前，第一步应该先确定系统将会有哪些参与者（Actor）。

参与者可以是用户、外部系统、硬件设备，等等。

通过这样的方式可以很明确地将系统与用户区分开来。

二、确定用例接下来，应该确定每个参与者与系统之间存在哪些行为以及可以进行哪些操作，也就是确定用例（Use Case）。

用例就是参与者与系统之间的一种交互方式，是为了实现某种特定的目标而进行的一系列操作。

三、建立用例图在确定完参与者和用例后，下一步就是建立用例图。

在用例图中，参与者用方框表示，用例则用椭圆形表示。

每个参与者都需要某些用例才能完成自己的任务，所以在用例图中，参与者与用例之间都要有连线连接。

此外，参与者与用例之间的连线可以用带箭头的实线或虚线，实线代表主要的交互过程，虚线则代表次要的交互过程。

每个用例的名称应该简明明了地表达该用例的功能。

四、添加包含和扩展用例在用例图中，某些用例之间会存在包含关系或扩展关系。

包含关系表示一个用例包含其他用例或操作，而扩展关系表示一个用例可以在执行过程中控制或者扩展其他用例。

在用例图中，这些关系都要用带箭头的连线来表示。

五、添加关联关系除了用例之间的关系，参与者之间还会存在关系，这些关系可以是拥有关系、通信关系、以及参与者之间的关系。

这些关系也要在用例图中体现出来。

六、定稿用例图在添加所有重要的用例、参与者、以及用例关系之后，就可以将用例图定稿。

此时，应该仔细检查每个用例的名称和说明是否清晰明了，参与者和用例之间的连线是否简明直观，以及参与者和用例的位置是否合理。

基于UML面向对象的系统分析设计方法研究1、引言UML是一种编制系统蓝图的标准化语言，可以实现大型复杂系统各种成分描述的可视化、说明并构造系统模型，以及建立各种所需的文档，它是一种定义良好、易于表达、功能强大且普遍适用的建模语言。

UML的发展对软件工程的发展做出了杰出的贡献。

UML支持从需求分析开始的软件开发的全过程。

UML通过三类图形建立系统模型：用例（Use Case）图、静态结构图（对象类图、对象图、组件图、配置图）和动态行为图（顺序图、协同图、状态图、活动图），这些图可以从不同的抽象角度实现系统的可视化。

URM的发展经历了以下几个阶段。

最初的阶段是专家的联合行动，由三位OO（面向对象）方法学家[8]将他们各自的方法结合在一起，形成UML 0.9。

第二阶段是公司的联合行动，由十几家公司组成的“UML 伙伴组织”将各自的意见加入UML，形成UML 1.0和1.1，并作为向OMG申请成为建模语言规范的提案。

第三阶段是在OMG控制下的修订与改进，OMG于11月正式采纳UML 1.1作为建模语言规范，然后成立任务组进行不断的修订，并产生了UML 1.2、1.3和1.4版本，其中UML 1.3是较为重要的修订版。

目前正处于UML的重大修订阶段，目标是推出UML 2.0，作为向ISO提交的标准提案。

1.1 UML的特点UML具有以下特点[1]：(1)面向对象。

UML支持面向对象技术的主要概念，提供了一批基本的模型元素的表示图形和方法，能简洁明了地表达面向对象的各种概念。

(2)可视化，表示能力强。

通过UML的模型图能清晰地表示系统的逻辑模型和实现模型。

可用于各种复杂系统的建模。

(3)独立于过程。

UML是系统建模语言，独立于开发过程。

(4)独立于程序设计语言。

用UML建立的软件系统模型可以用Java、VC++、SmalltaIk等任何一种面向对象的程序设计来实现。

(5)易于掌握使用。

UML图形结构清晰，建模简洁明了，容易掌握使用。

基于UML的大学图书馆图书信息管理系统设计实验系统简介本系统为一个小型的图书管理系统，需完成以下工作：（1）借书、还书（2）在图书馆中增加或删除一本书（3）按照作者或者专业领域查找一批书（4）找出被某位读者借出的一批书（5）找出最近借出某本书的读者系统的用户有两类：图书管理员和普通读者。

功能（1）（2）（5）只供图书管理员使用，功能（4）只能供读者查找自己借出的书，功能（3）为管理员和读者的共同功能。

本系统需满足以下限制：（1）图书馆中所有未借出的书可供读者随时借阅（2）在同一时刻，一本书不能既被借出又可供阅读（3）一个读者一次借出图书的数目不能超过预定值1、用例分析与设计从以上系统简介容中可以看出，本系统有以下几类参与者：图书管理员Admin读者Reader读卡器CardReader服务器System在上述参与者中，图书管理员和读者与系统进行交互，通过对交互场景进行归类和抽象，本系统应具有以下用例：借书lendBook还书returnBook增加图书addBook删除图书delBook按作者、专业检索图书findBook_Author按读者检索图书findBook_Reader按书检索读者findReader_Book2.1生成用例图由以上用例分析可生成用例图，如图2.1所示图2.1 系统用例图2.2用例的顺序图为了使每个用例的操作流程更简洁明了，本系统采用UML的顺序图来对每个用例进行细化，如下所示。

1、借书图2.2 借书顺序图函数说明：InsertCard（）：刷卡ReadCard（）：读卡ifMax（）判断借书数量是否达到上限ReturnReaderInfo（）返回读者信息Return（true）：该读者可继续借书lendBook（）：输入借书信息Update（）更新数据库2、还书图2.3 还书顺序图函数说明：BookInfo（）：输入还书信息Update（）：更新数据库ReturnReaderInfo（）：返回读者信息3、增加图书图2.4 增加图书顺序图函数说明：addBook（）：输入增加的图书信息ifAllowsAdd（）：判断是否允许添加Update（）：更新图书信息Return（true）：返回添加成功4、删除图书图2.5 删除图书顺序图函数说明：delBook（）：输入删除的图书信息ifAllowsDel（）：判断是否可以删除ifSure（）：是否确定删除Return（true）5：确定删除Update（）：更新图书信息Return（true）7：返回删除成功5、按作者检索图书图2.6 按作者或专业检索图书顺序图函数说明：findBook_Author（）：管理员或读者选择按作者或专业检索图书Author（String）：输入作者或专业信息returnBookInfo():返回图书信息6、按读者检索图书管理员部分：图2.7 按读者检索图书顺序图图2.8 读者检索个人借阅图书顺序图函数说明：findBook_Reader（）：选择按读者检索图书ReaderId（）：输入读者编号ReaderIdandPass():输入读者编号密码returnBookInfo（）：返回书籍信息7、按书检索读者图2.9 按图书检索读者顺序图findReader_Book()：选择按图书检索读者BookID（）：输入图书编号returnReaderInfo（）：返回读者信息2、概念模型和顶层架构设计3.1概念模型设计图3.1 系统概念模型——分析类图说明：表示控制类表示实体类表示边界类3.2顶层架构设计图3.2 系统顶层架构3、用户界面设计4.1 界面变化分析根据管理员的功能分析，与管理员相关的主要界面有以下10个：Admin Welcome：管理员主界面findReader_Book：按读者检索图书界面lendBook：借书界面returnBook：还书界面addBook:增加图书界面delBook：删除图书界面findBook_Author：按作者或专业查找图书界面findBook_Reader：按读者检索图书界面UserInfo：显示读者信息界面BookInfo：显示图书信息界面各界面之间的转换如状态图4.1所示图4.1 管理员屏幕变化状态图根据读者的功能分析，与读者相关的主要界面有以下5个：Reader Welcome：读者主界面findBook_Author：按作者或专业查找图书界面findBook_Reader：按读者检索图书界面InputPass：读者验证账户名密码界面BookInfo：显示图书信息界面各界面之间的转换如状态图4.2所示图4.2 读者屏幕变化状态图4.2 界面的类图表示针对每个屏幕的结构及功能，采用类图对其进行详细说明，如下所示。

基于ＵＭＬ的企业资产管理系统的分析与设计利用UML对企业资产管理系统进行了分析与设计。

采用以用例图为驱动方式、活动图和顺序图进行系统的动态建模，定义了类图进行系统的静态建模。

标签：资产管理系统用例图活动图类图顺序图固定资产管理(以下简称资产管理)是企业重要的经济资源和赖以生存发展的物质基础。

如何确保对企业固定资产进行科学管理，健全各项资产管理制度，提高企业的市场竞争力，构建一套企业资产管理系统是十分必要的。

目前管理信息系统的开发与设计主要采用面向对象的方法，而UML( Unified Modeling Language)是一种面向对象的建模语言,它采用一整套成熟的建模技术，已广泛地应用于信息系统的分析和设计过程中。

本文就是利用UML中的各类模型对资产管理系统的功能、业务流程和行为进行描述，构建更可靠和更完善的系统模型。

一、UML建模的概述UML建模是利用图形符号来描述现实世界各个对象，适用于系统的需求描述、系统概要设计和详细设计的全过程。

UML建模过程是以用例为驱动和采用迭代的建模过程，具体步骤如下：1.识别和确定系统的用例和执行者。

首先要对原系统进行需求调研，识别出系统的用例和执行者；接着分析各执行者之间、用例之间以及用例和执行者之间的关联；最后利用UML的用例图规范化描述出系统的功能模型。

2.建立系统的静态模型和动态模型。

以用例为驱动，采用UML的活动图表示具体用例内部及用例之间的工作流；从功能模型图中抽象出各种类及其属性和操作等特征，并以类图方式描述各种类之间的关系；最后使用顺序图描述在特定环境下这些类的实例表现出来的行为特征。

二、资产管理系统模型1.系统的用例图。

在资产管理系统的功能需求分析基础上，分层构建出该系统的顶层用例图和子系统的用例图并详细描述每个用例的处理过程。

如图1是计划管理子系统用例图，其中有建立采购计划、修改计划和查询计划三个用例。

图1 二级用例图之一计划管理子系统用例图2.活动图。

图书馆管理系统建模设计-------基于UML一、图书馆管理系统需求分析1.1系统目标设计图系统开发的总目标是实现内部图书借阅管理的系统化、规范化和自动化。

能够对图书进行注册登记，也就是将图书的基本信息（如：书的编号、书名、作者、价格等）预先存入数据库中，供以后检索。

能够对借阅人进行注册登记，包括记录借阅人的姓名、编号、班级、年龄、性别、地址、电话等信息。

提供方便的查询方法。

如：以书名、作者、出版社、出版时间（确切的时间、时间段、某一时间之前、某一时间之后）等信息进行图书检索，并能反映出图书的借阅情况；以借阅人编号对借阅人信息进行检索；以出版社名称查询出版社联系方式信息。

提供对书籍进行的预先预订的功能。

提供旧书销毁功能，对于淘汰、损坏、丢失的书目可及时对数据库进行修改。

能够对使用该管理系统的用户进行管理，按照不同的工作职能提供不同的功能授权。

提供较为完善的差错控制与友好的用户界面，尽量避免误操作。

1.2系统功能需求分析(1) 读者管理：读者信息的制定、输入、修改、查询，包括种类、性别、借书数量、借书期限、备注等。

(2) 书籍管理：书籍基本信息制定、输入、修改、查询，包括书籍编号、类别、关键词、备注。

(3) 借阅管理：包括借书，还书，预订书籍，续借，查询书籍，过期处理和书籍丢失后的处理。

(4)系统管理：包括用户权限管理，数据管理和自动借还书机的管理满足以上需求的系统主要包含有一下几个子系统（1）基本业务功能子系统：该系统中主要包含了借书还书和预订等功能。

（2）基本数据录入功能子系统：该子系统主要包含有书籍信息和读者信息录入功能。

（3）信息查询子系统：包含了多功能的查询书籍信息和读者信息。

（4）数据库管理功能子系统：主要包含了借阅信息管理功能，书籍信息管理功能和预订信息管理功能。

（5）帮助功能子系统。

下图为该图书馆管理系统的主要功能模块图：图1：图书馆管理系统功能模块图1.3功能描述（1）借书。

处理借书业务。

UML建模课程设计目录1 引言 (4)2 UML概述 (4)2.1 UML简介 (4)2.2 UML模型图的构成 (4)2.3UML事物 (4)2.3.1构件事物 (5)2.3.2行为事物 (5)2.3.3分组事物 (5)2.3.4注释事物 (6)2.4 UML图及特征 (6)2.4.1 用例图 (6)2.4.2 类图 (6)2.4.3 对象图 (6)2.4.4 时序图 (6)2.4.5 协作图 (7)2.4.6状态图 (7)2.4.7活动图 (7)2.4.8组件图 (7)2.4.9配置图 (8)3 UML结合实例分析 (8)3.1 需求分析 (8)3.1.1系统开发需求 (8)3.1.2系统功能需求 (8)3.2 UML建模分析 (9)3.2.2类图 (10)3.2.3 活动图 (11)3.2.4 顺序图 (12)3.2.5 协作图 (13)3.2.6 状态图 (14)3.2.7 组件图 (15)3.2.8 部署图 (15)4 总结 (16)1 引言建模是开发优秀软件所有活动的核心部分。

在开发中利用UML来编制系统蓝图,并与仓库管理系统开发的特色相结合,提出了自己的一套UML的建模过程。

基于这个过程来进行系统的分析,设计,实现与测试。

运用UML建模思想与各种模型对仓库管理系统进行详细的描述。

2 UML概述2.1 UML简介UML (Unified Modeling Language)为面向对象软件设计提供统一的、标准的、可视化的建模语言。

适用于描述以用例为驱动，以体系结构为中心的软件设计的全过程。

UML的定义包括UML语义和UML表示法两个部分。

UML语义：UML对语义的描述使开发者能在语义上取得一致认识，消除了因人而异的表达方法所造成的影响。

UML表示法：UML表示法定义UML符号的表示法，为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。

2.2 UML模型图的构成事物(Things)：UML模型中最基本的构成元素，是具有代表性的成分的抽象关系(Relationships)：关系把事物紧密联系在一起图(Diagrams )：图是事物和关系的可视化表示2.3UML事物UML语言的事物,包括四类:结构事物:语言的静态构成要素，有7种：类和对象、接口、主动类、用例、协作、构件、节点。

一个基于UML 协作图的集成测试用例生成方法王林章,李宣东,郑国梁(南京大学计算机科学与技术系,江苏南京210093)摘 要: UML 协作图描述了系统的一个协作过程中参与对象之间的结构关系和交互行为,确认它们是否被正确实现是集成测试的工作.本文提出了一个基于UML 协作图生成集成测试用例的方法,将表示设计的协作图作为测试模型,首先通过遍历每条消息的直接后继识别协作图中的表示用例实现的所有可能的场景路径,然后在遍历每条场景路径的过程中获取相应协作执行的路径条件、参数变量和预期方法调用序列,最后使用范畴-划分方法确定场景路径上的输入、输出、环境条件的合理组合作为覆盖该场景路径的测试用例,用于测试一个协作场景路径上的交互行为.该方法,集成了白盒方法和黑盒方法,在覆盖所有的测试需求的前提下,生成的测试用例较少.关键词: 测试用例生成;集成测试;UML 协作图;场景路径中图分类号: TP311 5 文献标识码: A 文章编号: 0372-2112(2004)08-1290-07An Approa ch to G enerate Integration Test Cases Based onUML Collaboration DiagramsWANG Lin -zhang,LI Xuan -dong,ZHE NG Guo -liang(CS De partment,Nanjing U nive rsity ,Nanjing ,Jiangsu 210093,China)Abstract: UML collaboration diagrams represen t the structure relationship and interactive behavior of the objects involving in acollaboration of the software system,whether they are correctly implemented or not could be validated by integration tes ting.An ap -proach is proposed to generate integration test cases based on UML collaborati on diagrams.It takes a collaboration diagram as the test model,it identifies all the scenario paths i n the diagram which represents use case realization by traversing the direct successors of each message.It selects and traverses each scenario path to get the method call sequence,path condi tion and parameters.It applies category parti tion method to generate rational combination of input parameters,environmental conditi ons,as well as the corresponding outpu t and method call sequence,to form a test case for each scenario path.This method,combines white -box and black -box test method to generate fewer test cases to test the gray -box behavi or,as well as to cover all the i ntegration req uirements.Key words: test cases generation;in tegration testing;UML collaboration diagram;scenari o path1 引言面向对象技术和统一建模语言(UML)在软件工程发展进程中具有里程碑的意义,自提出后,先后成为研究热点,并且迅速在工业界得到广泛的应用,他们对开发高质量软件起了很大的促进作用,但仍不能保证软件零缺陷,还给软件测试带来新的挑战[1~3].软件的复杂度随着软件规模的不断增大而增大,面向对象系统开发过程中克服软件复杂性的思想是将软件系统划分不同粒度的基本单元分别实现,如类、组件、子系统等,然后通过集成这些单元来构造系统.单元之间通过交互实现系统的行为,所以对交互过程的建模也是设计阶段重点关注的内容,UML 协作图[4]描述了上述交互,表示了行为的集成.在结构和行为集成的每一个环节都可能引入错误,导致软件中存在缺陷,要发现并排除这些缺陷,集成测试非常重要[5].在面向对象语境下,传统的集成测试方法不能直接使用[6],而且用UML 模型描述系统给信息的提取带来了新的问题.测试工作的核心主要是生成测试用例,在基于UML 的面向对象软件系统中,分析模型、设计模型是软件在其生存期不同阶段的变体,是生成最终程序的基础,也是生成测试的信息来源.当然他们在每一阶段的测试中都起相应的作用,特别地,分析模型是生成系统测试的测试用例的基础和系统测试的检验依据,设计模型是生成集成测试用例和集成测试的检验依据.设计模型包含规约和程序结构的信息,同时也描述了收稿日期:2003-07-28;修回日期:2004-03-20基金项目:863项目(No 2002AA116090);自然科学基金项目(No 60207036,60233020);973项目(No 2002CB312001)第8期2004年8月电 子 学 报ACTA ELECTRONICA SINICA Vol.32 No.8Aug. 2004图1 ATM 建立一次会话实例的协作图系统的相应功能片断的行为,因此可以结合白盒测试和黑盒测试方法,从设计模型生成集成测试用例.在设计阶段结束后,利用成为基线的设计模型生成所需的测试用例,可以在代码阶段结束后便可以开始测试工作,便于合理组织测试资源,而且对设计模型进行分析的同时也能发现设计本身的缺陷,以便及时排除,以防缺陷随着软件开发过程的进展而被放大.我们希望能够研究出仅从UML 设计模型图自动生成测试用例的方法,能够实现部分自动化而不增加用户额外的工作量,这样的测试方法容易被已经使用UML 的工业界采用[7,8].2 协作图与集成测试2 1 协作图的语法和语义UML 协作图就是用来表示一组通过交互来实现某些行为的对象,可以用来按交互中的角色及其关系对一个用例的特定的实现场景进行建模.它描述了特定行为的参与对象的静态结构和动态交互.动态交互部分是一个消息集合,用协作实现过程中的消息流定义系统行为方面的内容[9,10].本部分介绍一个客户通过ATM 上验证用户卡和PIN 有效性、建立会话的用例片断[5]的实例级协作图,如图1所示.协作图上存在条件消息说明考虑到许多不同的用例场景,涉及到多个对象之间的交互,其中每一个场景都对应协作图上的一条执行路径,这正是测试所要尝试的.图2表示了在这个协作中参与对象相应的类图.图2 图1AT M 用户验证的类图一个描述用例实现的实例级协作图上用于建模的元模型包括:类元角色名、关联角色名、对象符号、链接符号、消息符号、链上的约束等.对象框能够表示参与协作中交互的对象,链表示这些对象之间的结构关系,消息的箭头形状表示协作对象间的通信模式和对象的执行特征,消息标签表示对一个对象的操作调用的允许顺序的实例、操作的语义.在实际的建模活动中有些元素并不在模型上反映,例如图1的协作图只表示了协作中参与的对象之间的消息,这是表示对象交互的最小元素集.本文关注协作图表示的动态行为的测试,前面提到协作图上表示交互的主要元素是消息,下面详细介绍消息.协作图中的消息用带有消息标签的箭头表示,附在连接发送者和接受者的链上,链用于访问目标对象,箭头沿着链指向接受者,一个链上可以有多个消息,沿着相同或不同方向传递,消息的相关顺序由消息标签中的顺序号表示.按照UML1.5[6]中提出消息箭头有三种形状表示对象之间的通信方式和控制流类型:实线实心箭头表示同步消息,用于表示过程调用和嵌套控制流,每次调用增加一个嵌套层次;刺状箭头表示平面控制流,是异步通信,无嵌套,表示前驱-后继关系,指向下一步骤;虚线刺状箭头表示从过程调用返回.图1中的消息都是带有刺状箭头的实线,表示前驱/后继关系.消息标签说明发送的消息、发送的条件、由消息激活的方法、相应的参量和返回值,以及交互中的消息顺序,包括调用嵌套、迭代、分支、并行和同步,完全格式消息标签的语法文献[10]中有详细的定义.其语法如下:[predecessor ][guardcondition ][sequence -expression][return -value -list]:=message -name (argument)[predecessor]表示前驱,在协作中前驱是用逗号隔开的顺序号列表,并后跟 / ;[guardcondition]表示线程同步的卫式条件;[sequence -expression]表示顺序项列表,每一项表示交互中的一个嵌套层次,如果所有的控制并行则无嵌套;整数表示过程调用中的相邻高层中的消息的顺序,同一整数项中的不同消息在嵌套层是顺序相关的,同一前缀的消息顺序号构成序列.循环表示条件或迭代执行,表示根据条件执行零个或多个消息;[return -value -lis t]在有返回值的情况下表示消息返回值的名称,名称之间用逗号隔开,可以作为后续消息的参量;message -name 表示目标对象中引发的事件名称,可以用不同的方式实现,如操作调用;argument 是消息引发的方法的参量列表.消息上的条件增加了消息的表达能力,也增加的消息复杂度,消息上的条件有几种形式:在一个新的调用层次开始,如图1中消息标签4.1[i sMemberCard]feeAmoun t:=get -feeAmount()所示:4.1表示一个新的调用序列,条件成真时该层次的消息顺序发送,否则都不发送;在顺序发送的消息上,例如消息1.3中,[notATMCard]条件表示二值条件,条件成真时其后的消息eject()执行一次,否则不执行,对其他消息没有影响;在一个表示迭代的嵌套调用消息开始,如消息3.1.1表示了一个迭代执行多个消息的情况,根据validPIN 和n 的取值可能发送1或2次消息.这些协作图上的模型元素所表示的软件系统的不同方面1291第 8 期王林章:一个基于UML 协作图的集成测试用例生成方法的信息,都是系统的本质信息,需要在软件从设计到实现过程中必须保持的,因而软件实现中的行为的本质方面都会在设计中表示,所以可以从设计表示中获取行为方面的信息,用于确认软件实现中是否正确实现.2 2 场景路径一个表示用例实现的协作图实现了用例的不同事件流,包括正常流和异常流,每个事件流称为一个场景,这些场景都被相应的协作图实现.一个协作图所表示的协作正是从一个外部事件触发开始,在参与协作的对象之间完成一系列的交互,最后正确的协作结束时都导致一个外部输出,这也是一个线程执行的路径.要找到这些路径,一般的方法是将协作图转换为流图,然后在流图上使用图遍历的方法达到路径覆盖从而得到所有的路径.本文为了避免复杂流图的转换和不可行路径的遍历开销,试图直接从协作图上获取这些路径.我们从Paul C Jorgenson[5]定义的原子系统功能(ASF)和方法/消息路径(MM-path)得到启发,本文定义了一个场景路径(scenario-path):定义 场景路径(scenario-path,s-path)是协作图上从一个没有前驱消息的消息开始,沿着消息的偏序执行序列,到达一个没有后继的消息结束的由消息相连的方法执行序列.由于面向对象软件的事件驱动特性,软件的执行由事件开始,反映场景执行的场景路径由一个外部事件触发的消息(没有前驱消息)开始,表示路径入口,通过消息传递访问协作图中参与一个协作场景实现交互的对象的方法序列,达到一个引发端口输出事件的方法且该方法自己不再发出新的消息(没有后继消息)结束,到达路径出口,这时系统处于静止状态,等待另一个系统级端口输入事件开始进一步的处理.场景路径表示了协作图中的一个场景的线程执行的完整踪迹,也是参与协作的对象之间的交互的踪迹,消息的传递激活对象方法的执行是对象之间控制流的转移,而路径中通过消息激活的方法调用的参数定义和使用、对象的创建、使用和撤销明显表示了一条在控制流上执行的数据流.由于协作图在表示用例实现时,协作图上的场景路径是从第一条入口消息开始到所有能触发端口输出事件或没有后继消息的出口消息之间的所有可能的消息流.要获取场景路径上的消息流,可以通过消息之间的偏序关系以及决定消息流分支和循环的条件来实现.回顾协作图上消息及其顺序号的定义,整数表示过程调用中相邻高层中的消息顺序,同一整数项下的不同消息是表示一个前驱-后继式的平面控制流,嵌套的消息顺序号表示过程的调用控制流.消息顺序号隐含地表示了消息之间的偏序关系,因此可以在协作图上提根据消息的发送条件及其顺序号来跟踪场景路径.协作图上的分支和循环导致了许多可能的路径,极端的情况下路径的数目可能到达一个庞大的数字,要达到协作图上的路径覆盖,采用简单的方法达到判定/循环覆盖.先将循环消息看作条件消息,在遍历场景路径的过程中,访问一条消息后,先找出该消息可能的直接后继,然后采用深度优先的方法选择一个直接后继继续遍历,当到达一个没有后继的消息时,就完成一个场景路径的遍历,回溯到前一消息的下一个直接后继,继续遍历,只到所有消息的所有直接后继都已被访问,则完成了所有的场景路径的遍历.这样实现每条消息至少遍历一次,每个条件分支都至少遍历了一次,也避免了路径的穷尽覆盖.然后处理协作图上的循环,一般是给出绕过循环、循环一次、循环最多次以达到循环路径的覆盖.对于存在分支和循环的场景路径,例如图1所示的协作图上有7个条件判断和一个最大次数为2的循环,可能的路径有2*2*2*2*3*2*2*2=384条,但由于有5个条件判定各有一个分支直接导致场景路径结束,所以实际的场景路径应为1+1+1+1+1+3*2+2= 13条,这13条场景路径对应相应软件功能的13个执行场景.在协作图上遍历生成场景路径的同时,很容易基于路径覆盖准则获取相应场景执行过程中的控制流和数据流、覆盖路径的条件,然后可以确定每一路径所需要的输入和状态条件,当满足所有路径条件时线程就会沿着该路径执行,这正是定义集成测试用例所需要的信息,因此被看作基于协作图的集成测试的基础.下面分析协作图表示的协作在实现中通过参与者之间的集成完成时可能发生的故障,这样便于研究针对检错为目的的测试.2 3 基于协作图的协作集成测试模式协作图上描述的消息的错误实现可能导致协作中表现的行为发生偏差,从而使最终实现与设计不一致,偏离软件规约规定的功能.例如由于消息名的编码错误、错误的参数、不正确的参数值、不正确的或缺少输出以及非预期的运行时绑定导致的错误方法调用;消息前驱约束实现错误导致发送者对象发送违反接受者对象前提条件的消息或者发送者对象发送违反接受者对象的顺序约束的消息;消息的发送者或接受者对象错误导致错误的对象和消息的绑定;参与者缺少功能或特征导致错误的对象引起正确的异常、正确的对象产生错误的异常.所以链上的消息箭头和约束、消息标签、对象等协作图上的元素未按设计正确实现会导致最终的软件与设计不一致,如果协作图的实现中存在错误,肯定在协作图至少一条路径上,要定位该错误,在未知该错误在那条路径上时,只能通过协作图上选择所有可能的执行路径,并导出能够跟踪这些路径的测试用例,并用它们来执行软件,来确定错误在哪条路径上,从而可以调试软件,改正错误,以保证实现与设计一致.这些可能发生的错误都是在参与协作的对象之间交互时发生,也就是系统在通过不同对象的方法之间集成实现系统的行为时发生,这种错误通常通过集成测试来发现.在面向对象的语境中我们可以通过基于线程或基于使用的测试技术测试对象的交互.用协作图描述的交互行为在集成测试时,协作集成是最佳的测试模式[5],通过在协作中参与的组件来决定集成测试所有参与的对象.基于协作的集成测试需要检测协作的参与者之间的接口和交互,通过协作组织集成.每次处理一个协作,直到协作图上的所有协作都被测试,也即要求系统中每个对象之间的消息已经被至少测试一次时集成测试完成.协作图是对象、组件、子系统、系统范围测试需求的良好来源,对系统的一个有限片断来说,提供了实现的抽象视图,它通常是过多或过少细节之间的一个良好的折中,可以用于1292 电 子 学 报2004年在不同抽象级别和粒度级别建立软件系统的模型.由于协作图是描述的对象之间的交互,而系统的功能正是通过这些交互实现的,所以要考虑将设计描述的协作图作为生成集成测试的测试用例的测试模型.协作图上包括了对象间传递的消息及其顺序,这正是设计级的控制流和数据流信息,以往数据流和控制流只能从程序源码中分析得到.数据流和控制流对生成测试有很大的作用,所以我们利用协作图生成测试用例,就是要从协作图上提取出相应的数据流和控制流信息,利用传统的数据流、控制流生成测试用例的方法,生成可用于集成测试的测试用例.所以本文使用作为系统设计描述的协作图作为测试行为的测试模型,避免重新构造测试模型或者进行模型转换.2.1中分析了协作图中描述的信息,这也是作为测试模型的协作图中包含的对生成测试用例有用的信息,这些信息是规约在转变成实现时必须保持的,这些信息也是测试时要确认在软件实现中是否正确保持的设计信息,因此这就是测试工作第一步要获取的测试需求.测试需求的正确实现要求也就是测试规约,它规定了能让软件执行并正确反应测试需求的测试用例.如果我们能够用足够的测试用例执行了程序,并证明协作图上所有测试需求都在软件中正确保持了,就可以说测试充分了,本文主要关注协作图表示的系统的动态交互行为,而协作图上用于表示交互行为的主要是消息及其偏序序列,所以本文研究的测试方法的充分性准则是协作图上所有的消息及其偏序关系都被测试用例覆盖.一个场景路径上由消息激活的方法序列表示了要测试的行为,路径上对象间的消息传递描述了要实现相应的功能对象间必要的交互,协作图上场景路径的覆盖能够满足充分性准则,这样就可以把问题转换到满足协作集成测试需求的场景路径的分析和处理上,第3部分详细描述从协作图生成测试用例的方法.3 基于协作图生成集成测试用例的方法3 1 研究假定为了有针对性地解决从协作图生成测试用例的问题,本文假定:(1)协作图描述的协作与用例图描述的规约是一致的.模型本身的验证是通过非形式化的复审和形式化的模型检验方法进行的,已超出本文的研究范围;如果协作图上的场景路径集不能覆盖所有消息,则说明协作图本身有错误;(2)系统中的对象都是自行开发的,不包括第三方组件对象,文中的对象可以是不同粒度的对象(类的实例、类簇、组件、子系统、系统),也就是说我们在分析任意对象或类时,在必要的情况下都可以获取其规约和内部详细设计信息;(3)只研究针对检错进行的动态交互行为的测试;(4)本文为了明确解决问题,假定消息类型只有普通消息、条件消息、循环消息,而且只存在顺序循环,不存在嵌套循环.3 2 方法概述基于协作图的集成测试(Collaboration diagram-based Inte-gration T esting,CIT)方法集合了传统的白盒测试方法和黑盒测试方法,用于测试协作图中参与协作的对象之间通过消息的交互,对每个协作图处理一次,得到相应的测试用例集.首先分析协作图,根据消息的顺序号和消息的条件,找到每一条消息的直接后继消息,然后根据场景路径的定义,使用深度优先方法遍历消息及其直接后继直至到达无直接后继的消息从而生成场景路径,然后回溯到没有被访问的直接后继,重复上述方法找到所有的场景路径;在访问消息获取场景路径的同时,获取该路径的方法调用序列、参数和路径条件,将这些集成测试的关键因素用范畴-划分方法定义为方法序列、环境条件、系统输入、系统输出等范畴,结合该协作片断的用例规约和类图中的定义生成这些范畴的可能选择,然后结合路径约束条件在这些范畴的划分中确定选择项的合理组合,这样我们就等到了该场景路径完整的测试用例,包括外界输入、交互输入、预期方法调用序列、后条件、预期输出.对协作图中的所有场景路径都构造了测试用例,就形成了协作集成测试用例集.这样在实际执行集成测试时不但可以直接观察到系统级的输入作用下协作实现过程中的实际输出,还能够通过动态插装方法在代码中加入不影响软件功能的观察代码,使测试人员能够观察到实际协作执行时的方法调用序列和数据流的定义和使用,然后通过比较最终系统实际执行时输出与预期输出的一致性决定该协作实现的功能是否正确,通过比较应该发生的方法调用序列和实际执行时观察到的方法调用序列是否一致,确定协作表示的交互行为是否正确.本方法可以以增量的方法进行,最终生成的测试用例的具体程度,与相应UML模型图的设计精化程度相关,因为协作图描述的场景的详细程度与测试用例的表达能力直接相关.3 3 U ML协作图生成测试用例的算法描述CIT方法能够从协作图规约文档直接生成测试用例,主要描述分析协作图规约文档提取集成测试需求信息并生成消息后继表的算法UMLspecificationparser(),然后为每个消息确定其直接后继消息的findsuccessor()算法,根据消息后继表遍历所有场景路径获取测试用例规约信息的spathgenerator()算法,以及从测试用例规约使用范畴划分方法确定测试用例输入值、预期输出值、预期输出行为的算法testcasegenerator(). UMLspecificati onparser()算法从协作图从获取集成测试需求信息是通过对UML协作图规约的文本文件(如Rational Rose的MDL文件)进行分析完成的[11],在本文的工具框架中实现相应的功能,本文对分析算法不作详细描述.本文用邻接表定义消息后继列表,将分析结果信息按消息顺序号升序记录到messagelist的表头中,以便下一步处理.本文定义消息后继列表如下:messagei te m{mid:s tring;//消息顺序号mguardcondition:s tring;//消息卫式条件表达式mlabel:stri ng;//消息标签msender,mreciever:object;//消息发送者对象,消息接收者对象mmethod:method;//消息激活的方法mtype:[flat fl ow,procdure call,call return];//根据消息的箭头及线型划分的消息类型link:pointer of ms uccessor;1293第 8 期王林章:一个基于UML协作图的集成测试用例生成方法}ms uccessor{mi d:stri ng;//后继消息顺序号mscondition:s tring;//选择该后继的条件表达式next:poi nter of ms ucces or}mes sagelis t:messageitem[n];fi nds uccessor()算法为消息生成直接后继列表并记录到消息的后继链表中,描述如下:fi nds ucces sor(mess agelist){//找到所有消息的所有可能后继和每个后继条件//输入:消息后继表messageli st//输出:消息后继表messageli st//出口准则:所有消息都处理完for i:=1to n do{i f i==n或者messageli st[i]为端口输出事件触发消息mes sagelis t[i].li nk=nil;i:=i+1;//最后消息或触发端口输出事件的消息无后继消息els e{if mes sagelis t[i+1]是普通消息则messagelis t[i]的直接后继为messagelist[i+1];els e{k:=1;do while messageli st[i+k]是条件消息{messagelis t[i+k]是mess agelist[i]的直接后继,且条件为mes sagelis t[i+k]的条件取真if messageli st[i+k]是循环或嵌套层次的第一个消息{t:=该层次的消息数;mes sagelis t[i+k+t]是mes-sagelis t[i]的直接后继;条件为messagelist[i+k]的条件取假;k:=k+t;} //条件取假时循环或嵌套内的消息都不发送el se{messagelis t[i+k+1]是messagelist[i]的直接后继;条件为messagelist[i+1]的条件取假;k:=k+1;//不发送}endif}enddoendifi:=i+1;}endif}endfor;}endfindsuccess or;spathgenerator()通过访问消息后继表中消息及其直接后继生成场景路径,在遍历场景路径时同时记录路径上相应的控制流和数据流信息,执行完毕得到一个场景路径集spath相应的控制流数据流测试规约.其算法描述如下:s-pathgenerator(m:msuccess orlis t){//输入:mes sagelis t;(消息后继表)//输出:spath;(场景路径集)spath{sid:integer;//场景路径顺序号pathcondi ti on:li st of gardcondition;//场景路径的实现条件mlis t:lis t of mes sage;//场景路径上的消息流列表parameters:li st of variable;//场景路径上定义和使用的变量列表us erinputparameters:lis t of variable;//场景路径上外界输入参数列表methodsequence:{objectname,methodname,ne xt};场景路径上由消息激活的方法序列}[n];i,j:integer;i:=1;j:=1;Sid:=j;//场景路径序号//递归访问消息及其直接后继访问消息m,在消息标签中取出并记录返回值、参数、调用的对象方法;记录消息条件到路径条件中;if m的后继消息为空{ 一条场景路径结束;j:=j+1;return;}//回溯到m[i]的直接前驱继续else{k:=1;while m.link<>nil do{//m的后继消息列表不空success or:=m.link;spathgenerator(s ucces sor)//深度优先遍历该消息及其后继消息m.link:=success or->next;//下一后继消息;}endwhile}endi f;}endfi nd;testcasegenerator()选定遍历一个场景路径过程中生成的控制流和数据流,定义相关范畴,生成测试用例的规约.消息激活的方法序列正是我们要测试的对象间的交互,是软件执行时表现出来的对象之间的控制流传递行为,是对象之间通过消息交互的结果,定义为交互范畴Interaction Category;输入参数列表为测试该场景时外界的输入,定义为输入参数范畴input parameter Category;我们通过对参与协作对象的类图的分析,以及用例描述,可以获取我们所研究的交互行为定义、输入参数的定义、其他影响消息执行的变量的定义、系统环境条件的定义等,从而可以获取这些系统环境条件、输入参数、方法行为的可能选择,然后结合.利用范畴-划分思想,用相应场景路径的路径条件和加在消息上的约束、以及系统本身的属性约束来限定这些选择,排除无意义和有冲突的值,然后通过这些不同的范畴的不同选择的可能组合作为一个场景路径的测试用例,这样每个场景路径生成一个集成测试用例.具体算法描述如下:Testcasegenerator(){//输入:spath[n]//输出:tcsuite[n]{envirnmentpara,input(inputpara,paravaliue),ex-pectoutput,pos tcondition}i:integer;for i:=1to n do{tcsui te[i].postcondition:=s path[i].pathcondi tion;tcsui te[i].envi ronmentpara:={满足路径条件的环境条件}tcsui te[i].i nput.i nputpara=spath[i].userinputs para menters;选择对本场景路径条件有影响的参数确定其可能的取值;1294 电 子 学 报2004年。