（计算机软件与理论专业论文）基于元数据的构件测试技术研究.pdf

复旦大学硕士学位论文基于元数据的构件测试技术研究 基于元数据的构件测试技术研究 【 摘要】 针对构件软件的混杂性、 源码不可用性以及版本不确定性等给软件测试带来 的困难，本文通过对 mi me文件格式及多种构件标准中元数据定义的研究，提 出了一种通用的构件测试元数据表示方式， 该测试元数据需构件开发者提供: 并 以 此为基础， 将软件测试步骤与构件开发相结合， 对构件单元测试、 构件交互测 试及构件回归测试分别进行进一步研究。 文中首先给出了一种基于规约消息序列 来选择测试用例的方法， 可对数据流异常进行检测， 以保证选择的测试序列满足 测试充分性标准: 然后， 通过对面向 对象集成测试算法的改进， 解决了构件内 部 类之间的测试顺序问题;同时，本文提出了一个构件测试过程 c t p及其实现框 架， 其中包括了黑盒测试、 缺陷注入等方式; 并针对构件交互测试， 提出了一个 测试模型进行错误检测; 最后， 给出通过构件开发者提供的元数据来进行回归测 试的方法，并对基于版本元数据和覆盖元数据的测试用例选择算法进行了讨论。 【 关键字】 构件软件测试，数据流异常，元数据，对象状态图，构件交互图，版本元数 据，覆盖元数据 复旦大学硕士学位论文 基于元数据的构件测试技术研究 re s e arc h on comp one nt t e s t i ng t e chnol ogy b as e d on a b s t r a c t t h e h e t e r o g e n e i t y , u n a v a i l a b i l i t y o f t h e s o u r c e c o d e a n d u n c e r t a i n t y o f v e r s i o n o f c o m p o n e n t s o ft w a r e m a k e i t d i ff i c u lt t o t e s t s o ft w a r e . s o w e m a k e a p r o f o u n d s t u d y o n m i m e f o r m a t a n d d e f i n i t i o n o f m e t a d a t a i n c o m p o n e n t s t a n d a r d , a n d p r e s e n t a u n i v e r s a l e x p r e s s i o n o n c o m p o n e n t t e s t m e t a d a t a . t h e m e t a d a t a i s p r o v i d e d b y c o m p o n e n t d e v e l o p e r . b as e d o n t h e m e t a d a t a , t h e p a p e r c o m b i n e s s o ft w a r e t e s t s t e p s w i t h c o m p o n e n t d e v e l o p m e n t a n d m a k e s f u r t h e r s t u d y o n c o m p o n e n t t e s t , c o m p o n e n t i n t e r a c t i o n t e s t a n d c o m p o n e n t re g r e s s i o n t e s t . t o s e l e c t t e s t c a s e s b ase d o n t h e s p e c i fi c a t i o n . f i r s t , w e g i v e a me t h o d w h i c h i s u s e d s e q u e n c e d e t e c t d a t a fl o w a n o m a l y a n d m a k e s u r e t h a t t h e a g e t 匕sl c r i t e r ia . t h e n w e g e t t h e t e s t o r d e r o n e v e r y c l ass i n c o m p m o qma yo t t h e t e s t o n e n t衍 s . t h e me t h o d c ase s s e l e c t e d me e a d e q u a c y i m p r o v ing c o inp o m e n t h e 0 0 i n t e g r a t i n g t e s t a l g o r i t h m s . a t t h e s a m e t im e , w e p r o p o s e a t t e s tp r o c e s s a n d i t s i m p l e m e n t a t i o n w h i c h i n c l u d e s b l a c k - b o x t e s t , f a u l t i n j e c t i o n , a n d s o o n . w e b r in g f o r w a r d a t e s t m o d e l t o d e t e c t c o m p o n e n t i n t e r a c t i o n e r r o r . f i n a l l y , w e g i v e a m e t h o d t o e x e c u t e r e g r e s s i o n d i s c u s s t h e r e g r e s s i o n t e s t s e l e c t i o n a l g o r it h m b a s e d me t a d a t a . k e y w o r d s l c o m p o n e n t s o f t w a r e c o m p o n e n t i n t e r a c t i o n t e s t , d a t a fl o w a n o m a l y , m e t a d a t a , o b j e c t s t a t u s d i a g r a m , d i a g r a m , v e r s i o n m e t a d a t a , c o v e r a g e m e t a d a t a 复曰大学硕士学位论文 基于元数据的构件测试技术研究 引言l 随着软件数量、 规模和复杂性的不断增加， 软件的质量保证活动日 益成为人 们关注的焦点。 软件测试是软件质量保证的重要手段， 代表了规约、 设计和编码 的最终检查。 软件故障带来的不断增加的高昂代价使软件开发人员越来越注重于 规划良 好的彻底的测试。 现有的软件测试技术主要用于测试面向过程和面向 对象 的软件。 随着构件技术的日 趋成熟， 基于构件的软件设计方法已经成为当今软件 开发方法的新趋势。 基于构件的开发方法引入了许多不同于传统开发方法和面向 对象方法的新的特性， 现有的软件测试技术己不能满足测试基于构件的软件的需 要。 因此， 我们需要根据构件的特点， 对现有的软件测试技术加以改进， 或者提 出新的软件测试技术，更好地满足构件软件开发过程中 质量保证的需要。 对构件软件的测试可以分为三个步骤:构件单元测试 ( 构件测试) 、构件交 互测试和构件回归测试。 本文分别详细研究了这三个测试步骤中的一些问 题， 并 给出了相应的解决办法。 在构件单元测试中， 本文从构件开发者和构件使用者的 角度对构件进行测试。 然后通过构造构件交互图对构件进行交互测试， 以发现构 件交互中的错误。 本文最后讨论了回归测试技术在构件软件测试中的应用。 在本 文的三个测试步骤中，都将构件开发者提供的元数据作为重要参考。 本文共分为六章， 首先对软件测试、 面向 对象测试和构件软件测试进行了简 单阐述;然后按照构件软件测试步骤:单元测试 ( 构件测试) 、交互测试和回归 测试详细介绍了自己在构件软件测试领域里的研究成果。 第一章简单介绍了软件测试研究的背景、 面向对象软件测试以及构件软件测 试研究现状， 指出了构件技术给软件测试带来的新的困难， 并简要介绍了 本文所 要解决的主要问题。 第二章讨论了构件元数据的表示， 提出一种通用的元数据表示方式， 既可以 使构件开发者以规范形式为构件增加附加信息， 又可以以 一种通用的方式让构件 使用者获取所需的信息。 第三章从构件开发者和构件使用者的角度对构件进行单元测试， 对目 前的面 向对象测试技术进行改进; 同时提出一个构件测试过程及其实现以 保证构件的适 用性。 第四章研究了构件交互测试问题， 使用元数据构造构件交互图， 并在此基础 上，提出一个测试策略来进行交互测试。 第五章重点研究了构件元数据在回归测试选择技术中的应用， 通过使用构件 开发者提供的版本数据和覆盖数据， 使用本文提出的测试策略进行测试选择。 第六章总结全文并展望将来的工作。 复旦大学硕士学位论文 基于元数据的构件测试技术研究 第一章 绪论 ， . ，软件测试简介 通俗地讲， 软件测试是发现并指出软件系统缺陷的过程。 缺陷在软件开发和 维护的任何阶段都有可能发生，并由此产生一个或多个“ 漏洞”一一错误、 误解 和冗余， 有时甚至会误导开发者。 测试包括寻找缺陷， 但不包括跟踪漏洞及其修 复。 换句话说，测试不包括调试和修复。 测试能充分保证应用软件做它想做的事。 如果软件在交付使用之前没有经过 良 好的测试， 那些未被发现的软件错误迟早会在系统运行过程中暴露出来， 这往 往会导致很严重的后果; 而且想改正这些错误相当困难。 由软件缺陷带来的如此 高的代价使软件开发人员越来越注重规划良好的彻底的测试， 软件开发组织通常 将 3 0 %-4 0 %甚至更多的项目 精力花在测试上。对一些关键的软件 ( 如飞行控 制和核反应堆)测试所花的时间往往是其它软件工程活动时间之和的三到五倍。 测试能帮助确保一个产品满足需求， 但测试并不是质量保证。 有些人错误地 将测试和质量保证等同 起来。 在许多组织中， q a通常负责开发测试计划和执行 系统测试。 q a可能会对开发过程中的测试进行监测和保留 统计数据。 测试是 任 何质量保证过程中必需的 但不是所有的 部分。 q a从事的是那些用来防止和去除 在产品中确实存在的缺陷的活动。 1 . 1 . 1 软件测试技术发展回顾 自从计算机问世以来， 程序编制和程序测试这两个课题一直是计算机科学的 两个热点问题。 对程序进行测试的最基本方法是将程序运行并把运行结果同预期 的结果进行比较，从而验证程序是否正确实现。 6 0 年代的软件危机导致了软件工程思想的出现。7 0 年代初，人们提出了软 件生存周期的概念，明确地将软件开发工作划分为若干阶段，并规定需求分析、 系统设计和实现阶段的目 标，以及每个阶段生成的产品 【 4 1 。由 于程序中的错 误不仅仅由编码引起， 而且有可能是分析或者设计本身的问题， 因此人们将软件 测试的概念扩展到软件开发的各个阶段， 从而使人们对软件测试的认识更加广泛 和深刻，这对于软件产品的质量保证以及软件开发过程的组织具有重要的意义。 1 9 7 2 年， 在美国的北卡罗来纳大学召开了首次软件测试的正式会议。 会后， 软件测试的 研究进入了一个重要时期。 j .b .g o o d e n o u g h 和s .l .g e r h a r t 3 6 】 率先 复旦大学硕士学位论文基于元数据的构件侧试技术研究 提出了软件测试的理论， 从而把软件测试这一实践性很强的学科提高到理论的高 度， 被认为是软件测试技术发展过程中最有开创性的工作之一。 w e .h o w d e n 3 7 修正了 上述理论中的 缺陷。 e .j .w e y u k e r 3 8 】 等加以 进一步的 补充和完善。 这一 时期， 出现了路径测试、 域测试、 数据流测试、 错误驱动测试以及状态测试等技 术，并开始研制相应的测试辅助工具。 8 0年代，软件质量问题成为软件工程领域所关注的热点。国际标准化组织 制定了与软件测试相关的国际标准，如i e e e / a n s i s t d - 8 9 2 规定了软件测试的 文档标准，i e e e / a n s i s t d - 1 0 1 2规定了软件测试确认与验证计划标准， i e e e / a n s i s t d - 1 0 2 8 规定了 软件测试复查和审计标准等。 9 0年代以 来，随着面向对象技术的广泛应用，原有的测试技术已 无法适用 于面向对象软件， 面向对象软件的测试面临新的困难。 为此， 人们以传统的测试 技术为基础，结合面向对象软件的特点，对面向对象软件的测试技术进行研究， 也取得了一些进展。当前， 软件测试的研究工作主要集中于测试用例的生成、 测 试自 动化工具， 面向对象软件测试以 及分布式软件测试等。 继面向对象的设计方法之后， 基于构件的软件设计方法正在逐渐成为新的趋 势。由于构件的特点， 使得基于构件的软件开发更具优势， 但也带来了分析、 设 计、 实现测试和维护的一系列问题。 本文关心其测试问 题。 构件的测试问 题应该 从构件开发者和构件使用者两个角度来看， 原因有三: 一是使用环境 ( 包括编程 语言、 操作系统、 硬件平台)的不同;二是拥有的资源不同，构件开发者拥有构 件源代码， 而构件使用者可能只有构件的可执行代码; 三是测试目的不同， 构件 开发者需要测试构件的所有功能，构件的使用者只关心与他相关的构件功能。 现有的软件测试通常分为静态 ( s t a t i c ) 和动态( d y n a m i c ) 测试。 静态测试是 指在分析、 检查和测试软件时不实际运行被测试程序， 如: 审查、 符号演算以 及 验证。动态测试是指通过运行软件来检验软件的动态行为和运行结果的正确性。 因此，动态测试必须包括被测程序和用以运行软件的数据 ( 即测试数据) 4 1 1 . 从选择和产生测试数据的来源看， 动态测试分为基于规约的测试 ( 又称黑盒 测试或功能测试) 、 基于程序的测试 ( 又称白 盒测试或结构测试) 、 规约与程序的 联合测试。 基于规约的测试是指测试者不需要了解程序的内部结构， 直接根据程 序的输入和输出之间的关系或程序的需求规约、分析与设计规约来确定测试用 例，推断测试结果的正确性。基于规约的测试包括:等价类划分测试 ( p a r t i t i o n t e s t i n g ) 、因果图 ( c a u s e - e ff e c t g r a p h i n g ) 、 判定 表 ( d e c i s i o n t a b l e ) 、 边界 值分 析、 正交实验设计、 状态测试、 事务流测试等. 基于程序的测试是指测试者根据程序 的内部结构特性和与路径相关的数据特性设计测试用例。 常用的测试方法有: 路 径测试、 域测试、 符号测试、 数据流测试、 控制流测试、 程序插装和程序变异等。 复旦大学硕士学位论文 基于元数据的构件侧试技术研究 由于两者相互互补，常常采用联合测试方法。 为提高软件测试的效率，加快软件开发进程， 人们从7 0 年代开始研制相应 的测试工具。 如: 美国程序设计环境署开发了测试数据生成器， 用于证明需求的 可测试性， 产生测试数据并分析最终的测试结果: 加利福尼亚大学开发的支持测 试过程的t a o s ; r a t i o n a l 公司推出的一系列测试工具:快速查找内存泄露和防 止运行错误的 p u r i f y 、检查代码覆盖率的 p u r e c o v e r a g e ,测试软件性能的 q u a n t i f y , 测试系统性能的l o a d t e s t 、 进行功能测试的t e a m t e s t 以 及用于测试管 理的t e s t m a n a g e r 等， 并且这些测试工具还可以 与版本控制和需求变更管理的工 具相集成，从而实现更为复杂的功能。国内也开展了软件测试工具的开发，如: 清华大学开发的 c o b o l软件测试环境、f o r t r a n程序静态分析和动态分析系统 d t f g ， 北京航空航天大学开发的c 程序测试系统、 c h e n x u e s o n g 等的构造允许 剖面和产生测试数据的计算机辅助工具 【 5 6 1 ,暨南大学的c h e n h u o y a n 5 7 的基于代码插装的类簇级测试工具等。目 前， 人们普遍认为， 软件测试工具不但 是有用的，而且是必要的。 1 . 1 . 2 软件测试的目 标及其策略 人们对软件测试目的的认识经历了一个过程。早期的软件测试被认为是调 试。1 9 8 3 年i e e e 给出了软件测试的定义: “ 使用人工或者自 动手段来运行或者 确定某个系统的过程， 其目的是检验它是否满足规定的需求或判定预期结果与实 际结果之间的差别” 。这就说明了软件测试是以检验系统是否满足需求为目的。 g .j .m y e r s 3 9 】在 他的软 件测 试著作中 陈述了 一系列 关于测 试目 标的 规则: 1 )测试是一个为了寻找错误而运行程序的过程。 2 )一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例。 3 )一个成功的测试是指发现了迄今为止尚未发现的错误的测试。 上述规则蕴涵了测试观念上的转变: 成功的测试是发现了以前未发现的 错误 的测试而不是人们通常认为的: 一个成功的测试是指没有找到错误的测试。 如果 成功地构造了测试， 则测试者就能够在被测软件中发现错误。 测试的目的是为了 发现软件中的错误或缺陷，而不是为了 证明程序的正确性。 从保证软件质量的角度， 软件测试是保证软件质量的重要手段。 通常采用一 些经济、高效的方法， 捕捉软件中的错误，以证实软件的内在质量。从软件的开 发角度来看， 软件测试与软件产品的整个开发过程紧密联系。 软件测试可以为软 件产品提供一些系统、 客观的方法来度量软件内在的质量。 如果在开发过程中提 供一些有益的支持，可以降低测试开销。 一个成功的测试必须包括两个方面: 一是软件在所有的( 足够多的) 测试数 复旦大学硕士学位论文基于元数据的构件测试技术研究 据上是正确的; 二是测试数据的充分性， 即软件在测试数据上的表现能够充分地 反映软件的总体表现。判断一个测试数据集是否充分称为充分性问 题 4 7 。为 了 保证测试的成功， 软件测试通常采取一些策略来达到预期的目 标。 软件测试策 略主要考虑:如何在一定的条件下， 将设计测试用例的步骤组织成一个系统的、 有计划的测试步骤。通常的做法是先假定需求说明以及设计文档是正确无误的， 然后遵循与软件工程目 标相一致的原则， 采取一定的测试步骤， 分级别进行测试， 直至整个系统测试完毕。 常用的 测试步骤包括: 单元( u n i t ) 测试、 集成( i n t e g r a t e d ) 测试、 系 统 ( s y s t e m ) 测试、 确认 v a l i d a t i o n ) 测 试、 验收 ( a c c e p t a n c e ) 测 试和回 归 ( r e g r e s s i o n ) 测试。 测试过程中， 既要保证软件测试的充分性， 又要避免过度测 试。 在不能完全测试一个程序的情况下， 只能选择对最主要的方面进行测试， 以 降低开发成本并保证产品达到一定的质量要求。 1 . 2软件测试研究现状 软件测试研究范围很广泛。 目 前主要研究的方向 有自 动测试、 面向对象软件 测试方法、 w e b 测试、 构件测试、 测试充分性研究等。 本文主要就面向对象软件 测试和构件测试的研究现状作一综述。 1 .2 . 1面向 对象测试研究现状 f i e l d e r 在8 9 年的论文 【 4 0 】中 最早关注面向 对象软件测试中的单元测试问 题。 该文研究了面向对象软件测试与传统的测试之间的某些方面的不同， 包括何 时开始单元测试、 选用什么样的测试技术等。 该文认为，由于面向对象软件强调 数据抽象和外部行为，因此功能测试是首选的 ，但结构测试也是必要的。面向 对象技术并没有使测试工作变得更轻松， 虽然面向 对象的编程语言 ( 如 j a v a . c + 十 等) 的使用可以减少一些编码的错误， 但同时也增加了出现其它错误的可能。 类是面向对象方法的基本单元， 类的实例就是对象。 类把描述对象特征的属 性 ( i n s t a n c e v a r i a b l e )和对这些属性的操作 ( m e m b e r f u n c t i o n )封装在一起，实 现了信息隐藏。 面向对象的另一个重要特性是继承， 子类可以继承父类的属性和 操作， 提高了代码重用率。 类也是面向对象程序测试的基本单元。 类的信息隐藏、 继承、多态等特性对软件测试提出了新的挑战。 . 面向对象特性对测试技术的影响 r o b e rt v . b i n d e r 从测试角度研究了面向对象特性如封装、 继承、 多态和动 态绑定等， 考察这些特性在什么方面影响和如何影响面向 对象软件测试技术， 他 复旦大学硕士学位论文 基于元数据的构件测试技术研究 认为这些特性的引入增加了测试技术的复杂性 【 3 9 a 另一些研究则考察如何利用继承关系对子类进行测试。 f i e l d e r 认为在父类进 行充分测试的基础上，被子类继承的方法只需最小测试;h a r r o l d在 【 4 2 】中提 出使用类继承关系的层次， 通过复用和增量更新父类的测试信息等方式， 指导子 类的增量测试。 . 类测试方法 对象是面向对象软件基本的运行时的实体， 它是类的实例。类是描述对象特 征和行为的封装体， 也是面向对象软件的基本的测试单元。 类测试一般分为基于 数据流的测试方法和基于对象状态的测试方法。 h a r r o l d 把类中的操作分成三个不同的级别， 并相应给出三种定义一引用对， 他提出 要按照 操作的 级别来进行相 应的 数据流 分析【 3 5 o u g o b u y 引 入了 符号 执行技术来对类进行数据流分析，从而自 动生成测试用例。 c . d . t u rne r 最早提出要根据对象的状态来进行测试 4 1 ，他认为属性描 述了对象的本质特征， 同时属性值决定了对象的状态， 每个属性可以看作是一个 子状态。 . 基于形式化规约的测试 很多研究人员致力于对面向对象软件进行良 好的形式化的规约说明， 希望可 以 在 此基 础上实 现面向 对象软件的自 动 化测试。 b a r b e y 在他的0 0测试框 架中 引 入了抽象数据类型a d t s 的概念;d i d i e r b u c h s 等人提出了面向对象的并行描述 语言 c o - o p n / 2 4 3 1 ，该语言使用很复杂的语法对面向 对象软件进行形式化的 描述。 可惜的是这项技术还远不够完善， 而且没有形成一个通用的形式化规约标 准，因此仍需深入的研究。 . 状态机测试和u m l 测试 很多论文都 将传统的 确定 有限 状态机 应用到0 0 测试领 域， h . s . h o n g 对 传统的确定状态机f s m加以拓展，重新定义了状态和状态迁移，标出了 错误的 迁移， 从而转变成类状态机c s m， 为了进行侧试， 他给出了从c s m生成控制流 图c f g的转换算法 4 4 7 0 b i n d e r 在他的著作 【 3 9 】中专门 详述了 如何利用u m l 来对早期的建模进行 测试，但只是指导性的建议，并没有具体的针对某种图进行详细的阐述。 y . g . k i m把u ml 状态图转换成扩展的确定状态机e f s m， 在此基础上进行数 据流测试。 . 集成测试策略和回归测试 复旦大学硕士学位论文 基于元数据的构件测试技术研究 y . l a b i c h e 在他的论文 4 5 ) 中， 引用了d . k u n g 的 测试模型o s d ， 并以 此为基础利用面向对象软件中类之间的复杂依赖关系给出了类的集成测试级别。 d . k u n g根据类之间的 依赖关系提出了 类防 火墙的概念，指出了 如果修改 了某个类，那些和它有着依赖关系的类也应该重新测试 3 0 1 . g . r o t h e r m e l 针 对面向过程的软件给出了一个安全有效的回归测试选择算法 【 4 6 1 ，在此基础上 h a r r o l d 给出了j a v a 软件的回归测试选择方法 【 1 8 . 1 .2 .2构件测试研究现状 目 前对构件的定义还没有统一的说法。a l a n 1 等提到 “ 构件是系统中一 个有价值的， 近乎独立的可替换部分， 在这个系统的上下文环境中实现清晰的功 能。 系统应该具有良好定义的结构。 构件要符合一组接口 标准， 井提供接口的物 理实现” 。c l e m e n s 2 1则认为构件是 “ 一个软件单元，具有一组契约或合同 规定的接口。 构件与它所在的环境/ 上下文有清晰的依赖关系， 并且仅仅与此相 关。 构件可以 被独立配置，以 便由 第三方进行组装 ( 新的软件) ; ” 而u g o 3 1 则认为“ 一个构件是可替换的软件单元， 具有一组契约或合同规定的接口。 构件 与它所在的环境/ 上下文有清晰的依赖关系，并且仅仅与此相关。 ”从中我们可 以发现构件具有一些共同的特点: 构件是近乎独立的、 可替换的、 满足一定功能 的模块; 构件之间通过接口 进行通讯; 构件通常是经过编译的二进制代码或机器 码，甚至是可以 执行的。 而构件软件是基于构件/ 构件技术开发的软件。目 前的应用己有很多， 如微 软的o l e自 动 化和a c t i v e x控制技术。 s u n c h a n g - a l , l i u c h a o 5 8 】 等提出 了 一种白 盒测试工具的设计方法，就是基于构件的思想。 构件软件有以下一些特点: 1 )混杂性 软件可以由多个构件组装而成， 这些构件可能是不同的编程语言编写的， 整 个软件分为几个部分， 分布运行在不同的操作平台上。 这一方面提高了软件的灵 活性、 可扩展性， 另一方面不同的编程语言、 编译器、 操作系统、 机器架构可能 有自己独特的数据处理方式，构件之间传送的数据可能会产生歧义。 2 ) 源码不可用性 对于构件的使用者， 通常只能得到构件的外部接口信息和二进制代码， 而构 件源代码可能无法获得。 3 ) 构件版本不确定性 构件的设计与实现贯彻了 面向 对象的思想。 以 微软的c o m构件为例， c o m 接口 在c + + 中是用没有实现细节的纯抽象基类实现的， 一个c o m构件可以 支持 复旦大学硕十学位论文基于元数据的构件侧试技术研究 多个接口，一个c 一类可以使用多重继承来实现一个支持多个接口的构件。 基于构件的软件设计不要求必须使用面向对象的设计方法， 但是不提倡使用 面向过程的设计方法设计基于构件的软件。 本文提出的构件测试方法都是针对基 于面向对象的设计方法生成的构件的。 h a r r a l d 7 】认为应该从构件开发者和构件使用者两个不同的角度来看待构 件软件的测试问题。 构件的开发者认为构件相对于使用构件的环境是独立的， 所 以要用与上下文独立的方式测试构件所有的功能。 相反， 构件使用者开发的应用 程序提供了构件的运行环境， 所以构件使用者不把构件看成独立的单元， 而且仅 仅考虑与应用程序相关的构件功能。 另一个重要的区别是构件开发者有构件的源 代码，而使用者则通常没有构件的源代码。 构件开发者面临的测试问题包括: 1 )测试充分性判据的可扩展性 s c a l a b i l i ty ) :由 于复杂性问 题和组合爆炸 问题，对小规模程序适用的判据对大规模程序不一定适用。 2 )测试数据的产生:由 于同样的原因， 难以 产生合适的测试输入，使得对 低层次元素 ( 分支、定义一使用对， 需求功能可看作是高层元素) 难以达到较高 的覆盖率。 3 ) 如何配置构件的测试环境: 对单个构件进行测试的环境，与构件在实际 系统中运行的环境可能不同。 所以 在测试构件时应该考虑模拟真实环境， 如构件 的竟争和死锁， 多线程等。 但是由于构件的复用， 难以完全模拟构件使用的所有 真实环境。 4 )构造测试驱动器和打桩技术:传统的技术是面向特定的工程。但是构件 的多样性和其功能的专用化使得传统的技术达不到应有的效果。 5 )构件测试的可重用性:对构件的测试应该是可重用的。 构件使用者面临的测试问题包括: 1 ) 测试充分性判据的可扩展性问题依然存在。 2 ) 构件的测试顺序:如果软件采用分层结构，可以先测试底层构件，因为 不需要其他构件提供服务; 然后再测试高层构件， 所调用到的其它构件都是经过 测试的。如果不是分层结构，可能就难以确定测试的顺序。 3 )冗余测试问题:通常先对构件进行单独测试，然后使用相同的充分性判 据进行集成测试，这就导致有些测试是重复的。 4 ) 源代码是否可用:源代码可用与否导致不同的系统测试方法。 5 ) 编程 语言、 操作系统 平台、 硬件结构的 混杂 性 ( h e t e r o g e n e i t y ) : 系 统使 用的构件可能是用不同语言编写的， 运行在不同的平台上， 这就要求测试方法和 工具与平台和语言无关。 复h 大学硕士学位论文 基于元数据的构件测试技术研究 构件的开发者和使用者很可能不同 ( 尤其对于商业构件来说) ， 这导致了以 下问题: 开发者对构件做的测试可能不充分， 而使用者对此难以确定; 开发者和 使用者使用构件的环境不同， 包括编程语言、 操作系统、 硬件平台的不同; 对于 构件使用者来说， 源代码很可能是未知的。 这些问题是构件软件测试问题与传统 的软件测试问题的最大区别。 国外对构件软件的测试领域己经有一些研究: 1 ) c t b - c o m p o n e n t t e s t b e n c h 1 7 1 首先由构件开发者给出一个测试规约说明， 其中描述了构件的行为、 接口和 相应的测试集，用户可以在实际系统中使用这个规范进行测试。规范是以 x ml 形式提供的，可以不受操作系统的限制。提供了一系列构件测试工具，可以把 x ml 形式的规范转化为c或j a v a执行。 可以以 三种方式生成测试，手工的、计算机辅助的和自 动化的，比 较灵活; 使用x ml语言描述测试规格，可移植性好;支持符号执行，可以通过符号执行 得到测试输出而无需实际运行测试; 缺点是符号执行速度慢。 2 ) u m l b a s e d t e s t m o d e l f o r c o m p o n e n t i n t e g r a ti o n t e s t i n g 8 1 运用u ml时序图和协作图得到系统中接口 相互作用产生的错误， 这种方法 把基于u ml的开发过程与测试过程结合起来。 首先根据时序图得到正常和非正 常事件流， 通过协作图得到并发事件的事件流， 然后根据构件的信息传递模式把 时 序图 和协作图划分为a s f ( a u t o m a ti c s y s t e m f u n c t i o n ) 单元， 据此得到完整 的 测试模型， 然后根据a ll - e d g e 选择判据选择测试用例。 这种方法假设每个构件都经过了充分的单元测试， 不再包含错误， 因此把它 们看作黑箱。 测试用例的选择判据还有待探讨， 以 保证测试的充分性。 有可能实 现自 动化测试，但目 前还没有做到。 3 ) c o m p o n e n t i n t e r a c t o i n t e s ti n g ( c i t ) 9 1 首先建立构件相互作用的形式化数学模型，建立每个构件的形式化测试需 求，用来描述构件相互作用可能的顺序，这个模型也可以处理并发和同步通讯; 然后由测试需求生成单元测试用例， 进行单元测试; 之后选择构件进行集成; 生 成复合测试需求， 进而生成集成测试用例: 不断集成新的构件， 直到整个系统全 部完成。 这种测试方法考虑了集成的顺序， 所以 可以避免重复测试。 缺点是， 理论上 该模型可以从单元升级到系统，但实际上可能会很复杂，难以处理。 4 ) b u i l t - i n - t e s t s i n c o m p o n e n t s ( b i t ) 1 0 1 其实是一种新的构件规范， 要求构件支持正常模式和维护/ 测试模式。 要求 在构件源代码中增加用于内建测试的成员函数，在维护模式下可以调用该函数: 复旦大学硕士学位论文 基于元数据的构件测试技术研究 在正常模式下该函数是不会激活的。 这种内建测试的思想不局限于构件， 对类和对象也适用， 用处也很广泛， 可 以不局限于测试。但显然这种方法需要源代码。 5 ) r e s t r o s p e c t o r s ( 1 2 1 r e s t r o s p e c t o r s 记录构件的执行历史，以 便测试者可以 利用这些测试信息。 构件中的r e t r 。 类与 a v a b e a n 中的i n t r o s p e c t o r 类相似。 r e t r 。 构件有三种模式一 设计模式、测试模式和运行模式。即使没有源代码，r e t r o构件测试者也可以使 用源码覆盖分析的方法。 但由 于不是构件的标准， 构件提供者不一定提供这项功 9 g 0 b ) c o m p o n e n t s o ft w a r e fl o w g r a p h ( c b s f g ) 1 3 1 首先把从软件需求和源代码中得到的信息( 如数据流和控制流) 进行可视化 处理， 生 成fl o w g r a p h ， 然后借助结 构测 试技术生成 测试用 例。 使用c o m p o n e n t s t a t e m a c h i n e 强调了 构件的 特征。 第一步把变换t = ( s o u r c e , t a r g e t , e v e n t , g u a r d , a c t i o n ) 转化为嵌套的i f - t h e n - e l s e 结构， 并把具有相同e v e n t 的结合到一起;然 后据此构造控制流图， 并与从构件源代码构造的数据流图相结合: 第二步把所有 的子图用控制流边和数据流边连接起来。 产生测试用例的第一步是把变量的定义 和使用联系起来，然后用a l l u s e 判据产生测试用例进行定义一使用对覆盖。 该方法的本质是使用数据流和控制流方法， 加了一个全定义判据。 但没有给 出实例研究，不知道实际效果。 7 ) t d s 1 4 1 第一步确定构件的接口; 第二步， 确定接口中提供的方法和异常处理， 哪些 是必须进行覆盖的; 第三步， 确定这些方法和异常处理函数的参数， 用突变算子 对其进行处理: 第四步， 根据构件需求创建测试集， 然后运行测试; 第五步， 去 除测试中发现的错误;第六步，扩充测试集达到1 0 0 %的接口覆盖率。 这个方法的特点是提出了构件软件测试的充分性条件， 并由此生成、 检验测 试用例; 但提出的测试充分性条件还需要与传统的测试充分性条件进行比较， 例 如对比 不同的方法，看谁能更有效地检测出软件中播种的错误。 8 ) a n a p p r o a c h u s e p r o g r a m s l i c i n g , c o n t r o l - d e p e n d e n c e a n a ly s i s a n d d a t a - fl o w t e s t i n g 1 5 1 首先由 构 件开发者 对构件 进行充 分测 试， 并 提供s u m m a r y i n f o r m a t i o n ; 构 件 使用者 通过得到的s u m m a ry i n f o r m a t i o n 可以 进行有效的系统测试，而不需要得 到构件的源代码。 作者举了三个应用方向， 程序分片、 控制依赖性分析和数据流 测试。 根据构件开发者提供的不同附加信息， 构件使用者可以进行不同领域的分 析。 这种方法的缺点是s u m m a r y in f o r m a t i o n 并不属于 任何现有构件规范的 标准， 复旦大学硕士学位论文 纂于元数据的构件测试技术研究 要得到构件提供者的支持难度比较大。 1 . 3 本文的实现目标和解决的主要问题 构件软件测试是以传统的结构化程序测试技术和面向对象的测试技术为基 础， 充分考虑构件本身的 特点， 对传统的测试技术和面向 对象测试技术加以改进 和综合。 构件软件测试根据构件软件的生命周期可以分为构件单元测试、 构件交 互测试和构件回归测试。 本文将分析构件测试在上述的三个测试步骤中存在的问 题，利用构件开发者提供的元数据，提出相应的解决办法。 1 . 3 . 1 构件的单元测试 ( 构件测试) 在构件单元测试中，测试目 标不再是传统的子程序 ( 如过程、模块等) ，也 不是包装了包装了属性和操作的类和对象， 而是近乎独立的、 可替换的、 满足一 定功能的构件。 构件单元测试可以从构件开发者和构件使用者两个不同的角度进 行测试。 ( a ) 构件的开发者认为构件相对于使用构件的 环境是独立的， 所以 要用与上 下文独立的方式测试构件所有的功能。目 前开发的构件主要由面向对象的类组 成， 因此构件测试可基于类的测试进行。 构件测试主要包括构件中包括的类的内 部测试和构件内部类之间的集成测试。 在类的内部测试中， 基于状态和数据流的 测试技术被广泛采用。 但是， 基于状态的测试仅仅涉及与被测对象行为相关的那 些变量， 而那些没有定义对象状态的变量是不会被检测的。 这导致利用基于状态 的测试无法检测那些变量是否出现错误。 数据流测试技术使用数据流测试标准为 被测类产生测试用例， 但这是一项难度非常高的任务。 另外， 有些产生的测试用 例是不可行的， 无法用来进行测试。 为了避免计算任何不可行的数据流测试用例， 本文提出一种基于规约消息序列来选择测试用例的方法。 这些消息序列是由 类转 换图中描述的可行的路径转换而来。 由 于在序列中可能会存在数据流异常， 而数 据流异常可能会丢弃一些定义一 使用对， 所有可能导致一些测试用例无法被选择。 因此， 本文首先检测数据流异常， 然后再进行数据流测试用例的计算。 类之间的 测试主要关注如何确定被测类的集成顺序。 本文提出通过破除对象关系图中的环 路来确定类之间的测试顺序， 该算法对【 2 9 】 和【 3 2 】 中 提出的算法进行了改进， 使得有效产生测试顺序的同时， 使产生的桩模块数目 明显减少而且桩的构造更为 简单。 ( b ) 构件使用者并不关心构 件的内 部实 现， 而只 会关心1 ) 该构件是否 是可 靠 的: 2 ) 应用程序是否能接受该构件， 即构件的功能是否和系统需求相吻合。 因此， 复旦大学硕士学位论文 基于元数据的构件测试技术研究 本 文 提出了 一 个 构 件测 试过 程c t p ( c o m p o n e n t t e s t p ro c e s s ) 以 及c t p 的 一 个 实现框架。 该过程旨 在通过对构件进行黑盒测试、 缺陷注入的方式来确定构件是 否符合构件使用者的需要。 1 . 3 . 2 构件交互测试 当通过构件组装来开发应用程序时， 开发者关注的主要是这些构件组合起来 是否可以产生预期的结果。 而对于测试人员来说， 主要目 标是检测构件之间交互 的潜在错误， 同时应该尽量避免冗余测试。目 前的研究主要是采用传统的测试技 术，主要有:a )采用传统的数据流测试;b )突变测试;c )基于图形表示的测 试。 但是直到现在， 这些测试技术都无法很好地对构件交互进行测试。 为此， 本 文提出了一个测试模型对构件交互进行错误检测。 该模型包括两方面: 一个是静 态分析; 一个是动态监测。 静态分析主要是开发构件交互图， 该图捕获了 构件之 间的 直接和间接的交互。 直接交互包括消息控制流和接口 之间的数据流， 而间 接 交互可以由接口间的数据依赖和事件间的上下文依赖获得。 动态监测可以对运行 时的分布式事件进行控制，并可以捕获动态对象的行为。 1 . 3 . 3 构件回归测试 回归测试是软件维护阶段重要的测试活动， 回归测试同软件开发过程中的测 试最大的不同点就在于回归测试可以重用软件开发过程中的测试用例， 从而可以 节约测试的成本。 然而重新利用以前的全部测试用例对更改后的程序进行完全的 测试， 不仅要耗费大量的时间而且也无这种必要。 因此， 我们必须在这些测试用 例集合中按照一定的策略选择一部分测试用例， 以覆盖程序中被更改及受到这种 更改影响的部分， 构造用于回归测试的测试用例集合， 这就是回归测试选择技术。 在基于构件的软件开发 ( c b s e )中，构件经常进行升级，因此构件的回归 测试问题更为突出。本文通过构件开发者提供的元数据来进行回归测试。首先， 本文通过构件开发者提供的关于构件的版本元数据对测试用例进行选择， 然后利 用构件开发者提供的关于构件的边的覆盖元数据，结合第一步产生的测试用例， 进一步缩小测试用例的集合。 复旦大学硕士学位论文基于元数据的构件测试技术研究 第二章 构件元数据及其表示 通常， 构件开发者提供给构件使用