（计算机应用技术专业论文）面向遗留系统的软件构件化测试方法.pdf

浙江大学硕一j ：学位论文摘要 摘要 在金融领域，软件系统的集成测试通常会涉及到多个遗留系统间的交互，并 且单个系统的业务逻辑不会频繁变动。如何在黑盒或灰盒的状态下对多个跨平台 跨组织的系统进行有效测试是金融领域软件自动化集成测试的一个待解决的问 题。现有的对软件自动化测试的研究更多地着眼于自动化测试的技术实现，并不 能很好地解答这一问题。 针对金融领域遗留软件测试的特点，本文对现有的构件化软件测试方法进行 了定制和优化，以此为基础提出了面向遗留系统的软件构件化测试方法。本文对 现有的软件构件模型进行了改造并创建了专用于软件集成测试的全新的构件版 型一测试构件。本文还就测试构件的设计理念，测试构件的管理方法进行了说明， 并对构件化测试的项目流程和组织结构进行了详细的阐述。 基于构件化测试的基本原理我们还实现了一个自动化测试框架。该框架定义 了以关键字驱动为基础的简洁的脚本语言，实现了测试脚本的解析和测试构件的 动态装载，并提供了较为强大的出错处理和测试报告功能。结合该自动化测试框 架，构件化测试方法已在7 个项目中进行应用，实际的统计数据表明该方法在遗 留系统集成测试上具有较大的价值。 本文的创新点在于将“构件化软件”的思想引入到软件自动化测试中来，提 出了面向遗留系统的软件构件化测试方法，从构件模型，项目流程和技术实现三 方面给出了综合的软件自动化测试方案，提高软件测试资产复用率，缩短软件测 试周期，降低软件自动化测试项目成本。 关键词：软件构件，软件复用，软件自动化测试 a b s t r a c t i nf i n 锄c i a ls y s t e m ，s o f t w a r ei n t e g r a t i o n t e s t u s u a l l yi n v o l v e s i n t e 僦t 1 0 na m o n g m u l t i p l ei e g a c ys y s t e m s ，a n d t h eb u s i n e s sl o g i ce a c hs i n g l es y s t e mw i l ln o t b e 行e q u e n t c h a n g e d h o wt ot e s tf i n a n c i a ll e g a c ys y s t e ma u t o m a t i c a l l y s u n 0 u n dw i t hb l a c k - b o x0 r 邸a yb o x 锄v i r o n m e n t i sa l lu n r e s o l v e dp r o b l e m e x i s t i n gr e s e a r c h e s 0 nt e s t a u t o m a t i o nw h i c hm a i n l yf o c u so ni m p l e m e n t a t i o nf r o mt e c h n o l o g yp e r s p e c t i v e ，c a n n o tp r o p e r l ya n s w e rt h i sq u e s t i o n 。 t h i sa r t i c i eo p t i m i z e se x i s t i n gc o m p o n e n t - b a s e d t e s t i n gm e t h o d o l o g y 8 n d p r o p o s c san e wt e s t i n gm e t h o d f o rl e g a c ys y s t e m b a s e d0 1 1 似1 s t i n gs o 姗a r e c o m p o n e n tm o d e l ，an e ws t e r e o t y p en a m e da s t e s tc o m p o n e n t i sc r c a t e dw h l c h 1 s d e d i c a t e dt os o 咖a r et e s t i n g t h i s a r t i c l ea l s od i s c u s s e sd e s i g nc o n c e p t o ft e s t c o m p o n 邮，c o m p o n c n tm a n a g e m e n t , t e s t i n gp r o c e s s e sa n do r g a n i z a t i o n a ls 劬c t u r e o t t e s ta u t o m a t i o np r o j e c t w ch a v ei m p l e m e n t e da na u t o m a t e dt e s t i n gf r a m e w o r k f o rs o 肌a r ec o m p o n e n t t c s t i n g t h i sf m m e w o r kd e f i n e s ak e y w o r d - d r i v e nb a s e ds c r i p t i n gl a n g u a g e a n d i m p l e m e n t sm e c h a n i s mf o rc o m p o n e n td y n a m i cl o a d i n g ，a l s o p r o v i d e s b u s te 丌0 r h a n d l i n ga n dt e s tl i e p o r t i n gf u n c t i o n a l i t i e s t h ep r o p o s e dc o m p o n e n t - b a s e d t e s tm e t h o d h a sb c e n 叩p l i e di n t o7 a c t u a lp r o j e c t s s t a t i s t i cd a t ao ft h e s ep r o j e c t sp r o v e s t h ev a l u e o fu s i n gt h i sm e t h o di nl e g a c ys y s t e m si n t e g r a t i o nt e s t i n g t h ei n n o v a t i o no ft h i sp a p e ri st h a ti n t r o d u c i n g t h ec o n c e p to f ”c o m p o n e n t - b a s e d s o 日：w a r e ”i n t ot h es o f t w a r et e s ta u t o m a t i o na n dp r o p o s e s as o f t w a r ec o m p o n e n tt e s t l n g m e t h o dw h i c h 嘶e n t c d t o l e g a c ys y s t e m t h i s a r t i c l e p r e s e n tc o m p r e h e n s l v e a u t o m a t e dt e s t i n g s o l u t i o n sf r o mt h ec o m p o n e n tm o d e l ，p r o j e c tp m c e s s e s 8 n a t e c h n o l o g ya s p e c t sw h i c hc a ng r e a t l yi m p r o v e r e u s a b i l i t yo f t e s ta s s e t sa n dr e d u c ec o s t o fp r o j e c t s k e y w o r d s ： c o m p o n e n t b a s e ds o f t w a r e ，s o f t w a r er e u s e ，s o f t w a r e t e s ta u t o m a t i o n 浙江大学硕士学位论文图目录 图目录 图2 1 测试构件模型8 图2 2 测试构件接口的作用9 图2 3 测试构件目录管理结构示例17 图2 4 测试引擎基本架构21 图3 1 构件化测试流程图2 6 图3 2 组织结构图2 6 图4 1 测试框架架构图4 5 图4 2 测试用例组织类图4 7 图4 3 测试执行静态类图4 8 图4 4p r e e x e c u t o r 相关类图5l 图5 1u s s c 项目自动化测试示意图5 5 图5 2 测试构件管理目录5 7 图5 3 测试项目资产管理目录5 8 i i i 浙江大学硕士学位论文 表目录 表目录 表2 1 测试构件接口模板10 表3 1 组织内角色定义2 7 表4 1 关键字示例3 5 表4 2 关键字的域说明3 5 表4 3 数据驱动测试示例测试步骤。3 7 表4 4 数据驱动测试示例测试数据3 7 表4 5 函数功能示例测试步骤3 8 表4 6 函数功能示例函数定义3 8 表4 7c o m p o n e n t 项配置说明。4 2 表4 8k e y w o r d l i s t 项配置说明4 2 表4 9 其他测试环境配置项4 4 表5 1 自动化测试项目投资回报分析表6 0 i v 浙江大学研究生学位论文独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的 研究成果。除了文中特别加以标注和致谢的地方外，论文中不包含其他人已经发 表或撰写过的研究成果，也不包含为获得逝婆盘堂或其他教育机构的学位或 证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文 中作了明确的说明并表示谢意。 学位论文作者签名：签字日期：年月日 学位论文版权使用授权书 本学位论文作者完全了解逝姿盘茔有权保留并向国家有关部门或机构 送交本论文的复印件和磁盘，允许论文被查阅和借阅。本人授权逝、江盘堂可 以将学位论文的全部或部分内容编入有关数据库进行检索和传播，可以采用影 印、缩印或扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后适用本授权书) 学位论文作者签名： 导师签名： 签字日期：年月 1 3 签字日期：年月日 浙江大学本科毕业论文第1 章绪论 第1 章绪论 1 1 软件自动化测试现状 软件自动化测试在过去的2 0 年中已经有了很大的发展。大批的自动化测试 工具的出现使得软件测试的效率大大提高。软件自动化测试框架的出现标志着 软件自动化测试从零散的工具层面的开发工作转变成了在软件架构层面的整体 规划，这是技术层面的一个飞跃【1 】o 软件自动化测试框架大大减少了自动化测试 代码的实现和维护的成本，使测试人员可以把精力集中在应用程序的测试用例 设计上，而不是开发测试代码上。 所谓自动化测试框架，是由一些假设、概念和为自动化测试提供支持的实 践组成的集合。自动化测试框架和应用软件开发的框架有很多类似的地方也很 强调模块化和分层的概念。通过抽象出不同的层来降低耦合，增加聚合：提高脚 本开发效率，方便维护，增强稳定性。传统的结构化线形脚本已经无法满足上面 的要求新一代的自动化测试框架提出无疑为自动化测试提供了解决问题的手 段。国内外现有5 种基本的软件测试自动化框架：模块化测试框架，测试库框 架，数据驱动测试框架，关键字驱动测试框架和混合测试自动化框架。除去混 合测试自动化框架不说，前面四种测试框架各有特点，并具有较明显的前后继 承关系1 2 】。 模块化测试脚本框架( t e s tm o d u l a r i t yf r a m e w o r k ) 需要创建小而独立的可 以描述的模块、片断以及待测应用程序的脚本来测试被测试应用程序。但是一 个众所周知的事实是，测试脚本的维护性比较差，测试脚本的可读性也不直观， 对于缺乏很强技术背景的测试人员来说这不是一种用户友好的技术。 测试库框架( t e s tl i b r a r ya r c h i t e c t u r e ) 与模块化测试脚本框架很类似，不同 的是测试库框架把待测应用程序分解为过程和函数而不是脚本【2 l 。这就大大提高 了测试代码的可维护性和易读性。但是这种测试框架对于测试人员的友好度还 是有待提高。因为用函数来组织测试代码对于编程人员的设计分析能力依赖性 浙江大学本科毕业论文第l 章绪论 很大。假如一个程序员对测试代码进行了“不优雅”的函数划分，那么程序的 可读性和可维护性就不能得到很好的保证。 如果说前两种测试框架还更多地从测试脚本维护这个偏向于编程的角度来 提出解决方案的话，那么数据驱动的测试框架则真正从软件测试本身的特性来 提出解决方案【3 1 。在软件测试中，通常推荐将测试步骤合并成测试用例，将不同 的测斌数据整合成测试数据文件与测试用例一一对应。通常来说一个测试用例 会有多组测试数据与之对应。如果考虑到边界值分析和路径覆盖的话，测试数 据的组数将更为庞大。根据软件测试的这一天然特性，数据驱动的测试框架提 供了测试用例与测试数据的映射功能将两者对应起来从而增强了测试代码的维 护性。另一方面，一个测试用例对应多组测试数据的方法大大减少了测试脚本 的数量【4 】。 数据驱动的测试框架的一个核心思想就是将软件测试过程中不变的测试步 骤抽取出来，将变动的测试数据单独组织管理。以变动的测试数据作为触发条 件来驱动测试用例的执行。在这一思想的基础上，关键字驱动的测试框架有了 进一步的改进。通常来说应用软件都是基于一定的业务需要而存在的，我们的 测试用例也是基于业务需求来编写的。那么无论底层的代码实现怎么改变，只 要上层的业务需求，业务逻辑没有改变，那么相应的测试用例的变动也会很小。 所以说在软件测试中不变的不是测试步骤的实现而是测试步骤的业务逻辑意义 【5 1 。关键字驱动的测试框架将这些逻辑意义抽取出来按照一定的规则组织成“关 键字”。这些关键字代表的就是一个特定的原子的业务逻辑，并且有一套或多套 的具体代码实现与之对应。可以看到关键字驱动的一大好处就是充分实现了测 试业务逻辑和具体代码实现的分离。只要业务逻辑不变，代码实现的改变不会 影响现有的测试用例。另外测试人员完全可以根据业务需要自由组合“关键字”， 而不必关心底层实现的细节。 1 2 本文研究内容和相关工作 经过研究和比较我们发现，现有的测试框架对于代码级别的单元测试，接 2 浙江大学本科毕业论文第1 章绪论 口测试以及用户级别的界面测试等有较好的支持。但是对于软件集成测试，特 别是多个系统间的集成测试来说还没有很完善的解决方案。另外现有的自动化 测试框架更多地是从技术实现的角度上对软件测试提供支持。但是软件自动化 测试作为软件工程的一个子课题，除了需要技术实现上的支持外还需要有合适 的项目流程的支持。如何将先进的技术与适当的流程进行有机结合并应用在测 试项目中是软件自动化测试要解决的问题。 在金融行业中，完成一个业务流程需要多个系统间的交互和协作，甚至涉 及到公司内部和公司外部系统问的交互。同时金融行业的软件项目对时间的敏 感性极高，时间就是金钱，任何项目进度上的延迟对金融业务的影响都是不可 估量的。此外金融领域软件系统的一个很大的特征就是金融软件有很大一部分 是遗留软件，许多现有的先进测试方法和手段都不能直接应用在上面。综合起 来我们可以将金融行业的软件测试的现实问题归纳为：如何在黑盒或灰盒的状 态下在极其有限的时间内对多个跨平台跨组织的系统进行有效地测试。 本课题就是针对上述提出的问题开展研究的。金融行业是一个发展成熟的 行业。它有极为成熟的行业规范和流程定义，因此金融行业的业务逻辑是极为 公开明晰的，也极为稳定。从领域工程的角度来看，领域越稳定越有利于公共 数据的提取。针对这一特点我们尝试将基于构件的软件工程的概念和方法引入 到自动化测试中。并对主流的基于构件的测试方法进行改造。以此为基础，本 文将给出一套切实可行的解决方案。该方案在理论层面给出系统化的测试策略， 通过定义描述整体策略和规程的计划来避免测试的偶然性带来的时间和工作量 的浪费，并且紧密结合项目的实际情况对不同平台间被测试软件的协作整合提 供很好支持。同时该方案也兼顾了对软件测试覆盖率、测试用例开发效率、质 量、可靠性、测试可移植性等方多方面需求的支持。 其次本文将进一步给出相应的自动化测试项目流程规约。从功能、业务、 组织、产出、人员等方面针对系统间的集成测试自动化提出流程上的改进。为 解决方案提供组织流程上的有力保证。 最后本文在技术层面构建一个自动化测试框架来有效支持具体测试用例的 3 浙江大学本科毕业论文 第1 章绪论 管理和执行。将自动化测试的规范、测试脚本的基础代码，以及测试用例进行 技术上的整合从而达到减少冗余测试代码、提高测试代码生产率、提高测试代 码重用性和可维护性的目的。本文将对自动化测试框架的某些重用模块的设计 进行深入剖析。 1 3 论文结构 全文共分六章。第二章将对软件构件化测试在方法论层面进行总体的介绍。 首先从概念上阐述其与基于构件的软件工程方法的异同。然后从构件模型，核 心理念和体系结构三方面做一个完整的论述。 第三章将对软件构件化测试的项目流程进行介绍。主要从项目的组织结构 和各阶段任务的说明两个方面阐述软件构件化测试方法在项目流程角度的特 点。 第四章将对支持软件构件化测试方法的自动化测试框架在技术实现层面进 行深入介绍。分别对测试脚本语言的设计，构件的编程接口及规约信息，以及 测试引擎内部的功能优化进行阐述。 第五章将把构件化测试方法应用到实际的测试项目中去。我们将介绍该方 法在u s c 项目中的具体应用情况。并在最后对应用该方法的各个项目从投资回 报的角度给出统计数据作出总结。 第六章将对论文研究工作进行总结然后对未来的研究工作进行展望。 4 浙江大学硕1 ：学位论文第2 章软件构件化测试方法 第2 章软件构件化测试方法 2 1 软件构件化测试主要概念 基于构件的软件开发( c o m p o n e n t b a s e ds o f t w a r ed e v e l o p m e n t , c b s d ，有时 也称为基于构件的软件工程c b s e ) 是一种基于分布对象技术、强调通过可复用 构件设计与构造软件系统的软件复用途径。基于构件的软件系统中的构件可以是 c o t s ( c o m m e r c i a l 0 昏t h e s h e l f ) 构件，也可以是通过其它途径获得的构件( 如 自行开发) 。c b s d 体现了“购买而不是重新构造”的哲学，将软件开发的重点从程 序编写转移到了基于已有构件的组装，以更快地构造系统，减轻用来支持和升级 大型系统所需要的维护负担，从而降低软件开发的成本。相应的基于构件的软 件系统所需的测试成本也大幅降低。这是因为在构件化软件中，系统的功能都被 彼此独立的构件所实现。并且系统功能的说明能够直接对应到构件的规约。这就 大大提高了对构件化软件进行功能测试的可重用性。 但是对于那些并不是基于构件开发的系统来说构件化软件测试所具有的种 种优点都是这些类型的测试项目所不具备的。如何对构件化软件测试的方法进行 改造并应用到这些类型测试项目中从而提高这类项目的测试重用性就是本文所 要解决的问题。 本文所论述的软件构件化测试就是借用软件构件模型的相关方法对遗留软 件系统进行业务逻辑的归类划分，从而搭建出针对遗留系统集成测试的构件化模 型，然后根据该模型实现相应的“构件 来进行自动化测试。 和基于构件的软件工程( c b s e ) 一样，本文提出的软件构件化测试方法也 是借用了系统建模的手段将软件需求或者说业务逻辑从自然语言描述转化为标 准的模型语言，例如u m l 6 1 ，d s l l 7 等。从而为统一的需求管理，沟通以及后续 的开发测试等打下基础。另一方面c b s d 的目的是为了最大限度地重用软件产品 从而缩短软件开发周期，减少开销。而构件化测试也是为了更大限度地重用自动 化测试代码和数据，缩短软件测试的周期【引。 5 浙江大学硕士学位论文第2 章软件构件化测试方法 从另一方面看，本文的构件化测试与现有的基于构件的软件工程中的测试有 明显的差别。主要体现在以下几方面： 基于构件的软件工程是从无到有生产软件产品的过程，相应的在c b s e 中的 软件测试都是针对现成软件构件进行的。而本文的构件化测试则是通过调用被测 系统的接口来开发一个专门为软件测试服务的“构件。该构件并不能够与其他 真正意义上的构件集成在一个应用系统中，而只是一个测试用的驱动或者说被测 系统的测试代理。为了避免概念上的混淆，我们使用“测试构件”一词代指本文 所提出的构件化测试方法中的“构件”概念。 基于构件的软件工程中需求直接来自于客户。构件模型直接从业务需求而 来。而本文的构件化测试方法的需求则根据测试任务确定。如果测试任务是进行 模块集成测试，那么需求即来自于软件设计文档。如果测试任务是进行功能测试， 那么需求则大部分来源于客户。 基于构件的软件工程对业务需求进行全方位的建模。模型的粒度大到业务规 则的步骤和约束，小到代码实现层面的类图，时序图等。但是本文的构件化测试 根据测试任务的不同只需要对系统在一定粒度一定维度上进行建模即可。 总的来说构件化测试模型是对测试任务确定的问题空间和解空间的抽象。是 对被测系统特征的描述。实现构件化测试代码和测试用例的复用的第一个关键因 素就是对构件的本质特征及构件间关系有清晰的认识。而这正是构件模型的研究 内容。系统化构件的复用包括构件开发，管理和重用三个方面【9 】。 在构件化测试方法中，( 测试) 构件开发的目的是提供测试人员被测系统响 应的模块代码。为了使测试构件能够重用必须确保测试构件的使用者即测试人员 能够对构件功能有清晰的了解。所以测试开发人员不仅需要实现相应的功能，还 要对功能进行规约。此外，为了确保测试构件的相对独立性，不仅要对相应的测 试构件模型进行规约，还要对测试构件的运行环境上下文关系进行规约，从而确 保测试构件开发者和使用者间信息的一致性。 对测试构件的有效管理是测试重用的重要保障。开发出的大量构件需要以一 定的形式和索引结构进行存储，以便于测试人员对构件的选择。测试构件的管理 6 浙江大学硕十学位论文第2 章软件构件化测试方法 重点是构件的功能信息。为了更好地对测试构件的选择提供帮助，测试构件管理 机制还需要从不同侧面对测试构件进行描述。如测试构件的版本，对应被测系统 的版本，开发人员等。标准化的测试构件管理能够更好地促进不同团队间对测试 构件的沟通和使用。 构件化测试的最终目标是通过测试构件和对应测试脚本，测试数据的重用， 来实现快速的软件自动化测试。从横向角度看，在本方法中软件自动化测试的项 目总体由三部分组成，即测试构件，测试用例，测试数据。从自项至下的角度看 着三部分都可以再分层，精化。整个被测系统可以再细化划分成更小的子系统。 对应于每个子系统都会有特定的测试构件实现。当被测系统的某个子系统功能被 更新时对应的测试构件也会进行版本的升级。从而实现测试构件的重用。事实上 在这里可以看到测试构件只是对应被测系统功能的一个代理。它实现向被测系统 的功能请求转发。 2 2 测试构件模型 首先我们对测试构件做出如下的定义。 定义：测试构件是一个独立发布的对应于一个实际系统模块的测试功能代 理，可以通过它的接口来访问对应系统模块的部分服务( 图2 1 是测试构件模型 示意图) 。 根据这个定义，我们强调了测试构件的三个重要方面：第一，测试构件是一 个可交付的软件单元。但是这个软件单元不是独立存在的，而是以被测系统代理 的身份存在。第二，测试构件会提供部分的功能，这些功能集合到一起能够满足 对被测系统进行测试的全部需要。第三，测试构件通过接口来对外提供测试服务。 7 浙江大学硕士学位论文第2 章软件构件化测试方法 厂 虚拟测试构件、 害虚拟测试构件实体匡 被测系统( s u t ) 测试构件规约 薹 2 2 1 测试构件的接口 图2 1 测试构件模型 接口 测试构件必须有一套关于它所代理的被测系统的测试功能集合的抽象描述， 以作为测试构件开发方与测试方之间的契约，这就是测试构件的接口。它的完整 定义如下： 测试构件接口是测试构件之间的契约。一个接口提供对应于一种被测系统功 能或状态的测试服务。接口由两部分组成：一是名字，即提供的测试服务的描述。 二是代理行为，即对应的被测试系统在收到该接口调用请求后的系统行为 1 0 l 。一 个测试构件可以有多个的接口。一个测试构件接口可以由多个测试构件来代理实 现。允许存在尚未实现的接口。 在软件的集成测试，系统测试中，大量的测试用例都是根据业务逻辑设计的。 这些测试用例足完全独立于具体技术实现手段的。在这样的测试场景中，测试构 件更多地就表现为对独立业务单位的封装和代理，而此时的测试构件接口就直接 映射到了某个具体的业务逻辑元或步骤。在现实世界中我们可能会针对同样的业 务逻辑采用不同的技术手段开发出不同的软件系统。但是在系统黑盒测试层面针 对这些系统的测试用例测试数据等从理论上说是完全相同的。在这种情况下构件 接口的存在无疑为重用测试用例测试数据等提供了便利。我们完全可以针对相同 的业务逻辑定义统一的测试接口。在测试用例，或者测试代码中只需要调用相关 的测试接口。而针对不同具体系统的代理功能实现则可以由不同的测试构件来实 g 浙江大学硕士学位论文第2 章软件构件化测试方法 现。因此，将测试构件的接口和构件本身分开是构件化测试的基本要求，也是不 同测试构件装配，替换，组合的基础。 由于测试构件是对构件接口的实现，从逻辑上来说，测试构件所代理的被测 系统的部分功能和内部状态是可见的。但是被测系统未通过测试构件接口所暴露 的部分则是外部不可见的。这种适度的开放性就是为了加强对被测系统本身的保 护。 不同的测试构件之间可以相互协作，这种协作是通过测试构件接口进行的。 测试代码或脚本扮演了胶水的角色将不同构件进行粘合。但是这种粘合只是针对 接口的粘合。具体的构件实现则与之相分离。 从图2 2 中我们可以看到，测试人员关注的足构件接口定义，通过调用正确 的接口来描述特定的测试用例。而构件开发人员则根据构件接口的描述针对不同 的系统实现开发特定的测试构件。正是接口的存在使两方实现了各自独立。 压瓦困 r = l - - - - - - - - - - - - - - - 一 陋蓝团 r 1 i j 2 2 2 测试构件的规约 图2 2 测试构件接口的作用 将构件行为以一种明确的方式表述出来很重要，但应如何描述才能确保其含 义的精确性，并且这种描述方法的本身要简单明了以方便构件使用者和开发者的 理解。这种对构件行为的描述就是构件规约【1 1 1 。构件规约结合文本和图形两种形 式。主要包含如下内容： 构件基本信息：作者，构件版本，构件类型，所代理系统版本等 9 浙江大学硕_ 1 ：学位论文第2 章软件构件化测试方法 构件接口信息：接口名称，功能描述，输入参数，返回值等 构件环境信息：配制参数，构件使用场景，依赖软件环境，局限性等 非功能性特征：性能及可用性描述 构件规约包括了接口说明，该接口说仅仅概括地描述了客户如何与构件进行 交互，同时隐藏具体的技术细节。实际上，尽管接口可以从构件规约的角度来说 明。但接口信息可以独立于任何其他进行实现的测试构件而存在。因为接口简洁 而全面度描述了特定环境中代理软件系统的部分行为和职责。也就是处于这种环 境下任何测试构件都必须实现和代理的被测系统的行为和职责。表2 1 定义了测 试构件的接口。 表2 1 测试构件接口模板 规约内容 说明 名称 接口名称 约束约束该操作实施的属性 输入调用该操作所输入的信息 返回( 输出)接口操作返回给调用方的信息 发送接口操作向被测系统发送的请求说明 读取接u 操作读取的外部可见信息 改变接口操作所改变的外部可见信息 规则 接口操作所运用的算法规则 假定针对外部可见状态和输入的最弱前置条件， 该条件必须为真才能保证结果可能为真 结果针对外部可见属性和返回值得最强后置条 件，只有该条件为真才能保证当前接口操作 执行正确 在测试构件模型中，接口规约由1 1 个部分( 子句) 组成，其中最重要的组 成部分是假定字句和结果子句，他们分别代表前置条件和后置条件【1 2 】。前置条件 定义了满足什么为真时才能保证接口对应操作能够被执行。而后置条件则描述了 操作准确执行的结果会使什么为真。当前置条件不满足时调用接口操作可能会引 1 0 浙江大学硕士学位论义 第2 章软件构件化测试方法 起后置条件的不满足。这种情况通常在非法测试用例中出现。 结果子句在实际测试中是由用户通过测试用例的描述传递给测试接口的，测 试构件在完成接口功能的调用后需要根据用户提供的结果子句与实际输出值进 行匹配。如果匹配无误则说明当前的测试步骤是正确的。如果不匹配则说明当前 的测试步骤出现错误。 返回值是构件接口在执行完操作后将被测系统的内部状态以数据集合的形 式的网馈给用户的结果。返网值是一个数据列表，列表的每一个元素都是形如 f i e l d n a m e = v a l u e 的数值对。这些数值对的数目和意义都是接口规约的一部分。 2 2 3 测试构件的种类 测试构件按照复用粒度和关注点的区别分为业务构件和服务构件两类 1 2 】。 业务构件是最大粒度的测试构件，是为代理一个自治业务功能的被测系 统而开发的构件。它通常由业务流程，状态模型，代理功能接口组成。 服务构件是最小粒度的复用构件。服务构件完成某种类型的功能。在测 试代码的开发中配合业务构件完成测试步骤的实现。按照其服务的区间 不同可分为通用功能构件，领域构件和测试平台相关的逻辑控制构件。 业务构件描述并实现了某个相对独立业务功能模块的测试接口。由于它实质 上是被测系统的一个测试代理，所以测试接口描述的是被测系统的功能切面。也 就是说对于测试人员来说，业务构件只是对被测试系统的一个黑盒描述。通常来 说一个良好设计的软件系统都是高内聚低偶合的，因此软件系统本身是对一个问 题空间内的解的描述，具有相对自治的特征。那么与之对应的测试构件也继承了 这种天生的独立性。然而对于那些没有采用面向对象思想设计的系统，特别是遗 留系统来说，在进行子系统功能再划分的时候就需要把握好构件粒度和边界的。 如果一个业务构件能够很好地封装被测系统的测试逻辑，并提供清晰的接口。那 么这个业务构件就真正地实现了业务逻辑的黑盒封装。在涉及到多个系统的集成 测试时，必须以黑盒方式定义业务构件。只有这样才能确保测试构件的重用和替 换。 浙江大学硕= l ：学位论文 第2 章软件构件化测试方法 服务构件是为测试人员提供公用服务的构件。它具有下面的特点： 具有定义清晰的运行时接口 可独立于任何测试环境 运行时的可跟踪和可管理性 分离关注点，即业务相关测试接口与数据通信等底层技术分离 使用户获得更为清晰灵活的构件模型 我们假设一个服务构件是使用面向对象技术构造的，它有特定的设计和实现 模式。服务构件通常由一系列具体的编程语言类组成，也可以构建在任何编程语 言之上。测试人员对于服务构件关心的重点不是技术的复杂性，比如连接数据库 的进程如何管理维护，过渡性边界，并行性等。因此对于服务构件的定义抽象了 独立于技术性之外的事项l 瑚。但是，这类的抽象功能往往必须以某种技术型的基 础设施来支持。这类基础设施就是测试引擎的一部分。更确切地说，测试引擎提 供了部分构件虚拟机的功能。服务构件是为了支持细粒度的构件服用而对构件的 扩展，服务构件按照服务的区间可划分为运算构件，领域构件和控制构件。 运算构件用于对具体业务计算提供通用的支持功能【1 3 】。运算构件的功能实现 类似于一个方法或者一个函数。一般情况下运算构件提供的功能都是测试引擎无 关的独立功能点。但是这类功能点又非常常用，因此被抽离出来以独立的构件维 护。一般来说运算构件提供的功能有，数值计算，逻辑运算，字符串操作，日期 操作，数据类型转换等等。 领域构件是针对不同的技术领域提供基本通用功能的测试构件。这类构件往 往针对特定技术或应用领域的一般性功能点进行封装。它的主要任务就是将原本 需要复杂代码才能完成具体功能转化为更加简单的操作原语，便于测试人员的使 用。但是这样的封装和转化也是有代价的。操作的简化对应的是功能组合灵活性 的下降。领域构件定义的操作都是常用操作，对于特殊的功能需求就无能为力了。 其次，这样的封装对于测试性能的影响足显而易见的，由于测试用例的逻辑独立 性，领域构件在被使用时只能在同一时刻服务于一个测试用例，因此，它所提供 的功能点在性能上就不能做很好的优化处理。在实际应用中，常用的领域构件有 1 2 浙江大学硕1 ：学位论文第2 章软件构件化测试方法 数据库领域构件，u n i x 领域构件，f t p 领域构件，w e b s e r v i c e 领域构件等。以数 据库领域构件为例，该构件提供了对数据库联接的维护，数据的简单读写等功能。 这些操作并不是十分强大的编程接口，但是对于系统测试而言已经足够。 控制构件在概念上与运算构件和领域构件有一定的交集。之所以单独定义控 制构件是因为该类构件的实现会调用到测试引擎的内部编程接口。与测试引擎的 具体实现功能紧密相关。事实上这类构件有别于构件的定义，因为它们不是独立。 但是它们又具备其他的关于构件的定义，也具备接口定义和对应的可替换性。它 们存在的最重要意义是向用户屏蔽了测试引擎内部的编程接口。从而保证了测试 引擎的内部状态不被恶意的更改。所以说控制构件满足部分构件的概念，但又是 测试引擎的一个重要组成部分。在实际应用中控制构件主要提供诸如测试数据倒 入导出，测试过程控制，出错处理等功能。 在编写测试代码时，测试人员通过业务构件来向特定的测试系统输入激励获 得被测试系统的响应数据，然后通过调用运算构件来对业务构件的输入输出作相 应的变换处理从而将测试步骤紧密联结在一起。这样就实现了业务逻辑与测试构 件的整合。另外控制构件的存在使得测试步骤与测试引擎更好地实现了交互。使 测试过程的中间状态能被测试引擎记录和处理，使得测试流程更加可控。 2 3 软件构件化测试的核心理念及规则 与构件化开发相比，软件构件化测试中对测试构件的建模和使用有一些不 同。它基于几条简单的核心理念和一些基本的建模规则。 2 3 1 统一性原则 许多软件工程方法以许多不同的方式在方法的不同部分中表示和操作同一 个给定对象。这些方法都是基于力度级别或开发阶段的具体实现而不是出于概念 本身来来实现的。例如，面向对象的方法中采用不同的方式来处理过程化的抽象。 在开发前期阶段里使用概念、术语和用例技术，而在后期阶段则运用概念、合作、 操作、方法调用等技术。 1 3 浙江大学硕j 二学位论文第2 章软件构件化测试方法 借用k o r b m 的概念，统一性原则要求，在方法的所有部分和在使用该方法的 项目所有阶段都应该用同样的方式来表示和操作同一个基础概念。运用统一性原 则的最重要作用就是任何行为的抽象或状态，无论复杂度和粒度如何都可以表示 成构件【1 2 】。由于测试构件是被测试系统的代理，因此任何测试都在概念上自成一 个系统。或者作为一个大系统的子系统而存在。我们通过测试用例的组织就能将 构件之间的包容组合关系构造成一棵包容树。然后通过测试引擎将它们映射成一 个可执行形式。 统一性原则要求任何的测试构件( 主要是业务构件，因为控制构件和领域构 件更多的是操作原语的集合) 都应以相同的基本方式建模。也就是说构件模型的 性质应由构件属性决定。统一性原则的应用大大简化了测试构件的组合和使用。 2 3 2 局部性原则 在该原则上构件化测试与当前的构件化开发是异曲同工。传统的面向对象方 法提供了一些基本的方式来表示构造块，将他们嵌套在另一个当中来创建更大的 构造快或者系统。但是这种方法更多的是从运行时的角度来划分模块的概念。尽 管模块代码或许具有构件的特性，但是开发时的工件却不是面向构件的并不是以 同样的嵌套关系来组织的。 局部性原则要求，对于系统运行时面向构件的结构，开发时的工件应当能反 映该结构的方式来构造和组织【1 4 1 。这就要求每个开发时工件都应当关注于运行时 单个工件的描述。也就是说不存在全局的模型。每个模型或图都关注与单个工件 的描述，即模型对于工件来说是局部的。这么做的一个显而易见的好处就是在开 发测试构件的过程中组建独立的开发团队变得十分简单。由于每个开发团队只需 要专注于自己负责的测试构件而不必过多地参与到其他构件开发团队的进程中 去。因此对于对于项目的管理就变得十分简单。 考虑局部性原则的另一种方式是根据角色进行建模。角色建模是一种开发类 图的方法，它强调类之间关系的相对性质【1 5 】。角色是一个对象的描述。实际上可 能使用不同的类来满足角色的需求。因此角色建模与多态思想是紧密相关的【l 6 】。 1 4 浙江大学硕- ：学位论文 第2 章软件构件化测试方法 在测试构件建模的过程中我们也应用角色建模的思想来规约构件模型。 2 3 3 简省性原则 就角色建模方法在构件化测试中应用来说，会产生不必要的信息副本。因为 独立的开发工件之间必然会在某种程度上有重叠，并且每个工件都从自身的角度 出发描述特定的信息，所以就存在冗余的危险。因此，我们规定要求每个模型仅 包含传递所需思想所需的最小信息量。 2 3 4 封装性原则 软件工程的一条重要原则是将软件单元做什么的功能描述与它的具体实现 分开。该原则方便了一种分而治之的方法。一个软件单元可以独立于其用户开发。 并且不同版本的软件单元可以相互替换，只要它们都是做同样的事情。这便是封 装性原则的由来。 封装性原则出现在绝大部分的构件模型中。在本文的构件模型中对于测试构 件如何工作有两种描述。借用k o r b a 的概念。我们将其称为实现和实施。实现描 述的是测试构件如何在上下文业务逻辑中工作，是一种内部的私有设计，展现了 构件的结构化架构。而实施则描述了测试构件的相应功能点是如何通过被测试系 统的程序接口实现的，这就需要维护一个从测试构件接口到被测系统接口的映射 关系。测试构件具有最多一个实现，但是可以具有多个实施，因为实现统一业务 需求的可能会有新老两套不同系统。 2 4 软件构件化测试体系结构 2 4 1 测试构件的注册认证 让一个测试构件能够复用则必须提供关于该测试构件的足够信息，让用户可 能确定它是否能够在目标测试环境和测试任务要求下使用。这些信息都将以一定 1 5 浙江大学硕1 二学位论文第2 章软件构件化测试方法 的方式组织和管理，在稍候的章节会有描述。这类信息的个重要组成部分就是 前面所述的构件规约。构件的规约更加侧重于测试构件本身代理的功能说明。但 从另一个方面来看，用户之所以选择一个特定的测试构件还在于他充分地信任该 测试构件的质量。 要确保对测试构件本身的质量进行认证可以从两方面入手。第一，在一个大 的团队或者部门层面的组织中，独立的质量保证团队可以承担起这个工作。该团 队将根据测试构件的规约对测试构件本身进行测试来认证该构件满足了预期的 目标【1 7 1 。第二，测试构件本身的历史用户反馈也是对构件质量的描述。一个测试 构件被使用的项目越多，频度越广，那相应地说明该测试构件本身的质量也更加 令人满意。因此在一个自动化测试项目完成后对测试中发现一b u g 进行汇总分析就 显得特别重要。尤其是对测试构件本身b u g 的纪录将直接作为构件认证信息的一 部分加到相应的构件库中存档。 因此总体的测试构件的认证过程如下，首先在测试构件开发完成后会有独立 的质量保证团队按照测试构件的规约进行测试，看它是否满足预期定义的需求。 如果这轮测试通过该测试构件通过了认证，构件及构件的规约会被加载到构件管 理库中统一管理。然后当使用该测试构件的项目在完成后会对测试构件的质量进 行再度评价。该评价将作为测试构件认证信息的一部分被更新到测试构件管理库 中。也就是说测试构件的认证信息会被不断地更新和修正，以此来保证测试构件 的认证信息能够做到客观公正。 测试构件注册需要准备的信息有构件属性，规约，构件源代码，使用手册， 构件自身等等。 2 4 2 测试构件的管理 在应用构件化测试的过程中，我们需要有一套机制来确保在组织层面上来管 理测试构件资产。维护一个测试构件目录是一种有效手段。测试构件的目录信息 主要有以下作用： 标示可用测试构件及其状态( 计划中，开发中，使用中等) 1 6 浙江大学硕士学位论文第2 章软件构件化测试方法 测试构件的规约 测试构件的用户群 测试构件的重要性 测试构件的安全性。 对测试构件目录的有效管理是很重要的，如果做不到就可能在测试构件之间 出现严重的依赖性和功能重叠，这就偏离了预定的规划可重用测试模块的目标了 【l 剐。 2 4 2 1 测试构件的目录管理结构 测试构件的目录结构在最上层按照构件的种类分成4 个目录。业务构件目录， 运算构件目录，领域构件目录和控制构件目录分别存放对应类型的测试构件。图 2 3 是测试构件目录结构的示意图