（计算机软件与理论专业论文）软件测试用例复用研究.pdf

摘要 随着软件产业的飞速发展，软件的规模变得越来越大，同时软件的复杂度也 变得越来越高。软件测试作为软件质量保证体系中重要一环，其工作的重要性也 逐渐被国内外软件企业所认可。但是，重开发、轻测试的观念仍没有得到根本的 改变，测试工作还是以开发工作的配角身份出现，软件测试过程的管理也具有很 大的随意性，软件测试过程的规范性和有效性无法得到保证，从而造成软件质量、 开发费用，以及交付日期都得不到保障。如何提高软件测试的效率就成了亟待解 决的问题。 软件复用是提高软件开发效率和改善软件质量的一项重要技术。通常学术界 和工业界将复用的概念重点使用于软件的需求工程和设计工程中，并取得了显著 的效果。然而，在测试阶段的复用研究却很少涉及。 本文结合国家8 6 3 课题“软件评测平台的应用与研究”( 课题代号： 2 0 0 4 a a l l 5 0 9 0 ) ，研究在软件测试中测试用例的复用，以提高软件缺陷的发现率， 改善平台测试服务的效率，保证测试的质量。该课题面向第三方软件评测机构， 主要研究在确认测试阶段软件测试的复用。本文分析了在确认测试阶段产生的可 复用资源，研究了面向复用的软件测试模型，提出了可复用测试用例的生成过程 和基于复用的测试用例生成过程，以及可复用测试用例的描述定义、分类检索， 最后在此基础上设计并实现了测试用例库系统。 关键词：软件测试，测试用例，复用，测试用例库 西北大学计算机系硕士研究生论文 a b s t r a c t w i t ht h ed r a s t i cd e v e l o p m e n to fs o f t w a r ei n d u s t r ya n di t si n c r e a s i n g l y l a r g e r s c a l e ，s o f t w a r eh a sb e c o m em o r ec o m p l i c a t e d a sa ni m p o r t a n tl i n k i ns o f t w a r e q u a l i t yg u a r a n t e es y s t e m ，s o f t w a r et e s t i n g h a s g o tr e c o g n i t i o nf r o m s o f t w a r e e n t e r p r i s e s h o w e v e r , t h eo p i n i o ni nw h i c hs o f t w a r ed e v e l o p m e n to u t w e i g h ss o f t w a r e t e s t i n gh a s n tg o tr a d i c a lc h a n g e t e s t i n gw o r ks t i l ls f f f v e sa sas u p p o r t i n gr o l eo f s o f t w a r ed e v e l o p m e n tw o r k , a n dt h em a n a g e m e n to v e rs o f t w a r et e s t i n gi sq u i t ea tw i l l ， l e a d i n gt o n oi n s u r a n c eo ft h er e g u l a t i o na n de f f e c t i v e n e s so fs o f t w a r e t e s t i n g c o n s e q u e n t l y , s o f t w a r eq u a l i t y , d e v e l o p m e n tc o s ta n dd e l i v e r yt i m ec a nn o tb e a s s u r e d h o wt oi n c r e a s es o f t w a r et e s t i n gp r o d u c t i v i t yi sa p m b l e mw h i c hn e e d st ob e s o l v e du r g e n t l y r e u s a b i l i t yi sa ni m p o r t a n tt e c h n i q u ef o ri m p r o v i n gs o f t w a r ep r o d u c t i v i t ya n d q u a l i t y s i g n i f i c a n ta c a d e m i ca n di n d u s t r i a le f f o r th a sb e e np u ti n t ot h es t u d yo f r e u s e i nv a r i o u sp h a s e so ft h es o f t w a r e l i f e c y c l e ，v i z r e q u i r e m e n t s , d e s i g n ，a n d i m p l e m e n t a t i o n ( c o d i n g ) b u t ，t h er e s e a r c ho fr o n s oh a sr a r e l yi n v o l v e dt h et e s t i n g p h a s e c o m b i n e dw i t hn a t i o n a l8 6 3p r o j e c t - t h ea p p l i c a t i o na n dr e s e a r c ho fs o f t w a r e t e s t i n gp l a t f o r m ”，t h i st h e s i sa p p l i e sr e u s a b i l i t yt ot h et e s t i n gp h a s e ，w h i c hm a i n l y s t u d i e so nt h es o f t w a r et e s t i n gr e u s ei na c c e p t a n c et e s t i n gp h a s e t h i st h e s i sa n a l y s e s t h er e u s a b l et e s t i n ga s s e t sa n dr e s e a r c h e st h er e u s e - o r i e n t e ds o t f w a r et e s t i n gm o d e li n a c c e p t a n c et e s t i n gp h a s e i to f f e r st w op r o c e s sf r a m e w o r k s o n ei su s e dt op r o d u c e r e u s a b l et e s tc a s e ，t h eo t h e ri su s e dt op r o d u c et e s tc a s ew h i c hi sb a s e do nt e n s a b l e t e s tc a s e a n du s e sf a c e t e dc l a s s i f i c a t i o ns c h e m et oc l a s s i f ya n dr e t r i e v et h er e u s a b l e t e s tc a s e si nt e s tc a s el i b r a r y b a s e do nt h er e s e a r c ho ft e s tc a s er e u s e ，at e s tc a s e l i b r a r yi sd e s i g n e da n di m p l e m e n t e d k e yw o r d s ：s o f t w a r et e s t i n g ，t e s tc a s e ，r e u s e ，t e s tc a s el i b r a r y 西北大学计算机系硕士研究生论文i i 西j 匕大学学位论文知识产权煮嗖书 本人完全了解学校有关保护知识产权的规定，即：硬究生在校攻 读学位期间论文工作的知识产权单位属于廷北大学。学校有权保爨著 向国家有关部f 1 或机构送交论文的复印件和邀予舨。本人定许论文被 查阕和借阙。学校可以将本学位论文的全部或部分悫容编入有关数据 瘴进行检索，哥鞋采鼹影印、缩窜或扫描等复篱手段保存和汇编本学 位论文。麓时，本人保证，肇盈后结合学位论文研究课题再撰写的文 章一律注磷作者单位为西北大学。 保密论文待解密后适用本声明。 学位论文作者签名：j 班汪耻指导教师签名： 狐 年s 窍l o 日9 一了辱6 窍 b f 型；。窆垩 蕹j 乏大学学位论文独穰经声明 本人声明：赝呈交懿学霞论文是本人在导师搭导下进行酶研究_ i 作及取褥熬 舞究成果。据我鼹知，除了文中特别船以标注和致谢的逾 方外，本论文不包含萁绝入汪经发表藏撰写过的研究成果，也不包含 为获褥西= 艺大学或其它教育机构的学位或证书而使用过的材料。与我 一阊工作的同志对本研究所做的任何贡献均已在论文中作了明确的 觉明并表示谢意。 学位论文作者签名：弱汪。西 2 皇年6a o 礤 前言 信息技术的飞速发展，使软件产品应用到社会的各个领域，软件产品的质量 自然成为人们共同关注的焦点。质量不佳的软件产品不仅会使开发商的维护费用 和用户的使用成本大幅增加，在一些关键应用中还可能造成灾难性的后果。因此 软件产品的质量和可靠性需要得到保障。 软件测试是为了发现错误而执行程序的过程，它是发现软件中错误和缺陷的 主要手段。软件开发的目的是开发出实现用户需求的高质量、高性能的软件产品， 软件测试以检查软件产品内容和功能特性为核心，是软件质量保证的关键步骤， 也是成功实现软件开发目标的重要保障。统计表明，在典型的软件开发项目中， 软件测试工作量和成本往往占软件开发总工作量和成本的一半【l 】。 然而软件测试是一项繁琐而复杂的工作，近年来，虽然软件测试有了较大的 发展，但仍无法满足当今软件开发的实际需要。因此，创建或改进软件测试理论、 方法，开发一些实用的软件测试工具，满足软件开发的实际需要和提高软件测试 的有效性，以确保软件系统的质量，一直是软件测试研究人员所奋斗的目标。 软件测试不确定性，主要是指软件测试人员的能力达不到规定的要求，软件 测试的过程失去控制，从而导致软件测试结果的重现性差，不同的测试人员对同 一个软件的测试结果经常是不同的。在软件测试中往往“重操作、轻管理，重结 果、轻过程”，使软件测试的质量得不到保证。正如许多软件工程专家所指出的： “软件发展的主要问题是管理问题，而不是技术问题”。 针对当前软件测试过程中存在的问题，解决的途径有两方面，一方面从软件 测试工程化的研究着手，对软件测试过程进行建模，建立软件测试的流程，并对 流程中的每个过程规定其相应的活动，使软件的测试活动由个人的不确定活动转 向软件测试的工程化。另一方面，从软件测试的复用解决测试人员经验不足的问 题，从而比较全面地解决了软件测试的不确定性问题。 可复用性是人类解决问题时普遍使用的概念。软件复用思想的提出及软件复 用技术的发展，对软件界乃至于整个计算机技术的发展有着深远的历史意义和现 实意义。传统上，软件测试复用比较广泛的应用在同一个测试项目的不同测试阶 西北大学计算机系硕士研究生论文 段和回归测试中。例如，低层被测对象的测试用例或其部分内容常常被复用在高 层被测对象的测试中，它们包括【2 】： ( 1 ) 单元测试的功能确认类用例可以在模块集成测试阶段复用； ( 2 ) 模块确认测试的测试用例可以在单元配置组装测试和确认测试中复用； ( 3 ) 配置项确认测试的测试用例在系统综合测试和系统验收测试中的复用。 然而，事实上在不同的测试项目之间也存在可复用的机会，如何发现这些可 复用的资源并充分地加以利用，就成为软件测试工作者面临的问题。本文主要面 向第三方软件测试机构，对不同项目间确认测试阶段的测试复用进行了研究。对 于第三方软件测试机构来说，随着测试项目的不断增加，产生的测试资源会日益 积累，如何在这些测试资源中发现并充分利用那些可复用的资源，成为第三方软 件测试机构需要解决的问题。 本文的主要研究工作包括： 1 分析了在软件确认测试阶段产生的可复用资源，研究了面向复用的软件 测试模型； 2 提出了生成可复用测试用例的过程框架和基于复用的测试用例生成过 程。生成可复用测试用例的过程包括五个步骤：测试层次划分、发现公共需求、 可复用测试用例设计、可复用测试用例评审和存储可复用测试用例。基于复用的 测试用例生成过程共分为：系统分析、提取查询信息、查询可复用测试用例库和 测试用例复用四个步骤； 3 利用软件复用中基于刻面的构件分类思想，本文采用了基于刻面的分类 方法对可复用测试用例进行分类，采用了关键字和刻面组合查询的方式进行检 索。 4 在研究测试用例复用的基础上，设计并实现了测试用例库系统。 本文共分为六章。 第一章介绍了软件测试的基础、软件测试面临的问题及其解决途径，介绍了 软件测试复用的必要性。 第二章对软件复用技术进行了介绍，主要介绍了软件复用中可复用的软件制 品以及软件复用的相关技术。 第三章着重介绍了软件测试中可复用的测试资源，研究了面向复用的测试模 西北大学计算机系硕士研究生论文 2 型，分析了软件测试复用的优点和难点。 第四章介绍了软件测试用例的复用，首先介绍了测试用例在软件测试中的作 用，对它的复用的必要性和重要性，然后提出了生成可复用测试用例的过程框架 和基于复用的测试用例生成，最后介绍了可复用测试用例的管理。 第五章介绍了测试用例库系统的设计与实现。 第六章对本文作了总结并对今后的进一步研究工作做了展望。 西北大学计算机系硕士研究生论文 第一章软件测试概述 软件测试是软件开发过程中的一个重要的环节，是保证软件质量和可靠性的 重要手段。在软件开发的过程中，软件开发的每个阶段都有可能产生误解或差错。 因此，要力求通过每个阶段的技术审查、走查、测试实施等能够尽早、尽量地发 现软件中存在的错误并将其排除。软件测试就是在软件投入运行使用之前，对软 件需求分析、设计规格说明、编码实现的最终复审，贯穿于软件定义与开发的整 个期间1 3 1 。 1 1 软件测试定义 传统上认为软件测试的方法从总体上分为两类。第一类测试方法是试图验证 软件是“工作的”，所谓“工作的”就是指软件的功能是按照预先的设计执行的； 而第二类测试方法则是设法证明软件是“不工作的”。 提出第一类方法的代表人物是软件测试领域的先驱d r b i l lh e t z e l ，他首先 在1 9 7 3 年给软件测试一个这样的定义：“就是建立一种信心，认为程序能够按预 期的设想运行。”后来在1 9 8 3 年他又将定义修订为：“评价一个程序和系统的特 性或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行 为。” 4 1 在他的定义中的“设想”和“预期的结果”就是用户需求或功能设计。 第一类测试可以简单抽象地描述为这样的过程：在设计规定的环境下运行软 件的功能，将其结果与用户需求或设计结果相比较，如果相符则测试通过，如果 不相符则视为b u g 。这一过程的终极目标是将软件的所有功能在所有设计规定的 环境全部运行，并通过。 在软件行业中一般把第一类方法奉为主流和行业标准。1 9 9 0 年的i e e e a n s i 标准将软件测试进行了这样的定义：“就是在既定的状况条件下，运行一个系统， 观察记录结果，并对其某些方面进行评价的过程。瞪】 第二类方法的代表人物是g l e n f o r dj m y e r s ，他认为测试不应该着眼于验证 软件是工作的，相反应该首先认定软件是有错误的，然后去发现尽可能多的错误。 他还从人的心理学的角度论证，将“验证软件是工作的”作为测试的目的，非常 不利于测试人员发现软件的错误。于是他于1 9 7 9 年提出了他对软件测试的定义： 西北大学计算机系硕士研究生论文4 “就是以发现错误为目的而运行程序的过程。” 6 1 这就是软件测试的第二类方 法，简单地说就是验证软件是“不工作的”，或者说是有错误的。 在此，本文对两方法进行一个简单的对比。 虽然软件测试总的目的是为了软件产品的质量，但很明显这两类测试方法在 具体目标、或指导思想上截然相反。由此也决定了它们在思路、过程和测重点上 有很大的差别，并各有利弊的。 第一类测试方法以需求和设计为本，因此有利于界定测试工作的范畴，更便 于部署测试的侧重点，加强针对性。而第二类测试方法与需求和设计没有必然的 关联，如果计划管理不当，测试活动很容易丢失重点，走入歧途。 第一类测试方法可以与软件的架构和软件开发的计划相配合，使软件测试活 动逐层次的展开，从而使软件的功能和质量有计划地逐步完善和提高。第二类测 试方法不具备这种过程的渐进性。 第一类测试方法的缺点是缺乏灵活性，不利于测试人员主观能动性的发挥， 正像m y e r s 先生所说，不容易找到软件的缺陷( b u g ) 。而这方面正是第二类测 试方法的长处。 1 2 软件测试分类 软件测试可以从不同的角度进行分类： 根据程序执行的方式，可以将软件测试方法分为人工测试( m a n u a lt e s t i n g ) 和自动化测试( a u t o m a t i ct e s t i n g ) 两类。 根据测试过程中程序的执行状态，可以将软件测试分为静态测试( s t a t i c a n a l y s i s ) 和动态测试( d y n a m i ct e s t i n g ) 。静态测试方法是对被测试程序特征分 析的一些方法的总称，其最大的特征是在对程序进行静态分析的过程中不执行被 测程序，如：审查、符号验算及验证。动态测试方法的一个最大的特征就是在测 试的过程中执行被测试源程序，其基本思想是使程序有控制的进行，并从多种角 度观察程序进行时的行为。因此，动态测试必须包括被测程序和用以运行软件的 数据( 称为测试数据) 7 】。 根据测试过程对系统内部结构和具体实现算法细节的关心情况，软件测试方 法可分为黑盒测试和白盒测试。 西北大学计算机系硕士研究生论文 黑盒测试又称为数据驱动测试( d a t ad r i v i n gt e s t i n g ) 或基于规格说明的测 试( s p e c i f i c a t i o n - b a s e dt e s t i n g ) 。在进行黑盒测试时，把软件当作一个黑盒，只 需找到程序输出和输入之间的关系或者程序的功能。因此，黑盒测试是从用户的 观点出发的测试，它是从软件需求出发，根据软件需求规格说明设计测试用例， 并按照测试用例的要求运行被测程序的测试方法。它较少关心程序内部的实现过 程，侧重于程序的运行结果，把被测程序看成是不可见的盒子，因此被称为黑盒 测试。黑盒测试方法主要有等价类划分、边界值分析、因果图、错误推测等【叭。 自盒测试也称为结构测试( s 仃l l c t i l r et e s t i n g ) 、逻辑驱动测试( l o g i c a ld r i v i n g t e s t i n g ) 或基于程序的测试( p r o g r a m b a s e dt e s t i n g ) 。采用这种测试方法，测试 者需要掌握被测试程序的内部结构，并根据内部结构构造测试用例。白盒测试是 种按照程序内部的逻辑结构和编码结构设计并执行测试用例的测试方法。白盒 测试通常根据覆盖准则设计测试用例，使程序中的每个语句、每个条件分支、每 个控制路径都在程序测试中受到检验【9 。白盒测试需要运行程序，并能在运行过 程中跟踪程序的执行路径。 1 3 软件测试阶段 在软件交付周期的不同阶段，通常需要对不同类型的目标应用进行测试。这 些阶段是从测试小的模块( 单元测试) 到测试整个系统( 系统测试) 不断向前发 展的。在软件测试中包括的测试阶段有：单元测试、集成测试、确认测试和系统 测试 1 0 】。 1 单元测试 单元测试的对象是软件设计的最小单位模块。单元测试的依据是详细设 计描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块 内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测 试。 2 集成测试 集成测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模 块组装在起之后，进行综合测试以便发现与接口有关的各种错误。一般来说， 集成测试有两种集成方法，一种是设计人员把所有模块按设计要求一次全部组装 西北大学计算机系硕士研究生论文 起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱。因为 测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个 错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。 另一种与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一 步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。常用的有两种 增量式集成方法，分别为：自顶向下和自底向上法。 3 确认测试 确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书 中的确认标准。确认测试准则：旨在说明软件与需求是否一致，并着重考虑软件 是否满足合同规定的所有功能和性能，文档资料是否完整、准确，人机界面和其 他方面( 例如，可移植性、兼容性、错误恢复能力和可维护性等) 是否令用户满 意。 4 系统测试 计算机软件是基于计算机系统的一个重要组成部分，软件开发完毕后应与系 统中其它成分集成在一起，此时需要进行一系列系统集成和确认测试。系统测试 应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能正 常工作并完成所赋予的任务。 1 4 软件测试的不确定性 软件测试不确定性，主要是指软件测试人员的能力达不到规定的要求，软件 测试的过程失去控制，从而导致软件测试结果的重现性差，不同的测试人员对同 一个软件的测试结果经常是不同的。在软件测试中往往“重操作、轻管理，重结 果、轻过程”，使软件测试的质量得不到保证。正如许多软件工程专家所指出的： “软件发展的主要问题是管理问题，而不是技术问题”。究其原因存在以下4 方面的情况 1 1 1 。 1 软件测试的立场 软件测试的目的是最大限度地发现软件中存在的错误，而不是为了证明软件 没有错误。软件测试应该站在客户立场采用“攻击”的手法去测试软件，但是有 些企业往往为了争取进入市场的时间而站在开发者立场去表明软件没有错误。 西北大学计算机系硕士研究生论文7 2 软件测试人员的素质 软件测试在很大程度上依赖测试人员的个人经验，有经验的测试人员知道控 件的测试步骤不同产生的结果是不同的，a p i 的测试应该采用程序方式进行，而 g u i 的测试应该采用键盘和鼠标方式进行，中间件和构件的功能和性能必须放在 相应的场景中才能显现等。有不少人认为“做不了开发，就去做测试”，好像软 件测试比软件开发的要求低得多。由此引发的结果是测试人员素质不高，测试质 量降低，更谈不上对软件测试人员的培训提高了。 置软件测试的过程 软件测试过程与软件开发过程一样，应该进行过程建模。在实际情况中，往 往是软件测试没有一定的流程，如测试没有计划，随机进行；又如测试用例即时 构想，没有事先设计。更谈不上对软件测试过程进行监督了，由此引发的结果是 测试过程失控。 4 软件测试的结果 软件测试的结果，特别是软件测试中发现的缺陷应该能够重现，为软件的维 护和修改提供依据。一个软件的功能是否正确和性能是否符合要求，是在该软件 采用的开发技术、运行环境和应用场景的三维坐标中显现出来的，软件测试的结 果应该对照软件的需求和软件测试的记录而产生的。由于在软件测试过程中缺少 详细的记录，往往使软件测试报告缺乏充分的依据。 1 5 解决途径 针对当前软件测试过程和管理方面存在的问题，解决的途径有两方面，一方 面从软件测试工程化的研究着手，对软件测试过程进行建模，结合国家标准 g b t 1 5 4 8 1 - 2 0 0 0 检测和校准实验室能力的通用要求所规定的检测过程要求， 建立软件测试的流程，并对流程中的每个过程规定其相应的活动，使软件的测试 活动由个人的不确定活动转向软件测试的工程化。另一方面，从软件测试的复用 解决测试人员经验不足的问题，从而比较全面地解决了软件测试的不确定性问题 【1 l 】 西北大学计算机系硕士研究生论文 1 5 1 软件测试工程化 改进软件过程，提高软件的开发质量一直是软件工程界努力的目标。软件测 试是软件生命周期中的一个子过程，对软件测试过程的规范化问题，越来越受到 软件测试领域专家的重视。软件测试工程化的主要思想是要求建立正式的测试组 织、明确测试的目标和流程、确定测试的活动、对测试的过程和活动进行监控， 从而保证软件测试的质量。软件测试工程化的研究始于1 9 9 6 年，从测试过程的 改进、测试组织测试度、测试评估程序到测试成熟度模型，进行了一系列的研究 1 2 1 13 1 。特别是使用软件测试成熟度模型( t m m ) 改进软件测试过程的提出，将 软件测试成熟度模型分为5 级，为软件测试成熟度的评估提供了依据。 在c m m 体系中间，并没有对测试管理模型作详细的规定，为了弥补这个缺 陷，t m m 将测试划分为五个级别，正好匹配c m m 的五个相应级别，这五个级 别分别是：初始级、定义级、集成级、管理级和优化级，每一个成熟度等级又包 括若干成熟度目标，每个成熟度目标又包含若干成熟度子目标 1 4 【1 5 】。图1 - 1 表示 t m m 的框架结构。 图1 - 1 测试能力成熟度框架 从图1 1 中可以看出，为了达到某一级测试成熟度，予目标定义了软件组织 西北大学计算机系硕士研究生论文 9 必须采取的一组措施的界限和范围。进而根据这些措施定义了一组与软件组织的 承诺相联系的活动和任务，并将这些活动和任务以及相应的职责分配给在测试过 程中的主要参与者：管理人员、开发人员与测试人员、用户或客户。职责不同的 几种人员履行各自的责任，通过完成与子目标相关的各种任务和活动达到预定的 子目标【1 6 】。 除初始级外，每个成熟度等级均包含若干要实现的目标。为了达到一个成熟 度等级，就必须满足该等级要求的所有成熟度目标。按成熟度等级排列的成熟度 目标如图1 - 2 。 优化、预防缺陷和质量控制级( 5 ) 优化测试过程质量控制应用过程数据预防缺陷 管理与测量级( 4 ) 软件质量评价建立组织范围内的评审程序健立 集成级( 3 ) 控制和监视测试过程软件全寿命周期测试 制定技术培训规划健立软件测试组织 定义级( 2 ) 制度化基本的测试技术和方法，启动测试计划过程 制定测试与调试目标 初始级( 1 ) 1 5 2 软件测试复用 图1 - 2 测试能力成熟度目标 针对当前软件测试过程和管理方面存在的问题，在促进软件测试工程化的同 时，将软件复用的思想应用到软件测试过程中不失为一个有益的尝试。通过软件 测试复用，可以解决测试人员经验不足的问题，提高软件测试的效率，从而比较 全面地解决了软件测试的不确定性问题。本文正是基于这样的背景，对软件测试 复用进行了研究。 西北大学计算机系硕士研究生论文 1 0 第二章软件复用技术 可复用性是人类解决问题时普遍使用的一个概念，比如说机械行业的螺钉生 产，螺钉一般是在专业制造螺钉的标准件机械工厂中生产的，而且该类机械工厂 本身并不需要生产出来的所有螺钉，生产的最主要目的是为了将螺钉销售给其他 机械行业的机器制造企业用来装配机器。当然机械行业比软件行业成熟得多，而 且生产软件产品过程和工艺要比生产螺钉的工程和工艺复杂的多，但这恰恰正是 我们用成熟的分工专业的机械行业的经验来思考目前软件行业的作坊式的生产 流程的理由，几个世纪前的人们正是在手工作坊里加工这些机械零件的。目前的 软件行业状况是一方面有大量的软件需要开发和维护，软件危机依然严重存在， 另一方面是有大量的重复工作存在；例如美国一所大学1 9 9 1 年的一项调查报告 发现，该校图书管理系统的5 0 多个分类程序中，重复实现同一个算法的有十几 个。现在越来越多的人已认识到，解决软件危机一个重要途径是采用软件复用技 术。因此，对软件复用方法的研究已经是软件工程中的重点和热点，被视为解决 软件危机，提高软件生产效率和质量的现实可行的途径【1 7 】- 2 0 l 。 2 1 软件复用技术产生的历史背景 随着计算机应用的逐步扩大，软件需求量迅速增加，规模也日益增长，软件 规模的快速增长，带来了软件的复杂程度的增加和程序代码的几何级增长。即使 是富有经验的程序员，也难免对编写数万行的软件顾此失彼，其结果是：大型软 件的开发费用经常超出预算，完成时间也常常超过预期。庞大的软件开发和维护 费用，加上不可避免的软件质量下降，对计算机应用的继续扩大构成巨大的威胁。 面对这种严峻的形势，软件界的有识之士发出了软件危机的警告。 1 9 6 8 年北大西洋公约组织( n a t o ) 的计算机科学家在前联邦德国召开的国 际学术会议上第一次提出了“软件危机”( s o f t w a r ec r i s i s ) 这个名词。概括来说， 软件危机包含两方面问题：一、如何开发软件，以满足不断增长，日趋复杂的需 求；二、如何维护数量不断膨胀的软件产品。 具体地说，软件危机主要表现有以下表现【2 l 】： 对软件开发成本和进度的估计不准确； 西北大学计算机系硕士研究生论文 1 1 用户对“已完成”系统不满意的现象发生； 软件产品的质量不稳定； 软件的可维护程度低： 软件没有适当的文档资料； 软件的成本不断提高； 软件开发生产率的提高赶不上硬件的发展和人们需求的增长。 针对日趋复杂的软件需求的挑战，软件业界研究了软件复用技术。作为针对 “软件危机”的最佳对策，软件复用技术已经引起人们的普遍关注。 2 2 软件复用的定义 目前，对于软件复用还没有一个形式化的概念，许多研究人员从各自不同的 角度对软件复用这个概念作了说明，b i g g e r s t a f f 和r j t c h e r 认为软件复用是在新 的开发项目中使用以前己获得的概念和对象；t r a c z 认为软件具有事先性，复用 特别为复用目的而设计的软件过程，而把使用不是特别为复用目的而设计的软件 称为软件挽救2 3 】：g a m b h i r 把在多个应用中使用相同的构件称作为软件复用和软 件挽救之间的区别。 本文中，软件复用是指重复使用“为了重复使用目的而设计的软件( 可复用 软件) ”的过程【24 1 。在软件演化的过程中，重复使用的行为可能发生在三个维上： 时间维：使用以前的软件版本作为新版本的基础，加入新功能，适应新需 求，即软件维护。 平台维：以某平台上的软件为基础，修改其和运行平台相关的部分，使其 运行于新平台，即软件移植。 应用维：将某软件( 或其中构件) 用于其他应用系统中，新系统具有不同功 能和用途，即真正的软件复用。 软件复用的目的是要使软件开发工作进行得更快更好更省。在市场环境中满 足市场时间上面的要求，开发出来的产品更可靠、易于维护和节约成本。 2 3 软件复用的分类 软件复用不仅是对软件程序的复用，还包括对软件生产过程中其他劳动成果 西北大学计算机系硕士研究生论文 1 2 的复用，如项目计划书、可行性报告、需求分析、概要设计、详细设计、编码( 源 程序) 、测试用例、文档与使用手册等等【2 5 1 。软件复用的分类方法很多，一种方 法是把软件复用分为横向复用和纵向复用【2 “。横向复用( h o r i z o n t a lr e u s e ) 是指 重用不同应用领域中的软件元素，例如数据结构、分类算法、人机界面构件等， 标准函数库就是一种原始的横向复用机制。纵向复用是指在一类具有较多公共性 的应用领域之间进行软件重用。因为在两个截然不同的应用领域之问实施软件复 用的潜力很小，所以纵向复用才广受瞩目，并成为软件复用技术的真正所在。 另一种分类方法是由北大青鸟工程提出的，它把软件复用分为两类：产品复 用和过程复用2 7 1 。产品复用指对软件开发过程中生成的各种产品( 需求规约、 设计、程序、测试计划和数据等) 构件的复用，这涉及可复用构件的建造( 从现 有系统中获取或者有目的的生产) 及可复用构件的使用( 对知识性资源的参考和 对程序代码级资源的复合组装) 两个方面，通过专业性的构件开发和基于构件复 用的系统集成实现软件的工业化生产。过程复用指通过采用自动化技术，复用关 于软件系统生成或变换的知识，从而使得可以从需求描述出发，通过生成或变换， 自动生成最终所需的系统。应用生成器、程序变换器和可执行规约语言均是过程 复用的例子。完全通用的过程复用意味着软件生产的自动化，这在目前还是不现 实的想法。当前过程复用的实践大多和领域相关，是非常理想的软件复用方式， 但在目前技术发展水平下，仍是难以企及的目标，产品复用也成为主要的研究课 题。 就产品复用而言，又可分为直接复用和间接复用两类，这是由被复用产品本 身的性质和内容所决定的。直接复用是指对那些可表示为某种程序设计语言代码 的构件的复用，这类构件的复用及其通过一定机制的复合( 组装) 可直接产生可 执行的应用程序，这是我们开发软件的最终目标。间接复用是指对需求规约、功 能规约、设计思想、测试计划等文档型知识的复用，这类非代码构件的复用虽然 不能直接得到最终可运行的系统，但可以对系统开发的效率和质量带来极大的好 处，这类构件的复合( 组装) 缺乏形式化和机械化的机制，通常只能由开发者在 分析理解后进行手工复合。 对已有软件资源的复用存在两种情形，一是不作修改的全部采用，这类构件 恰好能满足使用者的需求，这种复用成为黑盒复用；另一种是所复用的构件只能 西北大学计算机系硕士研究生论文 1 3 满足使用者部分需求，需要对构件进行适应性修改才可采用，这种复用称为白盒 复用。在大多数情况下，对构件的复用均是白盒复用。 2 4 可复用的软件制品 c o p p e rj o n e s 定义了可复用的十种软件制品【l 】： 1 项目计划。软件项目计划的基本结构和许多内容均是可以跨项目复用的， 这样减少了用户指定项目计划的时间，也降低了建立进度表、风险分析和其他特 征相关的不确定性。 2 成本估计。因为经常不同项目中含有类似的功能，所以有可能在极少修 改或不修改的情况下，复用对该功能的成本估计。 3 体系结构。即使当考虑不同的应用领域时，也很少有截然不同的程序和 数据体系结构。因此，有可能建立一组类属的体系结构模板，并将那些模板作为 可复用的设计框架。 4 需求模型和规约。类和对象的模型和规约是明显的复用候选者，此外， 用传统软件工程方法开发的分析模型也是可复用的。 5 设计的复用。设计结果比源程序的抽象级别更高，因此它的复用受现实 环境的影响较少，从而使可复用构件被复用的机会更多，并且所需的修改更少。 这种复用有三种途径，第一种途径是从现有系统的设计结果中提取一些可复用的 设计构件，并把这些构件应用于新系统的设计；第二种途径是把一个现有系统的 全部设计文档在新的软硬件平台上重新实现，也就是把一个设计运用于多个具体 的实现；第三种途径是独立于任何具体的应用，有计划的开发一些可复用的设计 构件。 6 代码的复用。包括目标代码和源代码的复用。其中目标代码的复用级别 最低，历史也最久，当前大部分编程语言的运行支持系统都提供了连接( l i n k ) 、 绑定( b i n d i n g ) 等功能来支持这种复用。源代码的复用级别略高于目标代码的复 用，程序员在编程时把一些想复用的代码段复制到自己的程序中，但这样往往会 产生一些新旧代码不匹配的错误。想大规模的实现源程序的复用只有依靠含有大 量可复用构件的构件库。如“对象链接及嵌入”( o l e ) 技术，既支持在源程序级 定义构件并用以构造新的系统，又使这些构件在目标代码的级别上仍然是一些独 西北大学计算机系硕士研究生论文1 4 立的可复用构件，在运行时被灵活的得新组合为各种不同的应用。 7 分析的复用。这是比设计结果更高级别的复用，可复用的分析构件是针 对问题域的某些事物或某些问题的抽象程度更高的解法，受设计技术及实现条件 的影响很少，所以可复用的机会更大。复用的途径也有三种，即从现有系统的分 析结果中提取可复用构件用于新系统的分析；用一份完整的分析文档作输入产生 针对不同软硬件平台和其它实现条件的多项设计：独立于具体应用，专门开发一 些可复用的分析构件。 8 用户界面。可能是最广泛的复用产品。g u i 软件经常被复用。因为它可 以占到一个应用的6 0 的代码量，复用效果非常明显。 9 数据。在多数被复用的软件制品中，数据包括内部表、列表和记录结构， 以及文件和完整的数据库。 1 0 测试信息的复用。主要包括测试用例的复用和测试过程信息的复用。前 者是把一个软件的测试用例在新的软件测试中使用，或者在软件做出修改时在新 的一轮测试中使用。后者是在测试过程中通过软件工具自动地记录测试的过程信 息，包括测试员的每一个操作、输入参数、测试用例及运行环境等一切信息。这 种复用的级别，不便和分析、设计、编程的复用级别作准确的比较，因为被复用 的不是同一事物的不同抽象层次，而是另一种信息，但从这些信息的形态看，大 体处于与程序代码相当的级别。 由于软件生产过程主要是正向过程，即大部分软件的生产过程是使软件产品 从抽象级别较高的形态向抽象级别较低的形态演化，所以较高级别的复用容易带 动较低级别的复用，因而复用的级别越高，可得到的回报也越大，因此分析结果 和设计结果在目前很受重视。用户可购买生产商的分析件和设计件，自己设计或 编程，掌握系统的剪裁、扩充、维护、演化等活动。 2 5 软件复用的相关技术 实现软件复用的关键因素( 技术和非技术因素) 主要包括：软件构件技术 ( s o r w a r ec o m p o n e n tt e c h n o l o g y ) 、领域工程( d o m m ne n g i n e e r i n g ) 、软件构架 ( s o f t w a r e a r c h i t e c t u r e ) 、软件再工程( s o f t w a r e r e e n g i n e e r i n g ) 、开放系统( o p e l l s y s t e m ) 、软件过程( s o f t w a r ep r o c e s s ) 、c a s e 技术等以及各种非技术因素，且 西北大学计算机系硕士研究生论文1 5 各种因素是互相联系、互相影响的，如图2 - 1 所示，它们结合在一起，共嗣影响 较终笺翔瓣实瑶【2 朝。 图2 1 实现软件复用的关键因素 1 ，软件构件技术 摘镎是撵痤霜系统孛毒狱鞠镶辨谖懿药袋戏分，瑟霹复麓橡磐霆摇其露箱鼹 独立的功能和可复用价值的构件。 可毵用构件应具备以下属性：有用性：必须提供有用的功能；可用性： 登矮易予遴解囊佼臻 震量：纛努及其交形崧矮箍正确工露；逶盛蛙：应该 易于通过参数化等方式在不同语境中进行配鼹；可移植性：应能在不同的硬件 平台和软件环境中工作。 戆麓鼹软终复矮遴解豹深灭，擒俘瓣禳念邑不莠弱隈予滚饯鹳稳终，藤楚延 伸到需对乏、系统和软件的需求规约、系统和软件的构架、文档、测试计划、测试 案例和数据以及其他对开发活动肖用的信息。这些信息都可以称为可复用软件构 件。 软件构件技术是支持软件复用的核心技术，跫近几年来迅速发展并受到高度 重视的一个学科分支。其主要研究内容包括： ( 1 ) 鞫俘获取：蠢嚣静匏构侉麓产帮双己裔系统中挖掘掇漱梅箨； ( 2 ) 构件模型：研究构件的本质持征及构件间的关系； 嚣i 大学计冀飒系颈研究生论文1 6 ( 3 ) 构件描述语言：以构件模型为基础，解决构件的精确描述、理解及组装 问题； ( 4 ) 构件分类与检索：研究构件分类策略、组织模式及检索策略，建立构件 库系统，支持构件的有效管理； ( 5 ) 构件复合组装：在构件模型的基础上研究构件组装机制，包括源代码级 的组装和基于构件对象互操作性的运行级组装； ( 6 ) 标准化：构件模型的标准化和构件库系统的标准化。 2 j 软件构架 软件构架是对系统整体结构设计的刻画，包括全局组织与控制结构，构件间 通讯、同步和数据访问的协议，设计元素间的功能分配，物理分布，设计元素集 成，伸缩性和性能，设计选择等。 研究软件构架对于进行高效的软件工程具有非常重要的意义：通过这一研 究，有利于发现不同系统在较高级别上的共同特性：获得正确的构架对于进行正 确的系统设计非常关键；对各种软件构件的深入了解、使得软件工程师可以根据 一些原则在不同的软件构架之间作出选择；从构架的层次上表示系统，有利于系 统较高级别性质的描述和分析。特别重要的是，在基于复用的软件开发中，为复 用而开发的软件构架可以作为一种大粒度的、抽象级别较高的软件构件进行复 用，而且软件构架还为构件的组装提供了基础和上下文，对于成功的复用具有非 常重要的意义。 3 领域工程 领域工程是为一组相似或相近系统的应用工程建立基本能力和必备基础的 过程，它覆盖了建立可复用软件构件的所有活动。领域是指一组具有相似或相近 软件需求的应用系统所覆盖的功能区域。领域工程包括三个主要的阶段：领域分 析、领域设计和领域实现。 4 软件再工程 软件复用中的一些问题与现有系统密切相关，如：现有软件系统如何适应当 前技术的发展及需求的变化，采用更易于理解的、适应变化的、可复用的系统软 件构架并提炼出可复用的软件构件? 现存大量的遗产软件系统由于技术的发展， 正逐渐退出使用，如何对这些系统进行挖掘、整理，得到有用的软件构件? 已有 西北大学计算机系硕士研究生论文 1 7 的软件构件随着时间的流逝会逐渐变得不可使用，如何对它们进行维护，以延长 生存期，充分利用这些可复用构件? 等等，软件再工程正是解决这些问题的主要 技术手段。 软件再工程是一个工程过程，它将逆向工程、重构和正向工程组合起来，将 现存系统重新构造为新的形式。再工程的基础是系统理解，包括对运行系统、