（计算机软件与理论专业论文）基于uml模型的测试场景生成研究与工具实现.pdf

生苎塑薹一 基于u m l 模型的测试场景生成研究与工具实现 学科专业：计算机软件与理论 指导老师：张为群教授 研究方向：软件工程 研究生：谢棠棠( 2 0 0 2 4 9 6 ) 中文摘要 随着软件开发从传统的结构化开发到面向对象的开发过程，以及最近提出 的模型驱动的架构开发，对软件测试产生很大的影响，同时也对软件测试的研 究与实践带来新的挑战。以掩件系统、分布式软件、嵌入式软件等为代表的异 构软件系统正在成为当前软件发展的一个主要趋势，由于这些异构软件在硬件 平台、软件平台上的多模式特点导致这类软件在开发和钡i 试中存在着大量特殊 性，对软件测试也提出了新的阿题，研究适合于异构软件特点测试技术已成为 当前亟待解决的重要问题。 u m l 作为建模语言事实上的标准，近年来被学术界和工业界广泛地用于软 件系统建模。从测试角度看，这些模型是获取系统结构和行为信息的来源，因 而是测试生成的理想基础，用这些模型驱动测试是很自然的想法，使得测试工 作可以尽早开始，及时发现和排除软件开发过程中引入的缺陷。但目前还没有 标准的或者是普遍接受的方法而且测试过程中能够得到的自动化程度依赖于 规约或设计的精确性。 本文对u m l 动态模型中的顺序图、活动图、协作图适用范围进行研究， 分析它们可作为哪些测试层次的测试模型，得啦如下结论：( 1 ) u m l 顺序图可 以作为系统测试和集成测试的测试模型；( 2 ) u m l 活动图模型具有描述系统工 作流程和并行活动的能力，这使得u m l 活动图摸型可作为系统测试的测试模 型。u m l 活动图模型可对系统从系统级、子系统级到类级的不同层次进行建模， 因此u m l 活动图模型也可以指导不同层次的测试，包括系统级的功能测试、 集成测试、以及对象类的单元测试；( 3 ) u m l 协作图可以作为集成测试的测试 模型，在研究传统的集成测试和基础上，针对异构软件系统特点，本文提出了 第1 页 中文摘要 基于u m l 协作图的分解的集成测试方法和基于u m l 协作图的线程集成测试方 法。 本文对u m l 动态模型中的顺序图、协作图和活动图的语法和语义分别进行 形式化定义和描述。通过扩展了传统测试中的覆盖准则，提出了一个基于u m l 动态模型的覆盖准则( 结点覆盏准则、转移边覆盖准则、环路覆盖准则、判断 覆盖准则) ，从而利用这些覆盖准则对u m l 动态模型进行深度优先遍历寻找测 试场景，在寻找测试场景的过程中，按循环至多发生一次，条件分支和并发完 全组合的条件得到基础测试场景。在此基础上，本文形式化定义了u m l j 顿序图、 u m l 协作图和u m l 活动图的测试场景，并分别得到u m l 顺序图、u m l 协作图 和l r m l 活动图的测试场景提取算法。 本文利用m o d e l m a k e r 建模工具的扩展接口实现了一个从u m l 动态模型中 自动提取测试场景的测试工具基于u m l 动态模型图豹测试场景提取工具， 并以自动饮料销售机的动态模型为例进行了测试实验，通过上面的测试工具得 到它的一系列的测试场景，并能把这些铡试场景及相关的限制信息保存到文本 中。 + 从u m l 动态模型中自动提取出的测试场景描述了系统的执行过程的场景， 它可作为测试上下文，并且根据规约文档中的约束和输入条件，用类别一划分 方法生成测试用例。同时该测试场景描述了程序执行轨迹，可根据这些测试场 景信息对源程序进行动态插装，通过程序的运行检查实现与设计规约是否一致。 关键词：u m l ；模型；软件测试；测试场景；测试自动化 第2 页 第一章引言 第一章引言 1 1 课题研究的背景 鉴于软件质量问题的追切性，许多计算机科学家在展望2 1 世纪计算机科学发 展方向和策略时，把提高软件质量放在优先于提高软件功能和性能的地位。如何 提高软件质量是软件工程致力解决的关键问题之一。软件测试和验证是保证软件 正确性和提高软件可靠性的最基本和最重要的手段。 随着i t 技术的发展和普及，当今的软件已经不再局限于基于单机的桌面系 统。以构件系统、分布式软件、嵌入式软件等为代表的异构软件系统正在成为当 前软件发展的一个主要趋势。由于这些异构软件在硬件平台、软件平台上的多模 式特点导致这类软件在开发和测试中存在着大量特殊性，而传统的软件设计和测 试方法已明显不适应异构软件的需要。研究适合于异构软件特点的测试技术已成 为当前亟待解决的重要问题。 软件测试有不同的方法。基本可以划分为结构性测试和功能性测试两大范畴 【1 1 】。结构性测试是另一种用于标识测试用例的基本方法，也叫做白盒测试。结 构性测试根据程序代码的特征( 如语句、分支、路径) 产生测试用例，并以相应 程序代码特征是否得到充分测试作为测试终止的判定标准，即测试充分性准则。 如果测试充分性准则确定的程序特征在测试过程中都得到完全的执行，则认为对 代码的测试是充分的。白盒测试方法的主要问题在于：( 1 ) 它仅仅关注程序本身 的结构，很难保证对软件系统问题域的覆盖充分性。( 2 ) 由于软件系统实际执行 路径的数目通常是天文数字，因此，结构测试一般仅限于单元测试。功能性测试 的基本观点是，任何程序都可看作是将输入定义域取值映射到输出值域的函数。 这种观点常常在工程中使用将系统看作是黑盒。即黑盒测试，其中黑盒的内容( 即 实现) 是不知道的。功能性测试标识测试用例，所使用的唯一信息是软件的规格 说明。它根据功能规约和设计规约产生测试用例，针对相应的功能属性和设计属 性进行测试，并以相关的属性是否得到了充分测试作为测试充分性准则，如果测 试充分性准则确定的相关属性在测试过程中都得到完全的执行，则认为测试是充 分的。功能性测试用例具有两个明显的优点：( 1 ) 功能测试与软件如何实现无关， 所以如果实现发生变化，测试用例仍然有用；( 2 ) 测试用例开发可以与实现并行 进行，因此可压缩总的项目开发时间。与结构测试相比，黑盒子测试方法则从系 统或模块的外部要求和特性出发，从各种不同的角度对其进行全方位的测试，包 第5 页 第一章引言 括基本功能、非法输入、边界和极端情况、时间和空间性能、兼容性、用户界面 友好性等。因而。功能测试的显著特点是：( 1 ) 与结构澳i 试相比，考虑的因素更 多、更全面，因而是保证软件测试质量必不可少的技术手段。( 2 ) 直接针对系统 的各项功能，避免了单纯追求程序结构上的覆盖率，特别是面向对象软件，加强 测试的针对性可以减少大量与应用本身无关的冗余测试( 3 ) 适用于从单一模块 直到完整系统的任意级别的测试。在缺点方面，功能性测试用例也常常会带来两 个问题：测试用饲之间可能存在严重的冗余，此外可能会有未涮试的软件漏洞 然而，目前工业界在软件开发过程中采用的测试技术是非系统化的。航空航 天、武器装备、医疗设备等领域的软件具有实时性强、可靠性要求高的特点，软 件失效将导致人员和财产的重大损失，典型例子1 9 9 9 年9 月火星气象轨道人 造卫星的使命，在经过4 l 周4 1 6 亿英里的成功之后，终于失败了。这颗卫星在 就要开始进入火星轨道时消失了。卫星的缺陷本来可以通过集成铡试查出，洛克 希德马丁太空科学家使用的是英制( 磅) 加速度数据，而喷气推进实验室采用 公制( 牛顿) 加速度数据进行计算【1 0 】。 近年来对象管理组织( o b j e c tm a n a g e m e n tg r o u p ，0 m 0 ) 陆续提出了统一的 建模语言( u n i f i e dm o d e l i n gl a n g u a g e ，u m l ) 、模型驱动的体系缩构( m o d e l d r i v e n a r c h i t e c t u r e ，m d a ) ，使得模型驱动的软件工程( m o d e l d r i v e n e n g i n e e r i n g ， m d e ) 成为软件工程发展的一个新的方向，模型驱动的软件工程( m o d e ld r i v e n e n g i n e e r i n g ，m d e ) 是软件工程发展的最新趋势。u m l 作为建模语言事实上的 标准，近年来被学术界和工业界广泛地用于软件系统建模。在m d e 中，建模是 具有决定意义的活动之一。建模不但是提供可视化文栏，也是为了更好的理解、 构造和验证系统，并可以提供简化和复用的机会。m d a 通过建模和模型转换获 得软件开发过程中各个层次的模型，用u m l 表示的过分析模型、设计模型、实 现模型，。从澳4 试角度看，这些模型是获取系统结构和行为信息的来源，因而是 测试生成的基础，测试用例可以从模型中自动生成，这就是模型驱动软件测试。 模型驱动的开发过程中，系统以自顶向下方式设计，高层结构被不断精化，迭代 式增量开发，测试能在开发的早期进行，这样可以减少系统集成的风险【1 】。 1 2 国内外研究现状 j e f f o 觚t t 【2 】等将原先的基于规约的测试用例生成准则适用于从u m l s t a t e c h a r t s 生成测试用例，将u m l s t a t e c h a r t 转换成形式化的s r c 规约，从后者 第6 页 生成测试数据。 l il i u y i n g 3 等提出u m ls t a t e c h a r t 生成测试用例的方法是将u m l 状态机图 形式化，将u m ls t a t o a h a r t 的表示的层次和并发结构分解处理，将复合状态表示 为抽象状态。将问题转换到传统的状态机上加以解决。分别构造主状态机图和复 合状态所对应的测试用例集，然后依据一定的合成规则和w p 一方法生成整个状 态机图的测试用例集。 b i n d e r 4 提出将状态图转换成扩展的有限状态机和流图。将扩展的有限状态 机和流图用作测试模型分别使用控制流和数据流测试技术生成测试用例。 【6 】提出一个新的基于u m l 的测试模型，对基于u m l 的面向对象软件开发 过程中的生成集成测试的测试用例，使得测试过程自动化，并且与开发过程集成。 该方法首先分析软件系统的顺序图和协作图，提取组件间的事件流，根据组件之 间的转移将顺序图和协调图划分为一组原子功能( a s f ) 单元，以每个a s f 为一个 节点、消息流为边构造测试模型，使用面向对象的集成测试方法在测试模型上生 成澳0 试用例。 y g k i m ，h s h o n g 1 3 等人基于u m l 状态图中的数据流和控制流提出一 组覆盖准则，通过将状态图转换咸扩展的有限状态机( e f s m s ) 识别控制流，状 态的层次和结构被展平，清除了广播通信，再将e f s m s 转换成流图。 2 4 】研究了作为系统规约的状态图，提出弓l 入概率方法的统计功能测试方法， 使用转移覆盖度准则，从u m l 状态图中生成统计测试用例。 【2 s 提出一种基于u m l 状态机图规约的面向对象软件测试方法，定义了一 个改进的基于规约的测试准则，以及相应从状态机规约生成测试驱动、测试用例、 预期输出的方法。该方法能够自动为每个测试用例构造测试驱动，测试驱动不仅 能够保证测试用例满足覆盖准则，还能检查系统的行为是否与规约一致。 【2 6 】基于场景的测试主要是使用u m l 来表示测试活动，主要是用顺序图建 立测试用例的规约，建立反应系统的基于场景的规约用于测试。 多年来的软件测试研究和实践或者使用黑盒方法基于需求规约生成测试，或 者使用白盒方法基于代码实现生成测试用例，基于设计生成测试的方法研究较 少，而设计模型是需求规约和代码实现的中间产品，保持了分析模型里本质的信 息，也是最终代码实现的依据。基于u m l 模型构造半形式化的u m l 测试模型 的研究成果较少，从u m l 分析设计模型中提取必要的信息，并用u m l 这一半 形式他的建模语言建立测试模型的研究更少。 第7 页 第一章；f 言 但这类方法目前在工业界还没有广泛放接受，主要是有些限制使得对大型系 统的建模无论在时间上、工作量还是精确性上都不可行，但u m l 的出现使得基 于状态机的测试往实用化方向靠近。 1 3 课题研究意义 澍试可以看成是一个搜索问题。我们要在数百万计的输入及其状态组合中， 寻找那些极少数的能发现错误的状态及组合。在这种规模下，蛮干是无能为力的。 相反。我们的查找必须是系统的。集中的和自动的如果我们要确保每一个目标 组合被铡试。那么我们的测试必须是系统的。如果不是这样，即使是最细心的测 试者也会被测试的规模和复杂性所击败。如果我们要利用现有错误可能在哪的信 息，测试必须是集中的。没有错误的地方要比有错误的地方多得多如果我们要 产生和运行大量一致的和可重复的测试，测试必须是自动的【1 2 】。 基于模型的软件测试满足上述三点。模型支持输入及其状态组合的系统枚 举。一个有用的测试模型把注意力集中在那些可眈出错的地方。模型可潮试性标 准是仅用模型中给出的信息，设计和实现一定的算法来产生就绪运行的测试用例 的难易程度。可测试的模型应当既支持手工生成溉试用例又支持自动生成测试用 例。一个可测试的模型需要，满足以下要求【7 】； ( 1 ) 它应该完整而准确地反映被测系统，并描述了要测试的所有功能特性。 ( 2 ) 它是对细节的抽象，这些细节会使得测试成本过分高昂。 ( 3 ) 它保留被测系统中有助于发现错误和验证系统一致性的关键细节。 ( 4 ) 对状态模型而言，它描述了所有的事件、动作和状态，并对各状态进行了 明确定义。 u m l 为使用者提供了丰富的图形表示方式，使得使用者可以从不同的抽象角 度对软件系统的特征进行描述【1 5 】【1 6 j 。u m l 是一种图形化的设计语言，它使用 不同类型的图从不同的角度和抽象层次上描述系统模型。在使用u m l 进行软件 设计建模时，设计者必须根据所需要描述的对象和系统动作选择适当的u m l 露 以达到设计效果。通用性角度，u m l 作为标准建模语言，具有广泛的适用性， 目前已被软件开发界广泛采用，支持从软件需求分析到设计实现部署的各阶段。 并有大量商业工具支持。形式化角度，u m l 模型具有严格的定义，提供了获得 对象结构和行为的表示方法。这种形式化特性使得测试信息的提取和自动化变得 容易a 强大的描述能力角度，u m l 模型集众家之长，具有强大的描述能力。u m l 第8 页 第一章引言 包括一系列视图和模型，他们从不同的层次和角度描述了软件系统的结构、行为 以及软件的使用强大的管理能力角度，u m l 模型通过提供不同层次的视图和 包机制等，具备了强大的管理能力，解决了模型维护和管理的问题。同时通过分 层等方法在一定程度上解决了状态空间爆炸的问题。可重用性角度，l r m l 模型 支持在软件开发的各阶段、从不同的抽象层次对系统各方面的相关信息进行建 模。这些模型不仅可以用于软件开发阶段，还可以用于指导测试，因此避免了专 门为测试构造模型，实现了软件分析和设计阶段制品的重用，同时也将测试活动 与开发过程集成起来。可迭代性方面可以尽早开始测试活动( 包括测试计划的 制定、测试大纲与测试用例的设计等) 并随着设计活动的细化不断纲化生成的 测试制品。这样，软件开发与测试开发可以并行进行，并在整个测试过程中进行 持续测试活动众所周知，越早开始测试越好。从澍试角度看，这些模型是获取 系统结构和行为信息，都是系统本质的信息，从而避免了再从系统实现中提取信 息的更大的工作量，因而是测试生成的理想基础。基于以上原因，我们认为u m l 不仅是软件开发的重要工具。同时也是指导蔫试的重要模型。 1 4 本文研究贡献 多年来的软件测试研究和实践或者使用黑盒方法基于需求规约生成测试，或 者使用自盒方法基于代码实现生成测试用倒，基于分析、设计模型生成测试的方 法研究较少，而分析、设计模型是需求规约和代码实现的中间产品，保持了分析 模型里本质的信息，也是最终代码实现的依据。 u m l 模型是软件开发过程中的一个重要的信息资源，这些信息在系统由规 约到实现时必须保持的，要测试最终的系统实现，必须要从系统的实现信息中获 取相应的测试需求和测试用例信息，这些信息我们同样也可以在系统的分析、设 计模型中得到。用这些模型驱动测试过程是很自然的想法，使得测试工作可以尽 早开始，及时发现和排除软件开发过程中引入的缺陷。如何将这些模型应用于测 试过程，是摆在测试研究人员面前、迫切需要解决的问题之一。但目前还没有标 准的或者是普遍接受的方法，而且测试过程中能够得到的自动化程度依赖于规约 或设计的精确性。 u m l 作为建模语言作为一个事实上的标准，被学术界和工业界广泛地用于 系统地分析、设计规约地描述，从而很自然地使用u m l 模型成为测试生成地信 息来源，但目前基于u m l 模型构造半形式化的u m l 测试模型的研究成果较少。 第9 页 第一章引言 这种方法是从u m l 分析设计模型中提取必要的信息，并用u m l 这一半形式化 的建模语言建立测试模型。 本文对u m l 动态模型中的顺序图、活动图、协作图适用范围进行研究，分 析它们可作为哪些测试层次的测试模型，得出如下结论：( 1 ) u m l 顺序图可以 作为系统测试和集成测试的测试模型；( 2 ) u m l 活动图模型具有描述系统工作 流程和并行活动的能力，这使得u m l 活动图模型可作为系统测试的测试模型。 u m l 活动图模型可对系统从系统级、子系统级到类缀的不同层次进行建模。因 此u m l 活动图模型也可以指导不同层次的测试。包括系统级的功能测试、集成 测试、以及对象类的单元测试；( 3 ) u m l 协作图可以作为集成涌试的测试模型， 在研究传统的集成测试和基础上，针对异构软件系统特点，本文提出了基于u m l 协作图的分解的集成测试方法和基于u m l 协作圈的线程集成测试方法。 本文对u m l 动态模型中的顺序图、协作图和活动图的语法和语义分别进行形 式化定义和描述。通过扩展了传统测试中的覆盖准则，提出了一个基于u m l 动 态模型的覆盖准则( 结点覆盖准则、转移边覆盖准则、环路覆盖准则、判断覆 盖准则) ，从而利用这些覆盖准则对i n 咀励态模型进行深度优先遍历寻找铡试 场景，在寻找测试场景的过程中，按循环至多发生一次，条件分支和并发完全组 合的条件得到基础测试场景。在此基础上，本文形式化定义了u l 咀顺序图、u m l 协作图和u m l 活动图的测试场景，并分别得到u m l 颓序图、u m l 协作图和u m l 活动图的测试场景提取算法。 本文利用m o d d m a k e r 建模工具的扩展接e l 实现了一个从u m l 动态模型中 自动提取测试场景的测试工具基于u m l 动态模型图的测试场景提取工具， 并以饮料销售机买饮料的动态模型为例进行了甥4 试实验，通过上面的测试工具得 到它的一系列的测试场景，并能把这些测试场景及相关的限制信息保存到文本 中。 从u m l 动态模型中自动提取出的测试场景描述了系统的执行过程的场景， 它可作为测试上下文，并且根据规约文档中的约束和输入条件，用类别一划分方 法生成测试用例。同时该测试场景描述了程序执行轨迹，可根据这些测试场景信 息对源程序进行动态插装，通过程序的运行检查实现与设计规约是否一致。 第1 0 页 第二章u m l 概述 2 1u m l 的发展概况 第二章u m l 概述 面向对象的分析与设计方法的发展在8 0 年代末至9 0 年代中出现了一个高 潮，u m l 是这个高潮的产物。它不仅统一了b o o c k , r u m b a u g h 和j a e o b s o n 的表 示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。 公认的面向对象建模语言出现于7 0 年代中期。从1 9 8 9 年到1 9 9 4 年，其数量从 不到十种增加到了五十多种。在众多的建模语言中。语言的创造者努力推崇自己 的产品，并在实践中不断完善。但是，面向对象方法的用户并不了解不同建模语 言的优缺点及相互之问的差异，因而很难根据应用特点选择合适的建模语言，于 是爆发了一场方法大战。9 0 年代中，一批新方法出现了，其中最引人注目的是 b o o c h ，o o s e 和o m t 等 9 】。 面对众多的建模语言，用户由于没有能力区别不同语言之间的差别。因此很 难找到一种比较适合其应用特点的语言；其次，众多的建模语言实际上各有千秋； 第三，虽然不同的建模语言大多类同，但仍存在某些细微的差别，极大地妨碍了 用户之间的交流。因此在客观上，极有必要在精心比较不同的建模语言优缺点及 总结面向对象技术应用实践的基础上，组织联合设计小组，根据应用需求，取其 精华，去其糟粕，求同存异，统一建模语言。r a t i o n a l 软件公司b o o c h 。r u m b a u g h 和j a e o b s o n 三位最优秀的面向对象方法学的创始入共同合作，统一建模语言， 打破了面向对象软件开发领域内原有的平衡，最终形成u m l 并被提交到o m g 。 1 9 9 7 年1 1 月，u m l 被o m g 全体成员一致通过，并被采纳为标准。从而，u m l 正式成为面向对象建模的统一的标准语言。u m l 在不断完善，当前最新版本2 0 值得注意： 首先，u m l 融合了b o o c h ，o m t 和o o s e 方法中的基本概念，而且这些基 本概念与其它面向对象技术中的基本概念大多相同，因而，u m l 必然成为乐于 采用的一种简单一致的建模语言。 其次，u m l 不仅仅是上述方法的简单汇合，而是在这些方法的基础上广泛 征求意见，集众家之长，几经修改而完成的，u m l 扩展了现有方法的应用范围。 第三，u m l 是标准的建模语言，而不是标准的开发过程。尽管u m l 的应用 必然以系统的开发过程为背景，但由于不同的组织和不同的应用领域，需要采取 不同的开发过程。 第1 1 页 第二章u m l 概述 2 2u m l 主要内容 u m l 是一种对软件密集型系统的制品进行下述工作的语言，这些工作包括： 可视化、详述、构造、文档化。 u m l 是一种语言。它提供了用于交流的词汇表中组合词汇的规则。而一种 建模语吉的词汇表和规则注重于对系统进行概念上和物理上的描述。像u m l 这 样的建模语言正是用于软件蓝图的标准语言。建模是为了产生对系统的理解。只 用一个模型是不够的，相反，为了理解系统中的各种事物，经常需要多个相互联 系的模型。对于软件密集型系统，就需要这样一种语言，它贯穿于软件开发生命 期，并能表达系统体系结构的各种不同视m 1 7 1 。 像u m l 这样的语言的词汇表和规则可以告述你如何创建和理解结构良好的 模型，但它没有告述你应该在什么时候刨建什么样的模型，因为这是软件开发过 程的工作。一个定义，明确的过程会给出如下的指导t 决定生产什么制品；由什 么样的活动和人员来创建和管理这些制品，怎样采用这些制品从整体上去度量和 控制项目 u m l 作为种建模语言，u m l 的定义包括u m l 语义和u m l 表示法两个 部分。 ( 1 ) u m l 语义描述基于u m l 的耪确元模型定义。元模型为u m l 的所有元素 在语法和语义上提供了简单、一致、通用的定义性说明，使开发者能在语义上取 得一致，消除了因人而异的最佳表达方法所造成的影响。此外u m l 还支持对元 模型的扩展定义。 ( 2 ) u m l 表示法定义u m l 符号的表示法，为开发者或开发工具使用这些图 形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用 级的模型，在语义上它是u m l 元模型的实例。标准建模语言u m l 的重要内容 可以由下列五类视图( 共9 种图形) 来定义f 1 8 】： 第一类是用例视图( u s ec a s e ) ，从外部用户的角度捕获系统、子系统或类的 行为a 它将系统功能划分为对活动者( 系统的理想用户) 具有意义的事务。这些功 能片被称为用例。用例通过系统与一个或多个活动者之间的一系列消息描述了与 活动者的交互。活动者包括人员、其他的计算机系统和进程。用例图是由执行者 ( a c t o r s ，一种特殊的类) 、用例( u s ec a s e s ) 以及它们之间的关系组成的。用例 图是从静态用例的角度来描述系统，对系统行为的组织和建模是很重要的。用例 模型表现一个系统或一个类对于系统外部的交互者的功能。u m l 定义了如下几 第1 2 页 第二章u m l 概述 种构成用饼图的元素；用例、执行者和用例关系。用例是一个系统或一个类提供 的紧凑的功能单元，它是由系统与一个或多个外部执行者之间交换的消息序列以 及系统执行的活动共同体现的。执行者是直接与系统交互的外部对象所扮演的角 色。用例关系包括通信关系( c o m m u n i c a t e ) 、扩展关系( , m m m d ) 和使用关系( u s e ) 。 第二类是静态视图( s t 目i t i cd i a g r a m ) ，包括类图、对象图和包图。其中类图描 述系统中类的静态结构。不仅定义系统中的类，表示类之闯的联系如关联、依赖、 聚合等，也包括类的内部结构( 类的属性和操作) 类图描述的是一种静态关系， 在系统的整个生命周期都是有效的。对象图是类图的实例。几乎使用与类图完全 相同的标识。他们的不同点在于对象图显示类的多个对象实例，而不是实际的类。 一个对象图是类图的一个实例。由于对象存在生命周期。因此对象图只能在系统 某一时间段存在对象图是类图的一种变形。除了在对象名下面要加下划线以外， 对象图中所使用的符号与类图基本相同。它是类图的一种实倒化，一张对象图表 示的是与其对应的类图的一个具体实例，即系统在某一对期或者莱一特定时刻可 能存在的具体对象实例以及它们相互之间的具体关系。对象圈并不象类图那样具 有重要的地位，但是利用它可以帮助我们通过具体的实饲分析。更具体直观地了 解复杂系统类图的丰富内涵。包由包或类组成，表示包与包之间的关系。包图用 于描述系统的分层结构。 第三类是行为视图( b e h a v i o rd i a g r a m ) ，描述系统的动态模型和组成对象闻的 交互关系。其中，状态圈描述类的对象所有可能的状态以及事件发生时状态的转 移条件。通常，状态图是对类图的补充。在实用上并不需要为所有的类画状态图， 仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。而活 动图描述满足用例要求所要进行的活动以及活动问的约柬关系。有利于识别并行 活动。活动图是一种特殊的状态图，表述的是系统中的活动流。它也是系统的动 态视图，在系统的功能建模上起很大的作用，它强调的是对象问的控制流。状态 的变化是由行为或子活动的完成来触发的。构成活动图的元素有：活动状态 ( a c t i o ns t a t e ) 、判断( d e c i s i o n ) 、泳道( s w i m l a n e ，在图中画出来就象游泳池 中的泳道，把各个活动组放在不同的泳道中以便更加清晰) 、活动对象流关系 ( a c t i o n - o b j e c tf l o wr e l a t i o n s h i p ，表示一个活动与有关对象之间的消息和输a 输出关系) 、控制图符( c o n t r o li c o n ，表示信号的发送和接收) 等。 第四类是交互视i 虱t e r a c t i v ed i a g r a m ) ，描述对象间的交互关系。其中顺序 图显示对象之间的动态协作关系，它强调对象之间消息发送的顺序，同时显示对 第1 3 页 第二章u 。概速 象之间的交互；协作图描述对象间的协作关系。协作图跟顺序图相似，显示对 象间的动态协作关系。除显示信息交换外，协作图还显示对象以及它们之间的关 系。协作图强调的是对象的结构组织和它们之间消息的发送和接收。表示的是对 象角色之间的关系，而不突出消息的时间顺序，它描绘了在特定上下文中一组相 关对象之间的协作，以及这组对象为产生所要求的操作或结果而进行协作时交换 的一组消息。如果强调时间和顺序，则使用顺序图；如果强调对象问关系，则选 择协作图。这两种图合称为交互图。 第五类是实现视图( i m p l e m e n t a t i o nd i a g r a m ) 。其中组件圈描述述代码部件的 物理结构及各部件之超逝依赖关系。一个部件可能是一个资源代码都件、一个二 进制部件或一个可执行部件它包含逻辑类或实现类的有关信息部件图有助于 分析和理解部件之间的相互影响程度配置图定义系统中软硬件的物理体系结 构。它可以显示实际的计算机和设备 咄鬻 l 7 r e c e i v e s o d a ( s e l e c t i c | ! 圈3 1 对用例“b u ys o d a ( 买饮料) ”场景建模的顺序图 一个顺序图表示一个协作。例如，一个用例的实现要求几个脚本图。我们的 目的是测试用例生成和执行，也就是要从顺序图上找到其表示的预期行为，然后 据此获取要让最终实现的系统再现该行为需要的输入必须满足什么条件，用这些 测试月 例执行系统时会得到实际的行为，通过验证动态模型表示的系统预期行为 与软件在运行时的行为的一致性就可以确定程序中是否存在与规约不一致的错 误f 2 l 】。 但是，顺序图还提出了一些附加的问题： l 、表示复杂的控制是困难的。选择和重复的符号是笨拙的，并且支持可能 冲突的解释a 因为很难决定什么时候一个脚本图中所有的路径被覆盖，这就对测 试设计提出了更多的问题。 2 、条件消息和被延迟消息问的区别不明显( 两条线都向下倾斜：条件消息有 个谓词通过说明两个消息有相同的时间来注解个被延迟的条件消息。 我们通过交互纵览图解决顺序图表示复杂控制困难，条件消息和被延迟消息 问的区别不明显的问题。 u m l 2 0 提供了种交互纵览图，它是来自活动图和交互图的建模技术的种 组合。交互纵览图就是一个活动图，其中每个活动是一个独立的交互图【2 2 】。这 样结合活动图的优点，我们就可以通过活动图清楚的表示顺序图中的事件顺序和 复杂控制困难，同时也有利于我们自动提取测试用例。 第1 7 页 第三章基于u m l 动态图的测试模型 3 。2 基于u m l 活动图的测试模型 要研究基于活动图模型的测试方法，我们需要首先了解活动图模型的适用范 围。活动图一般是人的工作流以及这些流和软件系统的相互作用的模型 2 3 1 。 u m l 活动图在系统分析和设计中特别有用，包括从初始阶段、细化阶段到构造 的整个过程。活动图主要用于软件系统动态建模，在下列情况下可以使用u m l 活动图模型： ( 1 ) 分析表示用例。用例图模型从使用者的角度来描述系统功能。但是，仅仅 通过用例图并不能描述用例中的事件序列，特别是当用例中存在多个可能的执行 场景时( 包括基本场景、异常场景等) 。活动图可以直接依附于一个用例。用例图 只反映了外部执行者与对应的各用例之间的交互关系，却没有描述出各用例之间 的联系。然而，对上述用户需求来说，用例之间存在着密切的联系，这些联系是 非常重要的，如果不将他们描述出来，就很难说得到的需求描述和分析模型全面 反映了用户需求。即用例之问的业务流程是一个复杂的动态变化过程，它描述了 用例之间的流转换，其中包含多种不同的变迁方式这时，就可以使用活动图来清 晰地记录特定用例中的活动执行顺序约束和依赖。 ( 2 ) 理解和建模业务过程和工作流，处理多线程应用。由于活动图模型具有描 述系统工作流程和并发行为的能力，因此。适合于建模业务过程和工作流。这是 理解、构造、测试和维护系统的重要模型。 ( 3 ) 活动图可以表示决策表，用于描述复杂的选择算法、商业规则。 如下图3 2 ：对用例“b u ys o d a ( 买饮料) ”场景建模的活动图。 第1 8 页 堡三皇薹王坐些垫查里鲤型堕墼型 图3 2 对用例。b u ys o d a ( 买饮料) ”场景建模的顺序图 总之。活动图模型所具有的描述系统工作流程和并行活动的能力。使得活动 图模型成为系统测试的重要依据。此外，u m l 活动图模型可以针对系统的不同 层次建模，从系统级、子系统级到类级，因此活动图模型也可以指导不同层次的 测试，包括系统级的功能测试、集成测试以及对象类的单元测试。 在可测试性方面，u m l 活动图模型存在下列问题：u m l 活动图模型中存在着 复杂的非结构化和并发特征。这将加大测试的难度。 3 3 基于u m l 协作图的测试模型 异构软件系统是软件产业发展的大方向，国内企业级大型异构应用系统、政 府异构息系统正全面建设。基于架构的异构软件系统的开发方法研究是大势所 趋，将对软件产业的发展产生重大影响。基于架构的异构软件系统开发可以达到 最大限度的组件重用、更好的系统可移植性与可维护性，以及强大的系统扩展能 力 2 7 】。 随着市场对于异构软件系统的需求日益增加，相应的设计方法和测试技术将 第1 9 页 第三章基于u m l 动态圈的潮试模型 有极大豹应用前景和市场需求。基于复杂、分布式系统的企业级应用系统和政府 信息系统开始广泛应用，这些系统往往采用多平台、多个开发商进行系统集成。 其中的软件部分规模庞大，大量采用多厂商的异构子系统和软件构件来组成一个 完整系统。美g a r n e r g r o u p 通过研究发现，美国异构子系统市场与软件构件市 场从1 9 9 7 年的1 4 亿美元增加到2 0 0 3 年的1 2 0 亿美元；到2 0 0 4 年。7 0 * 4 的新软件将 由异构子系统或软件构件构成。 软件应用实际情况来看，如何验证并确认这些异构软件系统的有效性和可靠 性成为一个非常重要的问题。异构软件测试与普通软件测试的主要区别在于测试 者除了使用传统方法测试异构软件的各个组件的内部功能正确性以外，还需要把 更多的糟力投入到软件异构部件间相互关系的检查和晃构软件的综合性能等更 为高级的领域。当前在这个领域的测试技术发展缓慢，铡试者更多的还是采用传 统的软件测试方法，没有取得突破性的进展因此，对异构软件系统集成测试技 术和方法的研究就变得非常必要【2 8 】。 异构软件系统集成浏试是异构软件架构和开发使用过程紧密联系在一起 的。体系结构将在一个系统组织成为可管理的构件和子系统。它服务予很多日标， 因为集成测试方案一般基于构件之间实现的依从性，所以需要分析异构软件系统 的体系结构。如果这种体系结构不明确。那么必须等特某些构件( 最坏情况下是 所有构件) 完成以后可以才可以进行集成测试设计。集成测试设计的过程常常会 发现需求和体系结构中的错误、遗漏以及二义性这就是尽早开始体系设计和 将可测试性作为设计目标的原因。迭代的、增量的面向对象开发增加了集成测试 的作用。增量式集成是最有效的技术，一次增加少数几个构件然后测试它们的互 操作性。而同时集成一个系统的大多数构件通常有很多问题：1 ) 因为错误可以 在任何接口中，所以调试会很困难；2 ) 最后的修改往往是必需的，从而导致底质 量的未经过充分测试的修改；3 ) 测试通常不是系统的，所以可能会漏掉一些接 口错误。相反，增量测试有许多优点。在未监测的接口被测试以前，许多接1 3 已 被系统的测试并证明是稳定的。如果没有被触发，有错误的接口代码会被遇见。 明显的错误最有可能是新假如的构件，因此调试会更有效。虽然概念上比较简单， 但是增量开发需要严格的组织，必须通过仔细分析构件的依从性以确定构件的顺 序，随后的测试也必须依照这些依从性来计划和管理。测试没有良好设计的集成 测试将会是高消耗并且低效率的，而适合的集中的集成测试会带来很高的效率 p 0 j 。 第2 0 页 传统集成测试方法通过观察构件之间的关系，得到依从性关系，并对依从性 关系拓扑排序，得到依从性树。拓扑排序是对一个有向图的捧序，使得每个结点 的前驱在该结点之前被歹 f 出，也就是所有结点都只有在它的前驱全部列举完以后 才出现。 定义3 - 3 1 依从性关系可以表示为一个三元组：c = - ( v ( g ) ，e ( g ) ，中o ) 。其 中： v ( g ) 是一个非空的结点集合。 e ( g ) 是边，表示从边集合e 与结点的无序偶( 有序偶) 集合上的函数， m 。表示构件与构件之同的相依关系。 3 3 1 基予u m l 协作啊的分解曲i i 戚霹瞳方镳 根据依从性关系，可以按照以下几种方式组织；自底向上集成测试是从具有 最少的依从性的构件开始。按照使用依从性的次序将构件加入到被测软件，以证 明稳定性；自顶向下集成涮试从顶层控制对象开始，以控制层次的相依性顺序向 被测软件增加构件以论证稳定性；三明治集成测试是自底向上集成和自顶向下集 成的组合；协作集成测试检测个特定的协作。检测协作的参与者之闺的接口并 根据协作组织集成。一个系统般支持很多协作。协作中包括的构件按照一个处 理线程、一个事件一响应路径或关键性能目标中鹩隶属关系来选择。它们的顺序 可以是根据依从性或顺序激活约束或根据二者共同来选择。 从协作图中，可以找出存在协作关系的构件。为被铡系统开发一个依从性树， 通过在设计阶段的协作图划分。将协作映射到依从性树直到所有构件和接口被覆 盖，并保证系统中的所有构件和构件之间的消息已经被测试至少一次。 3 3 2 基予u m l 协作圈的线程囊成溺试方法 面向对象程序没有层次控制结构、相互调用的功能散布在程序的不同类中， 类通过消息相互作用申请和提供服务。类的行为与它的状态密切相关，状态不仅 仅是体现在类的数据成员的值，也许还包括在其他类的状态信息。由此可见，类 相互依赖及其紧密。此外，面向对象程序具有动态特性，程序的控制流往往无法 确定。因此，只能对整个编译后的程序傲基于黑盒的集成测试。面向对象的软件 的集成测试有两种不同的策略：1 ) 基于线程的测试：基于线程的测试就是把合作 对应一个输入或事件类集合组装起来。也就是用购应系统的一个输入和一个事件 第2 i 页 棼三章基于u m l 魂态匿的铡试模墼 的请求来组装类的集合。对每个线程都要分别进行组装和测试。2 ) 基于使用测 试：基于使用的测试是按分层来组装系统，可以先进行独立类的测试。在独立类 测试之后，下一个类的层次叫从属类。从属类用独立类进行测试。这种从属类层 的贩序测试直到整个系统被构造完成。 图3 。3 对用例“b u ys o d a ( 买饮料) ”场景建模的协作图。从协作图规约中， 可以找到这些线程，可以直接提取出这些线程测试路径。u m l 协作图就是用来 表示一组通过交互来实现某些行为的对象，可以用来按交互中的角色及其关系对 一个用例的特定的实现场景进行建模。它描述了特定行为的参与对象的静态结构 和动态交互。动态交互部分是一个消息集合，用协作实现过程中的消息流定义系 统行为方面的内容。协作图上存在条件消息说明考虑到许多不周的用锣| | 场景，涉 及到多个对象之间的交互，其中每一个场景都对应协作图上的一条执行路径，这 正是测试所要尝试的。 5 ：u p d a t e r e s e r v e ( c a s - 靠p r i c e )3 ：c h e c k a v a i l a b i l i t y ( s e l e c t i o n ) 5 ：r e c e i v e s o d a ( s e l e c t i o o ) 图3 4 对用例“b u ys o d a ( 买饮料) ”场景建模的协作图 补充说明 为了有针对性地解决从协作图、顺序图和活动图生成测试用例的问题，本文 假定： ( 1 ) 动态模型描述的行为场景与用例图描述的规约是一致的。模型本身的验 第2 2 页 第三章基于u m l 动态躅豹舞试摸壁 证是通过非形式化的复审和形式化的模型检验方法进行的，已超出本文的研究范 围；( 2 ) 系统中的对象都是自行开发的，不包括第三方组件对象，文中的对象可 以是不同粒度的对象( 类的实例、类簇、组件、子系统、系统) ，也就是说我们 在分析任意对象或类时，在必要的情况下都可以获取其规约和内部详细设计信 息。 第2 3 页 第四章u m l 动态模型的形式化描述 第四章u m l 动态模型的形式化描述 4 1u m l 顺序图形式化 定义4 - 1 1u m l 顺序图s d 可以表示为一个四元组： s d = ( d ，mm x ，m f ) 。其中： 0 是s d 中非空有穷的对象集合。 m = 珊- ，m 2 ，m 3 ，胁 是s d 上描述的有穷消息集合，每个消息定义为 m le g u a r d x m n a m e x p a r a m e n t e r l i s t x r e t u r n v a l u e xs e n d e r x r e c e i v e r x t y p e ，其中， g u a r d 为消息发送的卫式条件；m n a m e 为消息名：p a r a m e n t e r l i s t 和 r e t u r n v a l u e 分别为消息的参数和返回值；s e n d e r e0 是m 的发送者， r e c e i v e r e o 是盯的接收者；m 的类型t y p e s y n c a l l ，a s y n c a l l ，s e n d ，r e t u r n ) 。 s y n c a l l 代表方法的同步调用；a s y n c a l l 表示方法的异步调用：s e n d 表示信号 的发送；r e t u r n 表示方法同步调用后的返回 a , h 靠互m 分别为顺序图所表示的场景的所有可能的起始事件集合和终止 事件集合： 4 2u m l 活动图形式化 u m l 活动图( 以下简称活动图) 借用了流程图、状态转换图，p e t r i ) 嘲的思想， 表示了活动可能发生的顺序。活动图是一种特殊形式的状态机，用于计算流程和 工作流程建模。活动图中的状态表示计算过程中所处的各种状态，而不是普通对 象的状态。通常，活动图假设在整个计算处理的过程中没有外部事件引起的中断， 否则，普通的状态机更适合于描述这种情况 3 1 1 。 活动图中的活动状态分为a c t i o n 状态、o r 状态、a n d 状态