（计算机软件与理论专业论文）分布式组件软件测试用例生成方法研究.pdf

上海大学硕士学位论文 t h e p o s t g r a d u a t e l 。魄s i s o f s h a n g h a l u n i v e r s r r y 摘要 计算机网络技术和面向对象技术的发展为软件开发和应用带来了许多深刻 的变革。分布式组件逐步成为新一代软件应用的重要模式，随着当前各种相关 规范的逐步形成和完善，相应的开发环境和支持工具不断出现，分布式组件系 统必将迎来前所未有的应用前景。如何保证分布式组件系统的质量成为一项亟 待解决的任务摆在软件测试工程师的面前。 本文讨论了分布式组件系统的特点，分析了组件软件在集成测试时可能出 现的错误类型，在此基础之上，提出组件软件的测试模型。为了更加精确描述 组件间交互行为，我们结合u m l 协作图与状态图为组件软件测试建模。 测试充分性准则是整个软件测试的核心，它直接决定测试用例的生成。本 文给出基于u m l 协作图和状态图的测试准则，基于这些准则，介绍了如何从u m l 协作图和状态图中产生测试用例。对于u m l 协作图，本文采用直接从协作图中 产生测试用例的方法，分别对协作图的条件、并发、循环条件迸行讨论，最后 采用深度优先算法遍历所有测试场景，每个测试场景对应一个测试用例；对于 u m l 状态图，本文首先将其转换成测试流图，然后从测试流图中产生测试用例。 最后，实现了基于u m l 协作图状态图的测试用例生成方法的工具u m l t c g 系统。这个系统，从读入u m l 协作图状态图的规格说明x m l 文件，到测试用例 的产生及测试用例管理都实现了自动化。 关键词：组件软件，协作图，状态图，测试流图，测试用例自动生成 v 上海大学硕士学位论文 t h e p o s t g r a d u a t et h e s i so fs h a n g h a iu n i v e r s n y a b s t l t a c t t h ed e v e l o p m e n to fc o m p u t e rn e t w o r ka n do b j e c to r i e n t e db r i n g sl a r g ec h a n g e i ns o f t w a r ed e v e l o p m e n ta n da p p l i c a t i o n s d i s t r i b u t e dc o m p o n e n t sg r a d u a l l y b e c o m eo n eo ft h em o s ti m p o r t a n tm o d e l so fs o f t w a r ea p p l i c a t i o n s w i t hv a r i o u s r e l a t e ds t a n d a r d sf o r m i n ga n dp e r f e c t i n gg r a d u a l l y , r e l a t e ds o m ed e v e l o p i n gs t u d i o s a n dt o o l sh a v eb e i n gi m p l e m e n t e dc o n t i n u a l l y , d i s t r i b u t e dc o m p o n e n t - b a s e ds y s t e m s w i l lh a v ea nu n p r e c e d e n t e dp r o s p e c t h o w e v e r , h o wt oe n s u r et h eq u a l i t yo f s o f t w a r e b e c o m e sad e s i d e r a t e dt a s ki nt h ef r o n to fs o f t w a r ee n g i n e e r s t h i sp a p e rd i s c u s s e st h ec h a r a c t e ro fd i s t r i b u t e dc o m p o n e n t - b a s e da p p l i c a t i o n s ， a tt h es a m et i m e ，t od e s c r i b et h et e s tm o d e l ，w ea n a l y z ep o t e n t i a lf a u l t sw h i c h m i g h t b ee n c o u n t e r e dw h i l et e s t i n gt h e ma n dt h e nw ed e s c r i b eo u l t e s t i n gm o d e l t h ek e y t os u o o e s so far e l i a b l es o f t w a r es y s t e mi st oe n s u et h ea c c l l r a c yo fi n t e r a c t i o n s a m o n gt h ec o m p o n e n t s ，s ow em o d e lt h es y s t e mw i t hu m l c o l l a b o r a t i o nd i a g r a m a n du m ls t a t e c h a r td i a g r a m t h ec o r eo fs o f t w a r et e s t i n gi st e s ta d e q u a c yc r i t e r i ao nw h i c ht h eg e n e r a t i o no f t e s tc a s e sd e p e n d t h i sp a p e rp r e s e n t st h e s ea d e q u a c yc r i t e r i aw i t l lr e s p e c tt ou m l c o l l a b o r a t i o nd i a g r a ma n du m ls t a t e c h a r td i a g r a m f o ru m lc o l l a b o r a t i o nd i a g r a m , t h i sp a p e rp r o p o s e sa na p p r o a c ht o g e n e r a t i o no ft e s tc a s e sd i r e c t l yf r o mu m l c o l l a b o r a t i o nd i a g r a m v a r i o u sm e s s a g e sa r ed e a l tw i t ho n eb yo n e ，a n dad e p t hf i r s t a l g o r i t h mi sp e r f o r m e dt os e a r c ha l lt h es c e n a r i op a t h sw h i c hc o m p o s et e s tc 嬲e s f o r u m ls t a t e c h a r td i a g r a m ，f i r s t l yw et r a n s f o r mi ti n t ot e s t i n gf l o wg r a p h ( t f g ) ，t h e n t h et f gi su s e dt og e n e r a t et e s tc a s e sb yc o v e r i n ge a c hs t a t ea n de a c ht r a n s i t i o n f i n a l l y , w ei m p l e m e n tat o o lu m l t c gt h a ta u t o m a t et h eg e n e r a t i o no ft e s t c a s e sa c c o r d i n gt ou m lc o l l a b o r a t i o nd i a g r a ma n du m ls t a t e c h a r td i a g r a m k e y w o r d s ：c o m p o n e n ts o f t w a r e ，c o l l a b o r a t i o nd i a g r a m ，s t a t e c h a r td i a g r a m ， t e s t i n gf l o wg r a p h ，a u t o m a t i cg e n e r a t i o no f t e s tc a s e 上海大学硕士学位论文 t h ep o s t g r a d u a t et h e s i so fs h a n g h a iu n e r s i t y 原创性声明 本人声明：所呈交的论文是本人在导师指导下进行的研究工作。 除了文中特别加以标注和致谢的地方外，论文中不包含其他人已发 表或撰写过的研究成果。参与同一工作的其他同志对本研究所做的 任何贡献均已在论文中作了明确的说明并表示了谢意。 签名：1 主l 建圭日期：型2 ：兰： 本论文使用授权说明 本人完全了解上海大学有关保留、使用学位论文的规定，即： 学校有权保留论文及送交论文复印件，允许论文被查阅和借阅；学 校可以公布论文的全部或部分内容。 ( 保密的论文在解密后应遵守此规定) 签名：丘灶导师签名： 上海大学硕士学位论文 t h ep o s t g r a j ) u a d et h e s i so fs f l a n g i - i a ju n i v e r s l l y 第一章引言 1 1 论文选题及研究意义 计算机网络技术和面向对象技术的发展为软件开发和应用带来了许多深刻 的变革。分布式程序逐步成为新一代软件应用的重要模式，物理上分布的工作站 系统通过高速网络的连接，协同完成复杂的信息处理任务；面向对象技术所提出 的封装、继承、多态、复用等概念，使软件开发过程有了根本性的转变。组件技 术是对象技术的继承和发展，借助组件技术，软件工程师可以从更抽象的级别上 认识和表达系统，并且通过更有效地重用来加速软件系统的开发。 分布式组件系统集中体现了网络化和组件化这两个现代技术发展的重要方 向。随着当前各种相关规范的逐步形成和完善，相应的开发环境和支持工具不断 出现，分布式组件系统必将迎来前所未有的应用前景。分布式组件软件开发平台 如c o r b a 、d c o m 、j 2 e e 在业界已经得到了广泛的应用。如何保证分布式组件系统 的质量成为一项亟待解决的任务摆在软件测试工程师的面前。 软件质量一直是软件开发人员和用户共同关心的问题，而软件测试是保障软 件质量的重要手段，因而它必将面临前所未有的挑战。试想在一个遵循增量开发 或敏捷开发过程的软件公司中，软件版本在不断更新，相应的测试用例数目和运 行这些测试用例的时间也在不断增长，如何保证在这种很短的用于进行版本更新 的时间内进行充分的测试和回归测试已经成为软件开发人员和测试人员迫切需 要解决的问题。一个大的软件项目可能涉及多家公司，包括许多分布在世界各地 的开发测试组，需要一种有效的机制来协调和整合各组的任务、过程和工作结 果。也需要一种机制来合理地、按照项目的进展情况动态地充分利用各地的资源。 再者，仅仅在开发者的工作环境中测试软件是不够的，软件产品的最终用户可能 遍布世界各地，它们的操作系统以及软件配置环境也千差万剐。因此，迫切需要 建立一种新型的软件测试模型。 通常软件测试可以分成两大类；基于规格说明的测试和基于程序代码的测 试。传统的测试技术不太适合面向组件测试。原因有： 传统集中式测试和注重单独的模块结构测试难以保证软件分布在不同服 务器或组件上能相互协调工作； 分布式其根本特点就是其运行状态的不确定性，即在运行的某一时刻， 软件处于某一状态时，其下一步的动作及该动作所导致的状态不可预知。 因此测试分布式的组件不能仅考虑输入和输出对应，因为在实际执行环 上海大学硕士学位论文 珊p o s l l g r a d u a t e t h e s i s o fs h a n g i a i u n i v e r s i t y 境中事件不可能完全按照这些事件序列发生，如出现非法事件； 由于组件的版权限制，组件使用者几乎不可能获得组件源代码，因此， 基于软件代码的技术，如结构测试技术和故障测试技术在这里无法直接 使用； 对基于组件的系统，即使组件是带源代码的( 如某些开放源代码的组件) ， 由于这些组件有可能是在不同开发平台或使用不同程序语言开发的，结 构测试技术和故障测试技术也依然无法直接使用； 由于组件常常不是根据某个具体最终用户开发的，它提供的功能常常会 比组件使用者要求的多。在这种情况下使用传统的测试覆盖率来衡量集 成测试结果是没有意义的，因为有可能组件提供的某些功能在该系统中 根本不会被使用。 目前，软件测试在很大程度上还是一项经验性的工作，停留在一种启发式的 思维方式上面，测试的效果和效率主要依赖于测试工程师个人能力，产生这种现 象的主要原因之一就是由于目前软件测试的规范化和形式化程度很低。随机的测 试最大的缺点就是缺乏系统性，不能全面地发现系统缺陷，测试过程也不容易实 现自动化。形式化方法能够有效克服随机测试带来的缺点。在软件方法学中，形 式方法越来越受到人们的重视，工业界现在要求人们能应用基于如v 嗍、z 、 0 b j e c t - z 、c c s 和0 b j 等软件规格说明表示的形式方法来开发软件。最近几年， 软件规格说明技术的研究和发展很快，并在工业界被用来描述大型软件系统。 国际对象管理组织0 m g ( 0 b j e c tm a n a g e m e n tg r o u p ) 认可的标准建模语言 嘶l ( u n i f i e dm o d e l i n gl a n g u a g e ) “1 是近年来软件工程领域的重要成果。它推 动软件开发的标准化进程，拓宽了研制与开发软件系统的适用范围。u m l 是一种 描述能力强大且涵义直观的可视化建模语言，它提供多种视图从不同角度和应用 层次刻画系统特性以及复杂的运行环境。基于u 札的软件开发过程和建模环境已 经被工业界广泛接受。基于u 地软件测试成为了软件工程的一个重要研究方向， 软件测试的关键是测试用例的产生，基于上述考虑，本文侵用u m l 协作图和状态 图模型实现分布式组件系统的测试用例的自动产生。相信这项工作，无论是对于 目前分布式组件系统测试工程的实践，还是对软件测试理论上的探索都具有重要 的意义。 1 2 国内外研究现状 目前国内外在组件软件的测试技术领域已有一些研究。 1 组件软件流图 2 上海大学硕士学位论文 t h e p o s t 0 r a d u j j e t h e s i s o f s h a n o h a l u n 【v e r s l l y s a m i “等人首先把从软件需求和源代码中得到的信息( 如数据流和控制流) 进行可视化处理，生成流图，借助结构测试技术生成测试用例。但没有给出实例 研究，不知道实际效果。 l e o n a r d 等人采用类状态机描述类的行为，然后求出类内和类间的相关迁移， 并在此基础上构造数据流图，节点由状态、迁移和条件组成，边由相关迁移组成。 数据流图储存在相关数据库中，数据库查询用来获取定义一使用信息，最后查找 出定义使用对之间路径，自动产生类和组件间测试用例。 2 基于u m l 的组件软件测试 该方法采用的测试技术大致分为两类：基于状态的测试技术“1 和基于事件 信息流的测试技术。事件信息流测试技术类似于结构测试技术中的程序控制流 或数据流技术，不同的是事件信息流是从u m l 图( 如协作图，状态图等) 中获得， 而不是从程序源代码中获得。 基于状态机的集成测试主要是从状态图中提取测试相关信息的舯“。但该方 法可能存在组合状态爆炸问题，其研究重点也就是如何较少测试用例的产生数量 和优化测试过程。 u m l 顺序图和协作图反映的是外界与对象之间或对象与对象之间为了完成所 需要功能而传递信息的关系，二者不同之处在于顺序图是以时间排序的，而协作 图着重于对象之间的关系。所以，很多基于事件流的测试是以顺序图和协作图为 基础的“。h o i j i n 嗍根据组件的信息传递模式把顺序图和协作图划分为 a s f ( a u t o m a t i cs y s t e mf u n c t i o n ) 单元，据此得到完整的测试模型，然后根据边 覆盖选择测试用例。但该技术没有考虑顺序图或协作图间的关系。f r a i k i n “”等 作了改进，他们认为各顺序图中如果存在相同的对象，则该对象就是不同顺序图 的组合点。但这仅表示了各顺序图和协作图的对象关系，其它的关系( 如控制流 关系等) 并不能被表示。y e “”采用其它u m l 图( 如活动图) 来反映这种关系，并称之 为连接图。如何解决该问题成为基于顺序图和协作图测试的研究重点。 王林章等“”提出了一个基于u m l 协作图生成集成测试用例的方法，将表示设 计的协作图作为测试模型，通过遍历每条消息的直接后继识别协作图中的表示用 例实现所有可能的场景路径，从每条场景路径中获取相应协作执行的路径条件、 参数变量和预期方法调用序列，最后使用范畴一划分方法确定场景路径上的输 入、输出、环境条件的合理组合作为覆盖该场景路径的测试用例，用于测试一个 协作场景路径上的交互行为。但系统对象都是自行开发的，消息类型只有普通、 条件、循环消息。而且只存在顺序循环。 基于u m l 的测试生成一般都是将u m l 模型转换到一个现成工具能够处理的中 间的形式化描述，这可能产生可控制性和可测性问题，而这二个问题到目前还无 3 上海大学硕士学位论文 t 眦p o s t g r a d u a t et h e s i so fs h a n g h a iu n i v e r s i t y 法完全解决，用这些方法测试入员还必须掌握复杂各种形式化理论。 3 基于组件元数据的测试“” 其思想是由组件开发者提供组件的某些元数据( m e t a d a t a ) ，组件使用者不需 要组件的源代码就可以查到组件的某些信息。元数据既可以描述组件的静态特 性，也可以描述其动态特性；针对不同的用户需求，可以提供不同的元数据，以 便于进行系统化测试。但是还缺乏组件提供者的支持；到目前为止还只能测试小 型程序。 4 组件交互测试 组件交互测试渊( c o m p o n e n ti n t e r a c t i o nt e s t i n g ，c i t ) 首先建立组件交互 的形式化数学模型，建立每个组件的形式化测试需求，用来描述组件交互可能的 顺序，这个模型可以处理并发和同步通讯；然后由测试需求生成单元测试用例， 进行单元测试；之后选择组件进行集成；生成复合( c o m p o s e d ) 测试需求，进而生 成集成测试用例；不断集成新的组件，直到整个系统全部完成。这种测试方法考 虑了集成的顺序，所以可以避免重复测试。缺点是，理论上讲模型可以从单元升 级到系统，但实际上可能会很复杂，难以处理。 文献 2 0 采用组件交互图( c o m p o n e n ti n t e r a c t i o ng r a p h c i g ) 来表示接口 和事件的直接关系，把c i g 图作为输入，用一种深度优先算法，得到需要测试的 路径集合。测试充分性条件包括每个接口、每个调用事件检测一遍，为了保证可 靠性，所有控制流路径部分数据流路径，也要检测。这种方法的通用性强，可 用于各种基于组件的软件系统，不需要知道组件的源代码，对于c o m 、c o r b a 、e b 组件都适用。该方法做了案例研究，通过对一个股票交易系统( 包含1 8 个组件， 1 0 3 7 个接口) 进行平行测试，发现比传统方法更加有效，能够用更少的测试用例 检测到更多缺陷。缺点是随着被测系统规模的扩大，方法的复杂性会显著提高。 5 组件内建测试“” 组件内建测试( b u i l t i n t e s t si nc o m p o n e n t s ，b i t ) 采用一种新的组件规 范，要求组件支持正常模式和维护测试模式。要求在组件源代码中增加用于内 建测试的成员函数，在维护模式下可以调用该函数：在正常模式下该函数是不会 激活的。 这种内建测试的思想不局限于组件，对类和对象也适用，用处也很广泛，可 以不局# 艮于测试。但显然这种方法需要源代码。 6 基于变异的测试乜1 1 t d s ( t e c h n i q u e ，d e v e l o p m e n tf r a m e w o r k s ，a n dq u a li t y a s s u r a n c es c h e m e s ) 的第一步确定组件的接口；第二步，确定接口中提供的方法( m e t h o d ) 和异常处理 ( e x c e p t i o n ) ，哪些是必须进行覆盖的；第三步，确定这些方法和异常处理函数 4 上海大学硕士学位论文 t h ep o s t g r a d u a t e1 啦s i so fs f i a n g h a lu n i v e r s r r y 的参数，用突变算子( m u t a n to p e r a t o r s ) 对其进行处理；第四步，根据组件需求 创建测试集，然后运行测试；第五步，去除测试中发现的错误( e r r o r ) ；第六步， 扩充测试集达到i 0 0 的接口覆盖率( i n t e r f a c e _ _ b a s e dc o v e r a g em e a s u r e ) 。 这个方法的特点是提出了组件软件测试的充分性条件，并由此生成、检验测 试用例；但提出的测试充分性条件还需要与传统的测试充分性条件进行比较，例 如对比不同的方法，看谁能更有效地检测出软件中播种的错误( s e e d e de r r o r ) 。 1 3 论文的主要研究内容 本文在充分吸收国内外组件软件测试领域新的理论和方法基础上，利用u 札 协作图和状态图模型，对分布式组件软件实施测试。本文的主要内容如下： 第一章：引言。首先介绍了论文选题及研究意义，然后介绍了国内外研究情 况。最后提出了本文的主要工作目标。 第二章：分布式组件软件建模。首先介绍了分布式组件系统，分布式组件系 统的开发和一般结构；然后介绍了测试分布式组件系统可能出现的错误，从错误 分析中得出组件软件的测试模型：接着分别介绍了基于u m l 协作图和状态图的测 试模型；最后介绍了如何从目前主流的三种组件软件中提取测试元素一接口和事 件。 第三章：测试用例自动生成方法。首先介绍了基于u m l 协作图和状态图的测 试准则；然后介绍了如何从u 札协作图状态图规格说明中获取所需的信息；最 后分别介绍了基于u m l 协作图和状态图的测试用例生成方法。本文直接从u 虬协 作图中产生测试用例，并分别讨论了如何处理条件、并发和循环消息；对于状态 图，本文先将状态图转换成测试流图，然后从测试流图中来产生测试用例。 第四章：系统实现。本文首先提出了系统实现的总体框架，共有四个模块： p 咀。解析器、转换器、t c g 生成器和测试用例管理；接着对这四个主要模块 的数据结构和类进行了较为详细的介绍；最后给出了这个系统实现的部分界面和 简单操作。 第五章：结论和展望。总结本课题主要研究成果和下一步的工作。 1 4 本章小结 分布式技术和组件开发方法为软件测试工作带来了新的挑战。本文首先指出 了传统测试技术和测试模型不适合组件软件的测试，然后介绍u m l 开发和测试 上海大学硕士学位论文 t h ep o s t g r a d u a t et h e s i so fs h a n g h a iu n e r s y 技术情况，为后面测试工作做了背景铺垫，并指出本文研究意义所在。接着对基 于组件软件测试的国内外研究情况进行全面分析。最后对全文的主要内容作了简 单介绍。 6 上海大学硕士学位论文 眦p o s t g r a d u a t et h e s i so fs h a n g h a il r n i v e r s 玎y 第二章分布式组件软件建模 2 1 分布式组件系统 2 ，1 分布式计算 分布式系统是基于网络互相连接的若干计算单元协同计算的软件实现。通过 网络的相互连接，分布式计算提供了一种跨越网络透明访问各种异构设备所需要 的支持，用户可以充分利用网络上的各种资源完成自己的任务。 当前许多企业应用被设计成分布式的应用模式，用于支持企业内部以及企业 之间透明的业务处理。 按照各个计算机之间互相连接的紧密程度，分布式系统可以分为紧耦合系统 和松耦合系统两大类。紧耦合系统包括分布式操作系统，而松耦合系统则包括网 络操作系统和基于中间件的分布式系统。这三类分布式系统的一般特点如下： 分布式操作系统：分布式操作系统与传统的单机操作系统在功能上完全 一样，只是分布式操作系统涉及到多个处理机。在分布式操作系统中， 每个站点都有自己的局部操作系统内核，负责处理该站点机的局部资源。 分布式操作系统位于各个局部操作系统内核之上，负责处理各种不同任 务的并发执行，包括任务调度、存储共享和错误恢复等，对于用户而言， 看起来就像是一台虚拟机。 网络操作系统：与分布式操作系统不同，网络操作系统一般不要求所有 的站点机具有相同的局部操作系统内核。这些站点机通过网络彼此相互 连接，通过网络操作系统对外提供服务。 基于中间件的分布式系统：无论是分布式操作系统或者是网络操作系统， 都难以满足分布式系统定义所要求的众多属性。目前最为流行的分布式 系统都采用中间件的模式，即在高层分布式应用和底层局部操作系统和 网络之间插入一个中间层，即用于屏蔽底层异构的操作系统和网络的差 异，又能对高层应用表现出系统的同一性和透明性。中间件用于提供的 最基本系统服务包括通信服务、名字服务、存储服务、分布式事务服务、 安全服务等。 7 上海大学硕士学位论文 t h ep o s t g i l a d u a t e l 。h e s i so fs h a n g h a iu n n ，e r s l t y 2 1 2 基于组件软件开发 目前软件工程界对组件没有统一的定义，我们不妨这样理解“组件川”：组 件是带有一定独立功能的，独立发布的，遵循某个组件标准的，支持第三方集成 的二迸制软件单元。它有如下特点： 即插即用。组件能方便地由第三方集成于软件系统中，不需要修改代码 和重新编译： 以接口为核心。组件的接口和实现分离，通过接口实现与其它组件或系 统交互，具体的实现被封装在组件内部，系统组装者只关心接口，不必 知道实现细节； 标准化。组件的接口被严格标准化，这实际上是组件技术成熟的标志之 一。且前主要组件标准有m i c r o s o f tc o m d c o m ，j a v a b e a n s 和e j b ，以 及o m g 组织的c o r b a 。 组件市场和组件库。在全球化的组件市场中或由开发人员开发积累的组 件库中有大量成熟组件，软件系统组装者能从中挑选合适的组件。组件 提供者对组件的拥有版权，对组件的质量负责，并且提供详细的组件使 用文档。 基于组件的软件开发过程与传统的面向过程或面向对象的软件开发过程有 所不同。传统的软件开发过程是围绕用户需求进行需求分析和设计，软件完全根 据用户的需求定制，称之为基于需求的软件开发过程。而基于组件的软件开发过 程，由于通常从商业市场上购买的组件并不是为了某一个固定用户定制的，或者 组件实现的功能并不是完全与用户要求吻合的，因此，基于组件的软件开发过程 是在用户需求、软件设计、项目管理和组件市场之间的一个平衡过程。传统软件 开发过程是对图2 - 1 表示的子开发过程的迭代瞄1 ，而基于组件的软件开发过程是 对图2 - 2 表示的子开发过程的迭代啪1 。 图2 一l 传统软件开发迭代子过程图2 2 基于组件软件开发迭代子过程 8 上海大学硕士学位论文 1 p o s t g r a d u t et h e s i so fs h a n g h a iu n e r s l t - 2 1 3 分布式组件系统一般的体系结构 尽管不同开发环境和中间件对分布式组件系统开发的支持程度上存在一定 差异，但是在体系结构上，它们却具有很大的相同之处。通过对一般的体系结构 的分析，可以更加容易理解分布式组件系统的本质，对于分布式组件系统的软件 模型的认识也更加清楚。 图2 3 是分布式组件系统的一般体系结构。从图中可以看出，本质上分布 的组件之间还是服务器和客户之间的关系。提供服务器的组件称为服务器，而请 求服务的一方的角色是客户，当然，这种角色并不是固定不变的。系统中客户和 服务器是两个主要的角色，其它成分构成组件之闯交互的基础结构。基础结构包 括请求方代理、服务器端代理和通信结构。 i 【曩紫。 i 属鹤谢棠方 i， 【映黼if 釜哆毳理】 涵 【谴痞 也定雀 盈务】一 li l 一一 图2 3 分布式组件系统一般体系结构 组件之间的一次交互是这样的：请求方首先发送服务请求给本地的代理对 象，请求方此时不需要对任何分布式本身的语义进行处理；请求代理方通过基础 通信结构传送请求，通信结构通过对象组件定位器的服务得n n 务提供方的引 用，并将请求传递给它；提供方代理可以引导请求，所以提供方并不知道分布的 细节就可以得到相应请求；如果结果存在，这些结果就会沿请求路径返回到客户 方组件。 通过上面的一般体系结构的分析可见，分布式组件系统本质上是底层代理和 基础通信结构支持下的一个并发系统，组件之问的主要关系是并发与交互关系。 分布在不同物理计算机的组件运行在不同进程当中，它们的运行在时间上是并发 的，组件之间交互是在支持平台帮助下完成的。更高抽象可以将分布式组件系统 理解为分布在不同物理位置的实体，实体各自具有自己的行为特征。实体之间存 在消息交换，所有的通信都是通过消息传递完成的。 u m l 协作图可以描述系统中组件实现行为的交互方式，它们为完成某个目标 9 上海大学硕士学位论文 t h ep o s t g r a d u a t et h e s i so fs h a n g h a lu n i v e r s i t y 而在协作中进行消息交换，因此u m l 协作图可以为这种类型的软件建立模型。但 是u m l 协作图本身并不能充分为组件间的交互行为建模。为了更加精确地为组件 行为建模，我们还结合u m l 状态图来描述组件问状态依赖关系。这样利用u m l 协 作图和状态图就可以为组件软件建立严格准确的模型。 2 2 模型分析 2 2 1 错误分析 为了描述测试模型，我们先描述测试组件软件系统时可能遇到潜在的错误。 基于这些错误特征，我们建立测试模型来检测组件软件之间可能潜在的错误。 在组件软件系统集成测试中，组件问交互评估是中心问题。组件间交互错误 可分为组件间错误和互用性错误。尽管组件在单元组件测试中已被单独测试过， 但错误仍然存在。在单元测试中，还有属于传统的错误类别没有被发现。下面对 上述三种错误分别进行分析“州： 1 组件间错误 在一个基于组件的软件系统中，即使单个组件已被单独测试过，当把它们集 成到一块，仍可能存在潜在的错误。与多个组件相关的错误被称为组件间错误。 例如在下列伪代码中，这里c 代表组件，i 代表组件的接口，通过把变量i = o 加入到组件c 。的接口i 。中，同时测试i ，和i 。，不能监测到任何错误。但当组件 c 。和组件c 2 ，厶集成在一起时，组件c ：调用i ：接口和c 。调用接口i ：，那么在a 中将产生溢出错误。 c i ： i l i - - - - 0 ； 1 2 一r e t u r r li ： g ： 1 3 一c l ：i l ( ) ； c 3 ： i 一j = 1 c 。：i ：( ) ； 2 互用性错误 基于组件的软件系统有许多特性，如异质、源码不可知、复用性等，致使有 不同类型互用性问题。这些发生的互用性错误从低到高划分为不同的级别：系统 1 0 上海大学硕士学位论文 1 h ep o s t g r a d u a t e1 1 正s i so fs h a n g h ju n i v e r s i t y 级、程序级和规格说明级互用性错误。 系统级互用性错误：在一个基于组件的系统中，不同组件可以被建立在 不同的组织下，如不同的操作系统和系统库的不同集合。 程序级互用性错误：当组件用不同的程序语言编写，而程序语言中的不 相容性也可导致失败发生。例如经常遇到的不相容问题之一是v c + + 和 v b 中不相同的双精度值的处理。 规格说明级互用性错误：在许多的情况下是开发者曲解了规格说明。 数据歧义曲解通过接口的数据。如返回值或输入数据的类型和值 的误解等。 控制歧义曲解交互模式。这包括曲解接口的执行序列，例如，许 多组件有初始化接口，此接口必须在其它接口之前被调用，如没有 这样做将导致出错；也包括曲解交互机制，例如，当异常产生时， 接口就需要进行异常处理，如果缺乏异常处理，软件则会崩溃。 3 传统错误和其它错误 在组件中有些错误是孤立的，可以采用传统的测试和维护技术，这些错误定 义为传统错误。其它错误，如与特定输入和特定执行环境相关的错误也归入这类 错误。 从以上错误分析，可以看出组件软件的错误主要在于组件间及组件与其环境 间的交互性错误。产生这些错误所涉及的因素主要是接口、执行的事件及相应的 依赖关系。 2 2 2 组件软件的测试模型 测试组件软件时，我们假设每一个单独的组件已经过充分测试。因此一个可 靠软件系统的关键就是保证组件间交互的正确性。y ew u “驯提出的测试模型重 点解决组件间的交互和上一节描述的错误分析类型1 和类型2 。一个组件与其它 软件间的交互可以是直接或间接交互。直接交互包括接口调用、异常处理或用户 触发一个事件；间接交互是通过一个事件序列来完成的。 组件软件通过把能实现一定功能的组件集成起来，以完成总体功能和需求。 所以其集成测试的中心环节是测试组件间及组件与环境间的交互操作。由于组件 源代码不可知，组件对外提供的只是接口和事件。接口和事件是组件的基本元素， 也是组件软件测试的基本元素。当组件集成时，程序员一般只注重如何规定接口 和事件。但这些接口和事件如何交互，以及集成系统中潜在的错误通常没有考虑。 因此基于组件软件测试需要考虑的关键要素有接口、事件及它们之间的依赖关 上海大学硕士学位论文 t h ep o s t g r a d u a t et h e s i so fs h a n g h a iu n i v e r s i t y 系。 接口是组件的入口点，通过接口客户端组件可以请求服务，该服务公布在服 务提供者组件的接口上。每一组件由接口名和唯一接口i d 来表示。接口是组件 与其环境交互的门户。因此在集成和系统测试中每个接口至少被测试一次。 测试接口可以保证每个可能被调用的接口在运行时间内至少被执行一次，这 方面与传统的要求每个函数或过程至少被测试一次相似。但在不同上下文中被不 同组件调用的接口可能有不同的结果，某些并没有经接口触发的事件也对组件有 影响，也需要被测试。即在系统中每个事件，不管它的类型如何，都至少被测试 一次。 接口测试和事件测试确保两个组件( 客户端和服务器) 间的每次交互都执行 了测试。然而一个组件软件系统包括一组组件间的交互，事件触发序列可以产生 意外的输出结果，所以需要捕获事件间的关联关系，这类似于传统程序中控制流 依赖关系。如果存在如下执行路径，如o 的触发会直接或间接触发o ：，则事件e 。 和事件f l 。间有一个上下文敏感依赖关系。对给定的事件e ，需要测试与e 有敏感依 赖关系的每个事件，观测执行历史对e 的执行输出的可能影响。这种依赖关系不 仅包括直接交互，而且包括由其它接口和事件触发的事件与接口间的协作关系。 因此这种依赖关系适合于识别由不同组件间不恰当的交互引起的交互性错误。 接口和事件是测试的基本元素，从组件规格说明中相对容易获取组件接口。 识别事件第一必须知道触发事件的接口和对应事件的被调用的接口，事件触发或 执行的行为表现为集成组件间的交互性，所以只要可以对组件接口及接口间的交 互进行建模，事件就不难获取。我们用u m l 协作图和状态图来为组件软件建模。 e m l 协作图描述了系统的一个协作参与组件之间如何交互，但是删l 协作图本身 并不总是可以充分为组件间的交互行为建模。为了更加精确地为组件行为建模， 我们还结合u m l 状态图来描述组件间状态依赖关系。例如，从图2 4 我们可以 看出序列“2 a 一2 a 卜2 a 2 ，2 a 2 a 一2 a 3 ，2 a 2 a 1 ”( 2 a 2 和2 a 2 a 是一对并发 消息) 是允许用户进行取消操作的唯一序列。然而，该序列可以发生在不同上下 文中，如用户在正确输入p i n 后取消当前交易，或输入p i n 错误后取消当前交易。 图2 7 是图2 4 对应的状态图。根据该状态图，我们可以清楚看出取消操作是 在下面三种不同场景下发现：a ) 等待p i n ，b ) 有效的p i n ，c ) 等待客户的选择。 使用状态图可傻接口和事件间的交互描述得更精确。使用状态图我们描述的 依赖关系不仅包括所有可能存在协作图中的序列，而且包括所有可能存在状态图 中的结合序列。 1 2 上海大学硕士学位论文 1 1 虹p o s t g r a d u 觚1 忸s i so fs 姒n g 队il r n i v e r s i r v 2 2 3 基于u m l 协作图的测试模型 u m l 协作图强调发送和接受消息组件之间的结构组织。可以用来按交互中的 角色及其关系对一个用例的特定实现场景进行建模。它描述了特定行为的参与组 件的静态结构和动态交互。动态交互部分是一个消息集合，包括一个和多个动态 交互，表示在执行计算过程中不同时间里协作中的消息流，这些消息定义了行为 方面的内容。协作图有路径，有顺序号。协作图中的消息箭头表示组件之间的消 息流，消息上可以标注说明发送的顺序，还可以指明条件、重复和返回值等。一 个协作图从引起整个交互或协作的消息开始，如一个操作调用。图2 4 是a t m 客户端输入p i n 用例的协作图。 图2 - - 4a t m 客户端输入p i n 用例的协作图 协作图描述参与交互和相互关联的组件之间的交互，但是标准协作图的消息 标记并不能充分描述组件间的交互信息，因此需要对协作图的消息标记进行扩 展，以适应组件软件测试的需要。协作图应该提供如下六点信息啪”： 1 交互中的组件和这些组件的结构； 2 调用一个组件的顺序： 3 操作语义； 4 和其它组件之间的协作，由其它组件而引起的操作； 5 协作图中组件间协作图模型( 同步或异步) ； 6 组件执行特征( 并发或顺序) 。 我们对协作图的定义如下： 上海大学硕士学位论文 t h ep o s t g r a d u 御。r 呱s i s0 fs h a n g h a iu n i v e r s r r y 定义1 ：组件协作图c d 可以表示为一个二元组：c d = ( o s ，m ) 。其中： o s = o s 。，o s ：，o s 。，o s ) 是c d 中非空有穷的组件集合。 m = m l ，m 2 ，m 3 ， 是c d 上描述有穷消息的集合，每个消息定义 为：m i2 ( l n 鲫e ，g u a r d ，s e q u e n c e e x p r e s s i o n ，p a r a m e t e r _ l i s t ， r e t u r n _ v a l u e ，r e c e i v e r ，s e n d e r ，t y p e ) ；其中 一mn a m e 为消息名； 一 g u a r d 为消息发送的卫式条件； 一 s e q u e n c e e x p r e s s i o n 表示顺序项列表每一项表示交互中的一个嵌 套层次，如果所有的控制并行则无嵌套；整数表示过程调用中的相 邻高层中的消息的顺序，同一整数项中的不同消息在嵌套层是顺序 关系，同一前缀的消息顺序号构成序列，构成消息之间偏序关系。 循环表示条件或迭代执行，表示根据条件执行零个或多个消息； 一p a r a m e t e r l i s t 为消息的参数； 一r e t u r n v a l u e 为消息的返回值； 一 s e n d e r 为消息的发送组件； 一 r e c e i v e r 为消息的接收组件； 一t y p e c o n l l n o n ，p a r a l l e l ，l o o p ，c o n d i t i o n ) 。c o m m o n 表示普 通消息，p a r a l l e l 表示并发消息，用小写字母表示；l o o p 表示循环 消息，用$ 表示；c o n d i t i o n 表示条件消息，用大写字母表示。如2 7 和2 7 a 是一对并发消息，1 1 a 和1 1 是一对条件消息，2 6 a * 是循 环消息。 实际上，协作图描述州l 用例图中的场景，其中场景被定义为在相互交互组 件阃传递的一个消息序列，每个消息序列代表该用例的一个可能的事件流。协作 图强调了参与交互组件的组织，体现交互组件间的整体连接关系，通过在组件间 的连接上带有标签的消息来描述组件间的交互。消息是组件间的通信，它传达了 要执行动作的信息，它能触发事件，接受到了一个消息通常被认为是一个事件。 通常，当一个组件调用另外一个组件的操作时，即完成了一次