（计算机软件与理论专业论文）基于cbd的软件测试方法研究.pdf

基于c b d 的软件测试方法研究 基于c b d 的软件测试方法研究 学科专业：计算机软件与理论 指导老师：张为群教授 研究方向：软件工程 研究生：曹严元( 2 0 0 2 4 9 8 ) 内容摘要 随着软件复用成为现代软件工程的重要目标，人们希望使用更高效的软件 设计和开发方法，降低开发费用，提高生产效率。软件构件技术的蓬勃兴起揭开 了软件开发从作坊式生产向工业化生产转变的序幕。基于构件的软件工程( c b s e ) 或基于构件的开发( c b d ) 是强调使用可复用的软件“构件”来设计和构造基于 计算机的系统，体现了“购买而非建造”的思想，将考虑的重点从编程软件移到 组装软件系统，“实现”已经让位给“集成”作为考虑的焦点。 伴随软件技术的不断发展，开发者和用户对于软件质量提出了更高的要求。 为此，软件开发者试图从技术、管理等各层面控制软件开发过程，提高软件产品 的针对性和可靠性，保证软件对于用户的使用价值。在众多的软件质量保证技术 中，软件测试作为一种传统的、直接的、行之有效的方法在软件质量保证中起到 了决定性的作用。软件应用的迅速推广，各种针对性的测试方法和技术不断出现， 其具体技术已被融入到各种软件开发过程和方法中。 近几十年，继面向对象的设计方法之后，基于构件的软件设计方法正在逐 渐成为新的趋势，不断成熟并大量推广。由于构件的特点，使得基于构件的软件 开发更具优势，但也带来了分析、设计、实现、测试和维护的一系列问题。在此 我们关心测试问题。这种新的软件工程的开发思想和方法给传统的测试技术提出 了新的挑战，需要研究适合于构件开发新特性的测试技术和方法以保证构件组装 软件的质量和可靠性。 本文通过对c b d 方法及特点的研究，从构件生产者和使用者的角度分析构 件本身的测试和构件集成软件的测试，提出了c b d 软件的测试模式。并重点关注 于构件软件的集成测试方面。提出了基于构件软件系统测试的一种方法：首先结 合构件生产者提供的构件规格说明和测试信息以及系统的分析和设计阶段的模 基于c b d 的软件测试方法研究 型和文档，对系统中的构件构架进行建模，得到系统构件的物理依赖关系；然后 定义了构件间依赖关系的相依性元素，通过系统分析和设计阶段的模型文档辅 助，分析提取系统构件间的相依性，并给出构件交互图，为构件软件系统的测试 提供了测试模型。通过构件交互图和前面的分析信息，在构件交互图中寻找测试 路径，为测试用例的选择提供依据。本文还讨论了测试充分性问题，研究了基于 图的测试的覆盖准则，为测试路径选择的充分性提供指导。 本文的测试方法针对构件软件源代码不可见闯题。结合了黑盒测试和白盒 测试，不仅对构件软件的功能进行测试，而且通过相依性分析对其内部结构也可 以进行相应测试，对传统泐试技术进行了有效韵改进和补充，以保证构件软件的 质量和可靠性。 最后本文通过对一个车辆出租公司开发的管理系统的分析测试，体现了文 中的测试方法在具体问题中的实际运用。 关键词：c b d c b s e 基于构件的软件软件测试测试模型 测试充分性测试方法和技术 2 基于c b d 的软件测试方法研究 r e s e a r c hf o rt h ec b d b a s e ds o f t w a r e t e s t i n g m e t h o d m a j o r ：c o m p u t e rs o f t - w a r ea n dt h e o r y s u p e r v i s o r ：p r o f e s s o rw e i q u nz h n n g d i r e c t i o n ：s o f t w a r e e n g i n e e r i n g a u t h o r ：y a n y u a n c a o ( 2 0 0 2 4 9 8 ) a b s t r a c t w i t hs o r w a r er e u s eb e i n gt h ei m p o r t a n ta i mo fs o f t w a r ee n g i n e e r i n g ，p e o p l e w i s ht ou s eh i g h e re f f i c i e n c ys o f t w a r ed e s i g na n dd e v e l o p m e n tm e t h o d s t h e s e m e t h o d sw i l lr e d u c ed e v e l o p m e n te x p e n s e sa n di m p r o v ep r o d u c e e f f i c i e n c y s o c o m p o n e n t - b a s e ds o f t w a r ee n g i n e e r i n g ( c b s e ) o rc o m p o n e n t - b a s e dd e v e l o p m e n t ( c b d ) c o m e sf o m ia n dw i l lb ean e wd i r e c t i o no fs o r w a r ed e v e l o p m e n t , i nl a t e s t d e c a d e st h ec b d d e s i g nm e t h o d sc o n t i n u o u s l yg r o w nu pa n dp o p u l a r i z el a r g e l y c b dm e t h o dh a sm o r ea d v a n t a g e sa sar e s u l to ft h ec o m p o n e n t c h a r a c t e r i s t i c ，b u ti t a l s o b r i n g s as e r i e so fp r o b l e m so fa n a l y z e ，d e v e l o p m e n t , i m p l e m e n t , t e s ta n d m a i n t e n a n c e s o r w a r et e s ti sat r a d i t i o n a l ，d i r e c ta n de f f e c t i v em e t h o di nn u n l e r o u s s o f t w a r eq u a l i t ya s s u f s n c et e c h n o l o g i e s s oh e r ew ec a r et h et e s to fc b ds o f t w a r e t h en e wd e v e l o p m e n ti d e ao fs o 盘w a r c e n g i n e e r i n g a r o s em o r e c h a l l e n g e t o t r a d i t i o n a lt e s t i n gt e c h n o l o g y w en e e dn e wt e s tt e c h n o l o g ya n dm e t h o dt ob ef i tf o r t h ec o m p o n e n tc h a r a c t e r i s t i ca n d g u a r a n t e et h eq u a l i t ya n ds e c u r i t yo f c b d s o f t w a r e t h i sp a p e rr e s e a r c h e st h em e t h o da n df e a t u r eo f c b d ，a n a l y s e st h ec o m p o n e n t t e s ta n dc o m p o n e n t - b a s e ds o f t w a r et e s tf r o mt w op o i n t so fv i e wa st h ep r o v i d e r so f s o r w a r ec o m p o n e n ta n dt h el l s e r so fs o r w a r ec o m p o n e n t t h ep a p e rp r e s e n t st h e t e s t i n gt y p eo f c b d s o r w a r c ，a n da t t e n t i o n st h ei n t e g r a t i o nt e s to fc b ds o f t w a r e w c p r e s e n ta na p p r o a c ht oa n a l y z i n ga n dt e s t i n gc o m p o n e n t - b a s e ds y s t e m s o u rm e t h o d u s e st h es p e c i f i c a t i o na n dt e s ti n f o r m a t i o no fc o m p o n e n tf r o mc o m p o n e n tp r o v i d e r a n dm o d e ld o c u m e n ti n s y s t e m sa n a l y z i n ga n dd e s i g n i n gp h a s et om o d e lt h e c o m p o n e n ta r c h i t e c t u r e ，g e tt h ep h y s i c a ld e p e n d e n c er e l a t i o n s h i p sa m o n gs y s t e m s c o m p o n e n t t h e nw e d e f i n et h ed e p e n d e n c ee l e m e n t s ，a s s i s t a n tt h em o d e ld o c u m e n t i nd e s i g np h a s et op i c k - u pt h e s ed e p e n d e n c ea m o n gc o m p o n e n t w cc o n s t r u c tt h e 基于c b d 的软件两试方法研究 c o m p o n e n t i n t e r a c t i o ng r a p ha st h et e s tm o d e lf o rc o m p o n e n t - b a s es y s t e m s u s et h e c i gw ef i n dt e s tp a t ha n dc o u l dg a i nt h et e s tc a s e b e s i d e s ，t h ep a p e rd i s c u s s e st h e t e s ta d e q u a c y p r o b l e m s w es t u d yt h et e s tc o v e rr u l eb a s e do nt e s tm o d e l i nt h ee n d ，w e a n a l y z i n g a n d t e s t - m g av e h i c l el e n d m a n a g e m e n ts y s t e m t ov e r i f y o u i t e s tm e t h o d k e y w o r d s ：c b d ，c b s e ， c o m p o n e n t - b a s e ds o f t w a r e ， s o r w a r et e s t , t e s tm o d e l ，t e s t a d e q u a c y , t e s t m e t h o da n dt e c h n o l o g y 4 基于c b d 的软件测试方法研究 第一章绪论 自计算机的发明以来，计算机技术蓬勃发展，计算机的应用得到了迅速的 推广。然而，长期以来软件的需求与其开发速度和质量之间的矛盾一直是制约计 算机技术进一步发展的主要因素之一，也就是软件危机。计算机界努力探索和研 究，通过各种手段试图发现软件开发过程中的规律和方法，以提高软件开发的效 率和质量，软件工程这一概念也就应运而生了。在软件工程的研究过程中，人们 试图通过对于软件生命周期、软件开发方法学、软件测试技术等各种涉及软件开 发过程的技术和方法的研究找到提高软件开发质量和降低软件开发和维护成本 的方法。 软件工程的思想和方法提出以后，软件开发者一方面从管理的角度进行研 究，希望实现软件开发过程的工程化，例如大家都熟悉的“瀑布式”生命周期模 型，以及后来提出的快速原型法、螺旋模型、喷泉模型、构件组装模型、并发开 发模型等对“瀑布式”模型的补充。另一方面，开发者侧重于对软件开发过程中 分析、设计方法的研究，例如在7 0 年代风靡一时的结构化开发方法，8 0 年代提 出的面向对象的开发方法以及后来的面向构件的开发方法等都是这种抽象层次 不断提高过程的自然发展结果，实现了更高级的抽象来表达客观世界。除此之外， 开发者还通过在开发过程中使用基于严格数理逻辑的形式化方法以及使用面向 不同软件抽象层次的软件测试策略来保证软件开发的质量。 1 1 软件开发方法的发展 为了克服6 0 年代爆发的软件危机，软件研究者们不断探索和研究软件工程 中薪的软件开发方法。软件开发方法的发展至今经历了以下阶段； 1 、p a r n a s 方法最早的软件开发方法是由d p a r n a s 在1 9 7 2 年提出的。 由于当时软件在可维护性和可靠性方面存在着严重问题，因此p a r n a s 提出的方 法是针对这两个问题的。首先，p a r n a s 提出了信息隐蔽原则：在概要设计时列出 将来可能发生变化的因素，并在模块划分时将这些因素放到个别模块的内部。这 样，在将来由于这些因素变化而需修改软件时，只需修改这些个别的模块，其它 模块不受影响。信息隐蔽技术不仅提高了软件的可维护性，而且也避免了错误的 蔓延，改善了软件的可靠性。现在信息隐蔽原则已成为软件工程学中的一条重要 原则。p a r n a s 提出的第二条原则是在软件设计时应对可能发生的种种意外故障 采取措施。软件是很脆弱的，很可能因为一个微小的错误而引发严重的事故，所 基于c b d 的软件测试方法研究 以必须加强防范。如在分配使用设备前，应该取设备状态字，检查设备是否正常。 此外，模块之间也要加强检查，防止错误蔓延。 p a r n a s 对软件开发提出了深刻的见解。遗憾的是，他没有给出明确的工作 流程。所以这一方法不能独立使用，只能作为其它方法的补充。 2 、y o u r d o n 方法1 9 7 8 年，e y o u r d o n 和l l c o n s t a n t i n e 提出了结构 化方法，即s a s d 方法，也可称为面向功能的软件开发方法或面向数据流的软件 开发方法。1 9 7 9 年t o md e m a r c o 对此方法作了进一步的完善。y o u r d o n 方法是 8 0 年代使用最广泛的软件开发方法。它首先用结构化分析( s a ) 对软件进行需 求分析，然后用结构化设计( s d ) 方法进行总体设计，最后是结构化编程( s p ) 。 这一方法不仅开发步骤明确，s a 、s d 、s p 相辅相成，一气呵成，而且给出了两 类典型的软件结构( 变换型和事务型) ，便于参照，使软件开发的成功率大大提 高，从而深受软件开发人员的青睐。 3 、面向对象的软件开发方法面向对象技术是软件技术的一次革命，在软 件开发史上具有里程碑的意义。随着o o p ( 砸向对象编程) 向o o d ( 面向对象设 计) 和o o a ( 面向对象分析) 的发展，最终形成面向对象的软件开发方法o m t ( o b j e c tm o d e l i n gt e c h n i q u e ) 。这是一种自底向上和自顶向下相结合的方法， 而且它以对象建模为基础，从而不仅考虑了输入、输出数据结构，实际上也包含 了所有对象的数据结构。不仅如此，o o 技术在需求分析、可维护性和可靠性这 三个软件开发的关键环节和质量指标上有了实质性的突破，彻底地解决了在这 些方面存在的严重问题，从而宣告了软件危机末日的来临。 4 、基于构件的开发方法继面向对象的开发方法后，基于构件的开发方 法正逐步成为软件工程开发方法的新趋势。基于构件的开发( c o m p o n e n t b a s e d d e v e l o p m e n t ，简称c b d ) 或基于构件的软件工程( c o m p o n e n t b a s e ds o f t w a r e e n g i n e e r i n g ，简称c b s e ) 是一种软件开发新范型，它是在一定构件模型的支持 下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造 应用软件系统的过程。由于以分布式对象为基础的构件实现技术日趋成熟，c b d 已经成为现今软件复用实践的研究热点，被认为是最具潜力的软件工程发展方向 之一。 c b d 遵循“购买而不创建”的开发哲学，让人们从“一切从头开始”的程序 编制转向软件组装。基于构件的开发任务包括创建、检索和评价、适配、组装、 测试和验证、配置和部署、维护和演进，以及遗产系统的再工程等主要活动，它 们与传统的生命周期中的方法不尽相同。 本论文就是在基于构件的开发方法的基础上，研究针对这种新的开发思想 6 基于c b d 的软件测试方法研究 和方法的相应的测试技术和方法。 当然，在软件开发方法的发展过程中还有其他的一些方法，如面向数据结 构的开发方法、问题分析法p a m 、可视化开发方法、i c a s e 方法等，这里主要介 绍主流的开发方法。 1 2 软件生命周期中测试的重要性 软件测试的重要性及其关于软件质量的隐含是非常重要的。正如d e u t s c h 所说的一样，软件系统的开发包括一系列生产活动，其中由人带来的错误因素非 常多。错误可能出现在程序的最初其中目标可能是错误的或描述不完整，也可 能出现在后期的设计和开发阶段因为人们不能完整无缺地工作和交流，软件开 发过程中必须伴有质量保证活动。软件钡4 试是软件质量保证的关键元素，并代表 了规约、设计和编码的最终评审。 软件作为系统元素的可见性不断增加而且软件故障带来的代价太高。使得 人们注重于规划良好的彻底测试，软件开发组织将3 0 - - 4 0 的项目工作量花 在测试上也并不为怪。另一方面，与人命有关的软件( 如飞行控制和核反应堆监 控) 测试所花的时间往往是其他软件工程活动时间之和的三到五倍。 软件测试也可以看作是系统工程中的一个问题。铡试就是分析被测系统， 判定怎样可能是错误的。我们从系统工程的角度看软件测试如图卜1 所示。 图l - l从系统工程角度看软件酒试 7 基于c b d 的软件测试方法研究 第二章基于构件的软件开发 随着计算机技术的飞速发展，各行各业对软件开发的速度和质量要求都有 了很大提高。然而，传统的“手工作坊”式的软件开发状况得不到根本改变，软 件技术的进步远远落后于硬件技术的进步，值得庆幸的是9 0 年代发展起来的 “基于构件的软件工程”( c b s e ) 有望从根本上解决这一问题，从而成为软件工 程进步中的又一里程碑。 构件和基于构件的方法是电子商务革命的驱动力。是i n t e r n e t 时代开发企 业级解决方案的方法。在最近的一份报告中，g a r t n e r 小组预计，到2 0 0 3 年， 所有软件解决方案中将有7 0 9 6 是使用像预建的构件和模板这样的“积木”来建造 的。同样，在国际数据集团( i d c ) 进行的1 9 9 9 年世界范围市场和趋势的调查中 估计，到2 0 0 3 年在世界范围内构件生产和组装工具的市场将超过8 0 亿美元，同 时在获取构件上还要另外花费2 0 亿美元。显而易见，在以后的几年中，i n t e r n e t 时代的企业级解决方案将在功能和侧重点上发生根本性的变化。 分解技术是软件工程的许多方法的核心。这些方法可以称为结构化设计、 模块化编程或面向对象，它们产生的单元称为模块、包或构件。然而，在每一种 情况下所涉及的主要原则是，把一个大型系统认为是有定义良好的、可复用的功 能单元构成的，能够控制系统的分解，并且保证能够重构成一个完整系统成为可 能。虽然这些概念很好理解，但大多数组织在把这些概念应用于实际时还是很艰 苦的，许多组织也开始重新评价它们的设计、实现和演化软件所使用的方法。因 此，我们应该重新注意面向复用、基于构件的方法，重新定义基于构件的策略， 并用适当的工具和技术支持它。这些新方法统称为基于构件的开发( c b d ) 或基 于构件的软件工程( c b s f , ) 。对于软件系统的开发者和用户来说，c b d 被看作是 一种能够降低开发费用、提高生产率以及在快速的技术演化面前提供受控的系统 升级的开发方式。 2 1 构件 理解c b d 的关键是要深入了解构件意味着什么，以及构件怎样形成一个解 决方案的基本构造块。 对于构件的定义，已有很多的描述。a n d e r sh e j l s b e r g 认为构件是一个自 包含的软件单元，它不仅是代码和数据，还包含提供关于构件如何适应特定宿主 环境，如何持久化的动态附加信息。s z y p e r s k i 和p f i s t e r 指出，构件是一个契 基于c b d 的软件测试方法研究 约上有具体接口，有明确的上下文依赖的组成单元，能够被独立配置且被第三方 支配构造。对于c b d 而言，构件远菲模块化编程方法中的子程序、面向对象方法 中的对象和类、或系统模型中的包。在c b d 中，构件的概念既包含了这些思想又 扩展了它们。构件是设计、实现以及维护基于构件的系统的基础。我们将采用一 个相当广泛、全面的构件定义：构件是一个独立发布的功能部分，可以通过它的 接口访问它的服务。这个定义虽然不是很正式，但它强调了构件的很多重要的方 面： 第一，它将构件定义为一个可交付的单元。因此，它具有可执行软件包的 特征。 第二，它提到构件会提供一些有用的功能，这些功能集合到一起会满足一 些需求。这些功能的设计符合一些设计准则。 第三，构件通过接口提供服务。使用构件，要求通过这些接口来提出请求， 而不是通过访问构件内部实现细节。 另外一种对构件概念的更高层次的分析提出了三个关于什么是构件的观 点，它们能体现出构件的许多有意义的特征： 包装的观点：将构件作为包装、分发、交付的单位。这是统一建模语言( u m l ) 规范所采用的观点。它将构件定义为：系统的一个物理的、可替换的部分， 是对实现的包装，并且提供了对一系列接口的实现。 服务的观点：构件是一系列服务的提供者。这是构件描述模型( c d m ) 所 采用的观点。它将构件定义为：构件是指通过接口提供服务的软件包。 完整性的观点：构件是数据的集成或包装的边界。完整性观点为构件可替 换提供了必要条件。它对构件的定义如下：构件是独立的、可交付的、对 一系列软件操作的包装，这种包装可以用来构造应用程序或更大的构件。 图2 一l 描述了构件的三种观点之间的关系，并且通过引入接口、构件规格说 明以及模型元素充实了这种简单的概念模型。其中每个观点都是建筑在另一个之 上的。 包装 服务 完整性 图2 - 1 三种构件观点 9 基于c b d 的软件测试方法研究 2 1 1 构件的要素 构件和基于构件的方法建立在面向对象概念和分布式系统思想之上，因此 它具有很多系统设计者和工程师所熟悉的特性。然而它也有其自身的很多独特的 特性。图2 - 2 描述了构件具有的要素。 图2 - 2 什么是构件 结合构件的五个要素，我们可以给出构件的形式化定义： 【定义1 】 构件 构件是一个独立发布的功能部分，可以通过它的接口访问它的服务。构件 可以定义为一个五元组： s p c ，i m p ，d e p ，s t a ，p a c ) ，其中s p c 为规格说明， i m p 为构件实现，d e p 表示可被部署，s t a 为构件标准，p a c 表示可被包装。 在构件的五元组定义中： 规格说明。构件要求有一个关于它所提供的服务的抽象描述，以作为服务 的客户方和提供方之间的契约。它不仅仅是简单地定义一系列可用的操 作，还描述了在特殊情况下对构件所期望的行为，约束构件允许的状态， 并且指导客户方与构件进行相应的交互。 一个或多个实现。构件必须被一个或多个实现所支持。这些实现必须符合 规格说明。 受约束的构件标准。软件构件存在于一个定义良好的环境( 或称为构件模 型) 中，必须遵守的一套规则，即构件标准。构件模型解决了一个构件怎 样使用其他构件可以获得它的服务、构件怎样被命名以及怎样在运行时发 1 0 基于c b d 的软件测试方法研究 现新构件和它们的服务等问题。已有的构件模型包括m i c r o s o f t 的c o m + ， s u n 的j a v ab e a n s 和e n t e r p r i s ej a v ab e a n s ( e j b ) ，以及o m g 的c o r b a 构件标准。 包装方法。构件可以按不同的方式分组来提供一套可以替换的服务。这个 分组就称为包。它们代表了必须安装在系统中的功能单元。 部署方法。一旦成品构件安装在一个运行环境中，它们就将被部署。这通 过创建构件的可执行实例并且允许与它发生交互来实现。 2 1 2 构件与对象 基于构件的方法是在面向对象方法的基础上逐渐形成的，然而构件和对象 的概念又有不同。考察对象和构件之间的关系，可以为理解构件方法提供一个很 好的起点。构件和对象的区别主要表现在以下三个方面： 构件担当一个部署单元的作用，它是基于构件模型的，这种模型定义了符 合这种模型的构件所要遵循的规则。 构件提供了对一个或多个对象实现的包装。 构件是一个组装单元，它用于从很多独立创建的功能部分设计和构建系 统，每一个部分都潜在地使用一种o o p l 或某种其他技术创建。 从图2 3 我们可以直观地看出构件和对象之间的关系。构件可以认为是一 种包装对象实现的简便方法。并且可以使它们组装成一个更大的软件系统。如图 所示，构件可以看作是在构件模型的环境中的一个或多个对象的实现。 图2 - 3 构件与对象之间的关系 基于c b d 的软件测试方法研究 2 2 构件化设计 构件化设计方法允许从构件来设计一个解决方案的构架，可以仅考虑构件 的抽象功能，而忽略它们以后的实现特性。以适当的构件构架为目标的设计方法 是构件方法获得成功的关键因素。 图2 4 表示了构件化设计过程中的要素，这些要素包括存储在构件库中的 多种多样的构件，种关注于接口的设计方法，以及基于构件构架的应用程序组 装。 图2 4 构件化设计过程的要素 基于构件的开发方法的基本目的是向以组装方式进行应用程序开发的方向 发展。这种组装是基于那些以独立服务的形式开发出来的构件进行的，这些构件 的服务是通过在某种基础设施上调用某种通用的服务来进行信息的交互的。因 此，基于构件的设计必需具备四种关键要素： 由构件组装的应用程序： 独立的服务提供； 公共的构件基础设施： 标准服务的使用。 基于c b d 的软件铡试方法研究 1 、由构件组装成应用系统 构件的开发以及应用程序的组装过程是由基于构件开发的方法来加以管理 的。这使得构件可以提供一系列独立的服务。构件提供的服务是通过构件规格说 明加以描述的，多种不同的构件实现都遵从这种规格说明。构件之问通过某种构 件的基础设施来进行通信，从而使得构件之间可以相互协作和同步。 基于构件的设计，开发人员要改变他们在构建系统时所采用的思考方式。 传统的软件开发方法基于如规格说明、设计、实现、测试以及部署等阶段，基于 构件的开发方法则关注于解决方案的结构、确认应使用什么样的构件、对已有的 构件进行选择、对构件加以包装和集成以及对最终解决方案的测试和部署等。对 基于构件的设计应符合以下四个原则： 构件的规格说明必须与其设计和实现清晰地分离。这使得构件的行为可以 独立地描述出来，而不需要考虑其具体的实现方法。也使得对同样的规格 说明有可能存在多个不同的可以互相替代的构件。 重点关注于接口的设计方法。基于构件的开发方法的结果必然是通过蘸好 定义的接口访问包装的行为。接口在服务的提供者和消费者之间提供了一 个协议，使得构件之间可以具有更大的独立性。 对构件的语义加以形式化的记录。操作的语义细节要求采用对每个操作设 置前置条件和后置条件的形式化的及可验证的描述。 严格地记录细化过程。规格说明和设计过程的各个阶段都必须被记录，以 便得到构件设计过程的演化记录。每次细化都必须加以验证。 2 、提供独立的服务 在构件化的设计时，还需要确定构件之间的各种交互关系以便提供独立的 服务这种确定是基于对每个构件功能的抽象描述生成的。在基于构件的开发方 法中，用于描述构件是什么的规格说明与构件的实现相分离，这使得构件的规格 说明之间可以相互独立，从而使得使用或替换某个构件时对系统产生的影响是可 以预期的。 3 、通用构件基础设施 独立地说明和建造构件，以及将它们组装成为一个集成的应用程序，这些 要求怎样实现昵? 答案在于需要有一种此应用程序中所有构件所使用的、共享的 构件基础设施。它的责任在于为组装的构件提供所需的协作及信息交流。 在构件基础设施中需要考虑两方面，第一是有一组任何希望使用这种基础 设施的构件都必须接受的协议、标准、约束和责任。这一般称为构件模型。这种 模型引导着构件的开发者和应用程序的组装者对这些构件进行设计、开发和使 基于c b d 的软件测试方法研究 用。第二是存在实现协作和同步的一组机制，使得构件之间可以相互通信。这些 机制使用了一些特定的技术，并与特定的平台相关。构件基础设施的各种机制对 一种或多种构件模型提供支持。特别地，它负责为那些符合它所支持的构件模型 的构件提供它们之间交互所需的底层实现。 4 、使用通用的服务 能够对功能性的片段加以复用，是人们选择使用基于构件的开发方法的重 要原因之一。因此，有必要建立多个可被许多系统复用的构件集合。相对于在每 个应用程序中都独立开发这些服务，在各种不同的应用程序系统之中使用标准化 的公用服务就相当有意义了。根据服务的用途，一般可以定义四种不同类型的通 用服务：领域相关的业务构件、通用业务领域构件、业务基础设施构件、技术基 础设施构件。 2 3 基于构件的开发( c b d ) 和基于构件的软件工程( c b s e ) 最近，人们开始重新关注于通过有计划地集成现有的软件部分来进行软件 开发。这通常称为基于构件的开发、基于构件的软件工程或简单地称为构件体， 而其中的各个部分称为构件。 2 3 1 什么是c b s e c b s e 是指用装配可重用软件组件的方法来构造应用程序。它包含了系统的 分析、构造、测试、维护和扩展的各个方面，在这些方面中都是以组件方法为核 心的。与传统的软件重用方法比较，c b s e 有以下特点： 即插即用。构件可以方便地集成于框架中，不用修改代码，也不用重新编 译。 以接口为核心。构件的接口和实现是分离的，构件通过接口实现与其他构 件的框架的交互，构件的具体实现被封装在内部，组装者只关心接口，不 必知道其实现细节。 标准化。构件的接口必须严格地标准化，这是构件技术成熟的标志之一。 目前主要的构件标准有m i c r o s o f t 的c o m d c o m ，j a v a 的j a v ab e a n s 和 e f b ，o m g 组织的c o r b a 。可以说计算机界很早就有用构件来装配成应用软 件的想法，但始终未能实现，其中的一个主要原因是构件标准的缺乏。正 是由于出现了以上较为成熟的构件标准，才使得c b s e 由梦想走向现实。 构件通过市场销售和分发。大量成熟的构件可以通过市场购得，市场的竞 基于c b d 的软件测试方法研究 争机制也可以保证构件生产的质量的提高、种类的增加和价格的降低。 2 3 2c b s e 的意义 c b s e 从根本上改交了软件生产方式。 福特创造了汽车的流水线制造法。开创了工业化大规模生产的新纪元。福 特制造的精髓就是将汽车生产的重点从制造每一个零件转到装配，汽车制造者不 必自己设计制造每一个零件。大部分零件有外购而来。过去的软件生产方式与旧 的汽车生产方式十分相似，开发者往往要编写程序中的绝大多数代码，因此，如 果能实现像组装汽车和机器一样地进行软件开发，将是软件工程的巨大进步。 c b s e 提高了软件重用率。 生产好的构件可以分发销售给多个其他用户，一方面大大降低单个构件的 成本，另一方面大大降低软件开发中的重复劳动。目前在各家企事业单位中存在 着许多旧的计算机软件系统。可以将这些系统分成模块后通过构件技术封装起 来，成为新系统的组成部分。这种通过标准的接口将旧的程序代码隐藏起来的做 法，巧妙地保护了已有的软件投资。 c b s e 使开发者将更多的注意力放到业务流程和业务规则上去。 由于开发者的主要工作是构造框架和装配构件使他们可以摆脱编程的细 节问题，将更多的精力投入到与用户交流。另外，一切业务管理者也可以在更高 的层次上，用偏近于业务而不是偏近于计算机的语言进行讨论。 c b s e 开发的系统的维护十分方便。 由于c b s e 是模块化开发，如果某个模块需要修改，只需用修改好的模块替 换以前的模块，不用重新编译整个系统。若想扩展系统的功能，也只需将符合框 架的约束条件的接口要求的扩展模块直接加入到该系统即可。由此可见，c b s e 开发的系统的维护和升级都十分方便。 c b s e 降低了对系统开发者的要求。 尽管c b s e 没有消除系统开发者和使用者之间的分界线，但却移动了这条分 界线。这是因为c b s e 的开发者主要任务是装配已有模块，不需要有很高的编程 技巧。从而使更多的人可以构造适用于自己的系统。在开发环境中。仅仅在构造 构件时才需要对编程语言的熟悉和高超的技巧。 基于c b d 的软件测试方法研究 2 3 3c b s e 与传统技术的比较 表2 1 对比了c b s e 与传统软件开发方法的不同。 传统软件开发 c b s e 软件结构紧耦合松耦合，模块化 软件成分，重点在于实现，重点在于接n 组件的特点白盒 黑盒 大爆炸式( b i g b a n g ) 进化式( e v o l m i o n a l ) 的 开发滚程 瀑布式( w a t e r f a l l )并发式 方法学 从小粒度的“软件片”开始构造装配 开发组织开发组 构件制造商，服务代理，构件集成者 表2 - 1c b s e 与传统软件开发的比较 c b s e 与0 0 技术有着密切的关系，因此往往会混淆两者。0 0 技术对于c b s e 既不是必要条佟，也不是充分条件。首先，构 牛不一定要甩o o 语言绽写。任何 一种可以实现构件标准接口和所需功能的语言都可以用来编写构件而且，c b s e 扬弃了0 0 技术的某些特点。多态性和继承性是o o 技术的重要特点。但对象之间 的继承性可能造成系统间的级联影响。c b s e 更重视封装性，它希望程序修改导 致的影响严格限制在构件内部。另外，c b s e 的涵盖面要广于0 0 技术。c b s e 包括 了系统分析。系统的设计和建模，项目组织，构件的开发和管理等各个方面，而 0 0 技术通常只包含o o a ，o o d ，o o p 这3 个方面 c b s e 的开发过程与传统方法的开发过程也有不同，从图2 - 5 中可以看到， c b s e 的开发以构件为核心，而且在需求分析阶段就可以进行构件收集工作，增 加了开发的并行程度，提高了开发效率。 c b s e 图2 - 5传统技术的开发过程与c b s e 的开发过程 1 6 传统技术 基于c b d 的软件铡试方法研究 第三章软件测试技术 随着计算机的普及，软件系统已经深入到生活的各个方面，种类越来越多， 设计和开发的方法也不断发展。人们对软件质量的要求也在不断提高，但现实中 软件系统的质量和稳定性却不尽人意，采用有效的软件测试是保证软件质量、提 高软件可靠性的重要手段。软件测试的概念虽然是和软件编程同时提出的，但发 展速度却远远没有编程技术快。近几十年来，随着软件应用的迅速推广，对软件 测试也变得迫切需要，各种针对性的测试方法和技术不断出现。 3 1 软件测试的基本问题 软件测试是使用为发现错误所选择的输入和状态的组合而执行代码的过 程。在软件工程过程中，测试可以看成( 至少心理上) 摧毁性的而不是建设性的。 测试要求开发者放弃刚开发的软件是正确的观念，创建测试案例试图“摧毁”已 经建立的软件。对于一个应用系统的测试，有两种不同的角度：开发人员希望提 供足够的证据来证明软件系统的功能是可行的，这便是基于规格说明的测试；用 户则希望知道系统的缺陷，即找到错误。作为测试人员则要从这两个角度同时考 虑，既要对系统已实现的功能提供证据。同时还要找出系统不能做什么。一般， 软件测试包含以下基本问题： 如何对一个应用系统选择测试用例； 依据怎样的准则对所选择的测试用例的覆盖程度进行评判； 当系统有改动时，如何进行有效的测试用例修订。 3 1 1 测试的定义 软件测试的定义有很多，但是有些并不正确，或者说是不适用于现代软件 测试的实际的。m y e r s 在1 9 7 9 年的著作软件测试的艺术一书中给出了测试 的三个错误定义：测试是显示错误不存在的过程。测试是显示软件程序能正 确地执行它的预期设计功能的过程。 测试是对一个程序能按照它设计去执行而 树立信心的过程。这些定义都不能正确反应软件测试的本质和目的。在m y e r s 的同一本书中给出了软件测试的比较公认的定义： 软件测试是通过有目的地运行软件程序以发现其缺陷的过程。 虽然对于软件测试正确的定义会有很多大同小异，但是有两点是大家比较 公认的。 1 7 基于c b d 的软件测试方法研究 1 所有软件都有缺陷，也就是英文中的b u g 一词。 2 软件测试需要运行程序，发现缺陷和错误，并尽量修复缺陷和改正错误。 3 1 2 测试的目标 g l e nm y e r s 在他关于软件铡试的优秀著作中陈述了一系列关于测试目标的 规则： 1 测试是一个为了发现错误而执行程序的过程。 2 一个好的测试案例是指很可能找到迄今为止尚未发现的错误的案例。 3 一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。 由此，我们可以看出，我们的目标是设计这样的测试，它们能够系统地揭 示不同类型的错误并且耗费最少时间和最小工作量。但在进行测试时，我们要认 清也必须牢记，测试无法说明错误和缺陷不存在，它只能表示软件错误和缺陷已 经出现。 3 1 3 测试的局限性 在软件测试理论的发展过程中，有一个分支是程序正确性证明，即试图通 过符号演算和理论证明的方法来证明程序的正确性。这种方法被认为在实践中是 行不通的。无论是从理论上。还是从经验上，我们都无法发现软件系统中的所有 错误，一个软件系统必定存在着缺陷，软件测试必然有一定的局限性。 输入状态空间的无限性 对于一个很普通的程序，其输入域的集合就可能是一个庞大的数目，例如 程序需要输入三个整形数，可能的组合就有2 3 z x 2 2 2 x 2 3 2 ( 假设计算机字长3 2 位) ，即使计算机的速度足够快。也要花至少几万年的时间，所以不可袁皂把所有 情况拿来做测试：对于程序的内部路径而言，各种组合也是一个惊人的数日，再 加上循环，情况就更复杂。所以，对于一个应用系统的测试不可能达到对输入 状态百分之百的覆盖，即不可能达到完全( 穷尽) 的铡试。 故障巧合性 一个成功的测试在于发现令从未发现的错误，然而不是所有的错误都壹n 此合作的，大多数的错误可能会隐藏。对某种输入，错误的代码也可能产生正确 的结果发生巧合性。例如，对于x + x 与x * x 的代码错误，如果取x = 2 ，错误就 不会被发现。 系统缺陷的不确定性 3 基于c b d 的软件测试方法研究 针对大型软件系统，由于无法确切知道系统的缺陷数量及所在的位置，对 修正这些缺陷而带来的新的缺陷也是不可预测的，所以对系统质量是不可知的。 3 2 规范化的软件测试 就现有研究而言，除非对于软件进行穷举测试( e c h a u s t i v et e s t i n g ) ，没 有任何一种方法能够确定可以发现软件中的所有错误。所以一般认为，软件测试 只能发现软件中可能存在的错误，而不能证明软件本身没有错误。由于技术和成 本的限制，对于一个规模较大的软件进行穷举测试是不可能的，基于这些原因， 软件开发者在测试过程中一般都根据以下的测试满意公理来进行测试的组织和 实施。 【公理1 】测试满意公理在软件测试过程中，可以认为系统的设计需求语 义为一个格 t ， ，若测试能够表明系统满足格的最小上界 tl ， ，则可 以认为系统满足 t ， ，即( t 1 c t ) ( v t k c t t k 譬t 1 ) a ( = t r u e ) = ， = t r u e 。 公理1 说明了测试者在无法找到与系统设计需求语义完全匹配的测试用例 的情况下，为了达到对系统实现的充分测试，往往通过各种方法试图寻找比系统 设计需求语义小的最大规则集。通过对这一规则集的测试来实现对于系统的“充 分”测试。虽然用户构造的规则集往往不是最大的，但用户可以以此为基础产生 对于软件正确运行的信心。 要使软件测试取得令测试者满意的效果需要从技术、管理等各个方面作大 量的工作。在实际测试过程中人们提出了规范化的软件测试方法，希望能够尽量 满足测试的充分性要求。 软件测试的规模包括两层含义：被测软件的规模( 有效代码量、结构逻辑 的复杂性、高性能