（计算机软件与理论专业论文）web再工程测试自动化解决方案研究.pdf

摘要 摘要 测试是所有工程学科的基本组成单元，是软件开发的重要部分。有数据表 明，随着各种支持设计与编程的自动化工具的快速发展，软件测试的工作量和 成本在软件开发总工作量和总成本中占有的比例越来越高，常会占到4 0 6 0 之间。而在软件再工程中，软件测试的工作量和成本在软件开发总工作量和总 成本中占有的比例还要增加。 软件测试技术的自动化是软件测试的发展趋势，它能完成许多手工测试无 法实现或难以实现的测试。正确、合理地实旅自动化测试，能够快速、彻底地 对软件进行测试，从而提高软件质量，节省经费，缩短产品开发周期。 本文对软件再工程的测试过程以及w e b 再工程测试过程模型进行了研究探 讨，并在此基础上，对w e b 再工程测试自动化解决方案进行了研究。w e b 再工 程测试自动化解决方案通过各种测试支援工具以及工具间的集成为w e b 再工程 测试的各个阶段提供计算机辅助测试：通过测试管理工具以及测试管理工具和 测试支援工具的集成，实现测试管理数据的自动采集，对测试过程进行管理。 本文还给出了一个w e b 再工程测试自动化解决方案( t p 2 j ) 的设计。该解 决方案用于对c s 结构向b s 结构转化( 既存系统开发语言为p b ，升级后的目 标系统为j s p s e r v l e t + j a v a b e a n s 体系结构) 的w e b 再工程测试过程进行辅 助支持。 最后，本文以z c r w 项目为例介绍了w e b 再工程测试自动化解决方案的实际 应用情况。 关键词w e b 再工程；软件测试自动化；t - p 2 j 解决方案；z c r w a b s t r a c t a b s t r a c t t e s t i n gi sab a s i cc o m p o s i t i o no fa l le n g i n e e r i n gd i s c i p l i n e s ，a n d i sa l s oa ni m p o r t a n tp a r to fs o f t w a r ed e v e l o p m e n t d a t ai n d i c a t e st h a t t h ew o r k l o a da n dc o s to fs o f t w a r et e s t i n ga 1 1h a sav e r yh i g hp r o p o r t i o n o ft h et o t a lw o r m o a da n dt o t a lc o s to fs o f t w a r ed e v e l o p m e n t ，u s u a l l y 4 0 一6 0 a n dt h ew o r k l o a da n dc o s to fs o f t w a r et e s t i n gw i l lh a v eah i g h e r p r o p o r ti o no nt h et o t a lw o r k l o a da n dt o t a lc o s to fs o f t w a r ed e v e l o p m e n t a n dt h e p r o p o r t i o n i se v e nh i g h e ri nt h es o f t w a r er e e n g i n e e r i n g d e v e l o p m e n t t h et e c h n o l o g yo fs o f t w a r et e s t i n ga u t o m a t i o ni st h et r e n do ft h e s o f t w a r et e s t i n g ，i tc a nc o m p l e t em a n yt e s t i n gw h i c hc a n tb ec a r r i e d o u to rh a r db ec a r r i e do u ta r t i f i c i a l l y b yc a r r y i n go u tt h ea u t o m a t i o n t e s t i n gr e a s o n a b l y ，w ec a nt e s tt h es o f t w a r eq u i c k l ya n dt h o r o u g h l y ，t h u s r a i s i n gt h es o f t w a r eq u a l i t y ，s a v i n gb u d g e ta n ds h o r t e nt h ep r o d u c t d e v e l o p m e n tp e r i o d t h i st h e s i ss t u d i e st h es o f t w a r et e s t i n gp r o c e s so ft h er e e n g i n e e r i n g a n dt h ep r o c e s sm o d e lo ft h ew e bc e n t r i cr e e n g i n e e r i n g ， a n db a s i n go n t h i s ，r e s e a r c h e st h ea u t o s o l u t i o no ft h ew e br e e n g i n e e r i n gt e s t i n g t h e a u t o s o l u t i o no ft h ew e br e e n g i n e e r i n gt e s t i n gp r o v i d e sa s s i s t a n c ef o r e a c hs t a g eo ft h et e s t i n gp r o c e s sb yg a t h e r i n ga n di n t e g r a t i n gt e s t i n g a i dt o o l sa n dp r o v i d e sa s s i s t a n c ef o rt e s t i n gp r o c e s sm a n a g e m e n tb y i n t e g r a t i n gt e s t i n gm a n a g e m e n tt o o l st h a tc o l l e c tt h em a n a g e m e n td a t a a u t o m a t i c a l l y t h i st h e s i sa l s oi n t r o d u c e st h ed e s i g no fa na u t o s o l u t i o no ft h e w e br e e n g i n e e r i n gt e s t i n g ( t - p 2 j ) t h i ss o l u t i o nu s e df o rp r o v i d e s a s s i s t a n c ef o r t h ec o n v e r s i o nf r o mc ss t r u c t u r et ob ss t r u c t u r e ( d e v e l o p m e n tl a n g u a g eo ft h el e g a c ys y s t e mi sp ba n ds t r u c t u r eo ft h e t t a tl a s t ，t h i st h e s i st a k e sz c r wa sa ne x a m p l et oi n t r o d u c et h e a p p l y i n go ft h ea u t o s o l u t i o no ft h ew e br e e n g i n e e r i n gt e s t i n g k e y w o r dw e br e e n g i n e e r i n g ：s o f t w a r et e s ta u t o m a t i o n ：t - p 2 js o l u t i o n z c r w 独创性声明 本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研 究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他 人已经发表或撰写过的研究成果，也不包含为获得北京工业大学或其它教育机构 的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均 已在论文中作了明确的说明并表示了谢意。 关于论文使用授权的说明 本人完全了解北京工业大学有关保留、使用学位论文的规定，即：学校有权 保留送交论文的复印件，允许论文被查阅和借阅：学校可以公布论文的全部或部 分内容，可以采用影印、缩印或其他复制手段保存论文。 ( 保密的论文在解密后应遵守此规定) 签名：鱼鳘呈导师签名- 第1 章绪论 1 1 软件再工程概述 1 1 1 软件再工程的定义 第1 章绪论 软件再工程( r e e n g i n e e r i n g ) 也称再加工( r e n o v a t i o n ) ，是对既存软件系统 进行调查，并将其重构为新形式代码的开发过程。它处于软件生存期的维护期。 软件维护的适应性、完善性、预防性维护都属于再工程范畴。一般来说，再工 程包括逆向工程、重构和正向工程。 由于既存系统的状况和用户对再工程的需求不尽相同，软件再工程也分为 不同领域。我们把为了适应以w e b 为中心的计算方式而将既存系统再工程升级 为基于w e b 系统的开发过程，称为w e b 再工程“1 。 1 1 2 软件工程进入再工程时代 当今软件系统的规模变得越来越大，结构也越来越复杂，而从头开始构建 的大系统数量在急剧地减少，很多既存系统正在被逐步地利用。越是庞大、悠 久的系统，特别是导入计算机较早的一些重要应用领域，如银行、证券、物流， 乃至政府、军用部门等，它们沉淀的历史遗产越雄厚，价值越高，越不能淘汰。 如图卜1 所示，2 0 世纪9 0 年代以后，先进国家的既存软件维护性开发已占软 件开发总量的8 0 以上。可以说，软件工程已经进入了再工程时代。 北京工业大学工学硕士论文 1 9 8 0 年1 9 9 0 年2 0 0 0 年 图卜l 软件工程中一次工程和再工程比例趋势图 f i g u r e1 1e n g i n e e r i n ga n dr e e n g i n e e r i n gp r o p o r t i o ni ns o f t w a r e e n g i n e e r i n zt i d em a d 1 1 3 软件再工程的特点 软件再工程有两个突出特征，一是比一次软件工程更迫切地需要计算机辅 助支持，二是测试工作比例远大于一次软件工程。前者在再工程方法学研究和 软件模式运动推动下可以找到自动化解决方案，后者则须强化对测试方法学体 系的研究。 1 2 软件测试概述 信息技术的飞速发展，使软件产品应用到社会的各个领域，软件产品的质 量自然成为人们共同关注的焦点。质量不佳的软件产品不仅会使开发商的维护 费用和用户的使用成本大幅增加，还可能产生其他的责任风险，造成公司信誉 下降，继而冲击股票市场。在一些关键应用( 如民航订票系统、银行结算系统、 证券交易系统、自动飞行控制软件、军事防御和核电站安全控制系统等) 中使 用质量有问题的软件，还可能造成灾难性的后果。 软件危机曾经是软件界甚至整个计算机界最热门的话题。为了解决这场危 机，软件从业人员、专家和学者做出了大量的努力。一系列的方法被提出并且 2 第l 章绪论 加以应用。比如结构化的程序设计，面向对象的开发，c m m ，u m l 等等。 事实上，对于软件来讲，“没有银弹! ”。不论采用什么技术和什么方法，软 件中仍然会有错。采用新的语言、先进的开发方式、完善的开发过程，可以减 少错误的引入，但是不可能完全杜绝软件中的错误，这些引入的错误需要测试 来找出，软件中的错误密度也需要测试来进行估计。 测试是所有工程学科的基本组成单元，是软件开发的重要部分。自有程序 设计的那天起测试就一直伴随着。统计表明，在典型的软件开发项目中，软件 测试工作量往往占软件开发总工作量的4 0 以上。而在软件开发的总成本中， 用在测试上的开销要占3 0 到5 0 。 1 2 1 软件测试技术的历史与发展 软件测试是伴随着软件的产生而产生的。早期的软件开发过程中，由于计 算机运行性能比较差，软件的可编程范围也比较狭窄，错误主要集中在元器件 的不稳定上。这阶段的测试更多的是承担的“调试”的任务，只是为了证明系 统可以运行起来。 2 0 世纪5 0 年代后期到2 0 世纪6 0 年代，随着高级语言相继诞生并得到广泛 应用，软件测试逐渐与调试区别开来。但是，由于这一阶段软件受到硬件系统 的制约，规模较小。因此，测试理论和方法的发展比较缓慢。 1 9 7 2 年6 月在美国北卡罗来纳大学召开的首届软件测试正式技术会议，成 为软件测试技术发展中的一个重要里程碑。2 0 世纪7 0 年代以后，随着计算机 硬件的发展，软件的规模越来越大，软件的可靠性也面临着危机；软件测试在 这一阶段承受了挑战。许多新的软件测试理论和测试方法相继诞生，逐渐形成 了一套体系。1 9 7 9 年，g l e n f o r dm y e r s 的软件测试艺术( t h e a r to f s o f t w a r e t e s t i n g ) 中将软件测试定义为：“测试是为发现错误而执行的一个程序或者系 统的过程。” 2 0 世纪8 0 年代，软件测试定义发生了改变，测试不单纯是一个发现错误的 过程，而且包含软件质量评价的内容。1 9 8 3 年，i e e e 提出了软件工程标准术语， 软件测试定义为：“使用人工和自动手段来运行或测试某个系统的过程，其目的 北京工业大学工学硕士论文 在于检验它是否满足规定的需求或是弄清预期结果与实际结果之f n j 的差别。” 2 0 世纪9 0 年代，工具被广泛应用到软件测试中。人们逐渐认识到，工具不 仅仅是有用的，而且在很多情况下是必不可少的。 近2 0 年来，随着计算机和软件技术的飞速发展，软件测试技术研究也取得 了很大的突破。测试专家总结了很好的测试模型，比如著名的v 模型、w 模型 等，在测试过程改进方面提出了t 删( t e s t i n gm a t u r i t ym o d e l ) 的概念，在 单元测试、自动化测试、负载压力测试以及测试管理等方面涌现了大量优秀的 软件测试工具。 虽然软件测试技术的发展很快，但是其发展速度仍落后于软件开发技术的 发展速度。随着面向对象技术，软件重用技术以及i n t e r n e t i n t r a n e t 的广泛 应用，同时软件规模越来越大，功能越来越复杂，使得软件测试在今天仍然面 临着很大的挑战。 1 2 2 软件测试的过程 软件测试过程通常被认为是主要由三个顺序的步骤组成：单元测试，集成 测试和系统测试。 ( 】) 单元测试( u n i tt e s t i n g ) 单元测试完成对软件最小独立单位的正确性验证。单元测试的测试要点 有： 外部接口：有效数据正确的流入和流出 局部数据结构：内部数据的完整性、正确性 边界条件：数据加工的局限条件是否正确 覆盖条件：逻辑条件下的各种覆盖条件的有效性 出错处理：对无效输入数据的处理措施的完整性和有效性 由于被测单元本身不是一个单独的程序，所以必须为每个单元测试开发 驱动程序( d r i v e r ) 或和桩模块( s t u b ) 。通常一个驱动程序只是一个接收 测试数据并把数据传送给被测单元，然后输出相关结果的“主程序”。桩模 块的功能则是通过模拟被测单元的从属模块来辅助被测单元运行。单元测试 第1 章绪论 过程如图卜2 所示。 单元测试的测试用例设计方法为：白盒法十黑盒法+ 经验( c h e c kp o i n t ) 。 通常以白盒法为主，其他方法为辅。 图1 - 2 单元测试示意图 f i g u r e1 2u n i tt e s t ( 2 ) 集成测试( i n t e g r a t e dt e s t i n g ) 集成测试是在对每个单元的单元测试完成后，按照设计的结构图，在把 软件单元逐步组装的过程中同时进行有序的测试。集成测试的目标是发现 和接口有关的问题。 按照集成的方式，集成测试可以分为两种：非增量集成测试和增量集成 测试。非增量集成测试是指在对各个模块进行单元测试后，按照程序结构 图，使用“一次到位”的方法将各个模块连接起来，把连接后的程序当作 一个整体来进行测试。增量集成测试则是指各个模块的集成是逐步实现的。 增量集成测试按照集成的顺序可以分为自顶向下集成测试和自底向上集成 测试。 集成测试的测试用例设计方法为：黑盒法+ 经验( c h e c kp o i n t ) 。如果把 白盒的节点视为局部子系统的最小外部功能，把黑盒视为局部子系统，则 仍为：白盒法+ 黑盒法+ 经验( c h e c kp o i n t ) 。 ( 3 ) 系统测试( s y s t e mt e s t i n g ) 系统测试是对系统整体功能和性能的验证。系统测试的内容主要包括产 5 北京工业大学工学硕士论文 品齐备性( 文档与程序) 、产品功能正确性、产品性能合格性和产品环境一 限制合格性等。 系统测试的参与人员主要有：用户( l e a d e r 直接u s e r 日常维护人员) 、 专业验收单位和开发机构验收部门等。 系统测试的测试要点主要包括： 功能确认：对需求定义的功能进行随机取样测试； 性能确认：对需求定义功能实现程度的验证测试； 环境一限制确认：软硬件环境、设备、条件增减适应性与局限性验 证： 系统测试的测试用例设计方法为：经验( c h e c kp o i n t ) 。 1 2 3 软件测试的方法 从不同的角度，软件测试的方法有不同的分类： ( 1 ) 根据测试过程中程序的执行状态，可以将软件测试方法分为静态测试和 动态测试。 静态测试方法并不真正运行被测程序，只对被测试程序进行特性分 析。因此，静态方法常称为“分析”。 静态分析可以通过人工或自动化两种方式执行。人工静态测试指测 试者对照设计书阅读源程序，查找其中的不一致( 差错) 的测试方法。英 语也称“w a l k t h r o u g h ”，或“d e s kt e s t ”。自动化静态测试是指使用专 门的静态分析系统，按照指定的分析规则，对源程序进行自动化分析。 目前，很多软件测试工具都具备静态分析功能，如j t e s t 等。 动态测试方法是指计算机必须真正运行被测试的程序，通过输入测 试用例，对其运行情况( 输入输出的对应关系) 进行分析。 静态测试的成本大大低于动态测试，对有经验的程序员来说，静态 测试摘除b u g 的比率大大高于动态测试。 ( 2 ) 根据测试的角度是被测试程序的外部还是内部，可以将软件测试方法分 为黑盒测试( b l a c k - b o xt e s t i n g ) 和白盒测试( w h i t e b o xt e s t i n g ) 。 第1 章绪论 黑盒测试又称为数据驱动测试( d a t ad r i v e nt 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 ) ，是一种从用户观点出发 的测试。黑盒测试把被测程序当作一个黑盒，不考虑程序内部结构和内 部特性，测试者依靠程序功能需求规格说明书来确定测试用例和推断测 试结果的正确性。软件的黑盒测试被用来证实软件功能的正确性和可操 作性。 白盒测试又称为逻辑驱动测试( l o g i c a ld r i v e nt e s t i n g ) 或基于 程序的测试( p r o g r a m b a s e dt e s t i n g ) 。采用这- - n 试方法，测试者必 须分析被测程序的内部结构，并根据程序的内部逻辑结构和编码结构来 设计和执行测试用例。白盒测试通常以提高覆盖率为目标设计测试用例， 常见的程序结构覆盖有：语句覆盖，判定覆盖，条件覆盖，判定条件覆 盖等等。 黑盒测试和白盒测试二者的测试侧重点不同，使用的场合也有差别。 通常在进行单元测试时大多会采用白盒测试，而在系统测试时则一般采 用黑盒测试。 1 2 4 软件测试的自动化 由于软件测试的工作量很大( 据统计，会用到4 0 的开发时间：一些可靠 性要求非常高的软件，测试时间甚至占到总开发时间的6 0 ) ，而且测试过程中 很多操作都是重复性的、非创造性的工作，因此，可以将软件测试的部分操作 实现自动化，由计算机代替人来完成这部分工作。 自动化测试有很多优点，如： ( 1 ) 可以大大减少回归测试的开销； ( 2 ) 可以在更短的时间内完成更多的测试； ( 3 ) 可以完成一些手工测试不能或难以完成的测试，如压力测试、并发测试 等； ( 4 ) 具有一致性和可重复性； ( 5 ) 可以更好地利用资源：可以利用晚上或周末的时间运行测试；还可以使 北京工业大学i 学硕士论文 测试人员解脱出来，将精力投入到测试设计等其他创造性的测试工作中 去： ( 6 ) 可以增加软件信任度； 但是，自动化测试也存在着一些局限性，如： ( 1 )自动化测试不能完全取代手工测试 对于某些涉及感官方面的测试如界面的美观等测试必须通过手工来 进行测试；对于运行测试很少的测试，由于自动化测试的建立需要较大 的开销，所以如果使用自动化测试则是一种浪费。 ( 2 )自动化测试不能提高测试的有效性 自动化测试只是机械地执行规定的测试操作，因此它不会比手工运 行同样的测试更有效。自动化测试只能提高测试的效率。 ( 3 ) 工具本身不具备人的能动性和想象力 测试的参照物是需求规格说明书和系统设计书，工具无法从文档中 得到测试用例，也无法按照需求说明书来对测试结果进行验证。 ( 4 ) 测试自动化可能会制约软件开发 只有将设计好的测试用例实现为工具能够识别的测试脚本并准备好 测试数据和测试环境后，测试自动化才能够得以实现。这些工作的开销 通常比较大，而且在软件变更后，测试脚本和测试环境也需要相应的维 护，这些都有可能会限制软件系统的修改或改进。 1 3 本课题的主要研究内容 在再工程过程中，测试工作比例远大于一次软件工程。正确、合理地实施 自动化测试，能够快速、彻底地对软件进行测试，从而提高软件质量，节省经 费，缩短产品开发周期。 本课题的研究内容包括： ( 1 )对w e b 再工程测试过程进行了研究，提出了适合w e b 再工程的测试过 程模型，为w e b 再工程测试实践提供了理论指导。 ( 2 )对w e b 再工程测试自动化解决方案进行了研究。w e b 再工程测试自动 第1 章绪论 化解决方案对测试过程进行自动化的管理与控制，使测试过程能够在 一个统一的环境下，按照统一的标准，基于可靠的定量化的数据来进 行。另外，w e b 再工程测试自动化解决方案通过集成各种测试支援工 具为w e b 再工程测试的各个阶段提供计算机辅助测试，通过测试管理 工具以及测试管理工具和测试支援工具的集成，实现测试管理数据的 自动采集，对测试过程进行管理。 ( 3 )给出了一个w e b 再工程测试自动化解决方案( t p 2 j ) 的设计。该解 决方案用于对c s 结构向b s 结构转化( 既存系统开发语言为p b ，升 级后的目标系统为j s p s e r v l e t + j a v a b e a n s 体系结构) 的w e b 再工 程测试过程进行辅助支持。在t - p 2 j 解决方案中，不但集成了一些已 有的优秀测试工具，还开发了两个w e b 再工程测试辅助工具：用于静 态测试的程序对比工具和用于动态测试的测试数据自动生成工具。 ( 4 )最后，本文以z c r w 项目为例介绍了w e b 再工程测试自动化解决方案 的实际应用情况。 1 4 本文的组织结构 在绪论中阐述了软件再工程的定义和现状、软件测试技术和测试自动化以 及课题的主要研究内容和本文组织结构。在第2 章中，在对一次工程的测试模 型和再工程测试的特点的研究基础上，提出了w e b 再工程测试过程模型。第3 章则对w e b 再工程测试自动化解决方案进行了研究，内容包括总体需求说明、 系统目标和主要任务等等。第4 章介绍了一个w e b 再工程测试自动化解决方案 t - p 2 j 的设计。第5 章介绍了在t p 2 j 解决方案中新开发的两个工具，分别是 测试数据自动生成工具( t d c ) 和程序对比工具( c e t ) 。第6 章介绍了w e b 再工 程测试自动化解决方案在z c r w 项目中的应用。第7 章中对本课题进行了总结和 评价，并展望其发展前景。 第2 章w e b 再工程测试过程模型母 究 第2 章f f e b 再工程测试过程模型研究 在软件开发几十年的实践过程中，人们总结了很多的开发模型，比如瀑布 模型、原型模型、螺旋模型、增量模型、渐进模型、快速软件开发( r a d ) 以及 r a t i o n a l 统一过程( r u p ) 等，这些模型对于软件开发过程具有良好的指导作 用。 但是，由于这些开发模型中没有充分强调测试的价值，也没有给测试以足 够的重视，因此利用这些模型无法更好地指导测试实践。所以，软件测试专家 又在测试实践的过程中总结出了一些测试模型，如v 模型、w 模型等等。而这 些模型往往都是针对一次工程，不能够很好地适用于再工程。本章将根据w e b 再工程测试的特点提出一个能够指导w e b 再工程测试实践的测试模型。 2 1 一次工程测试模型概述 人们在对软件测试方法学进行研究的过程中，提出了许多软件测试模型。 下面对主要的测试模型做一简单的介绍“。 2 1 1y 模型 v 模型是最具有代表意义的测试模型。如图2 - 1 所示。v 模型是软件开发瀑 布模型的变种，它反映了测试活动与分析和设计的关系，从左至右，描述了基 本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并 且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。如模型图所 示，图中的箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应 的是右边上升的部分，即测试过程的各个阶段。 v 模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、 详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后一个 阶段，主要是针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到 后期的验收测试才被发现。 1 f 北京工业大学工学硕士论文 2 1 2w 模型 图2 - i 软件测试v 模型 f i g u r e2 - is o f t a r et e s tv - n m o d e l v 模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和不 断地进行软件测试”的原则。根据该原则，在需求和设计阶段的测试应该遵循 i e e es t d1 0 1 2 1 9 9 8 软件验证和确认( v v ) 的原则。在v 模型中增加软件 各开发阶段应同步进行的测试，被演化为一种w 模型。如图2 2 所示。 w 模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序， 需求、功能和设计同样要测试。这样，只要相应的开发活动完成，我们就可以 开始执行测试，从而有利于尽早发现问题。 根据w 模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写 测试用例，这些工作对测试的各个级别都有意义。当需求被提交后，就需要确 定高级别的测试用例来测试这些需求。当概要设计编写完成后，就需要确定测 试条件来查找该阶段的测试缺陷。 w 模型也有其局限性。和v 模型一样，它也把软件的开发视为需求、设计、 编码等一系列串行的活动。同样的，软件开发和测试保持一种线性的前后关系， 第2 章w e b 再工程测试过程模型研究 需要有严格的指令表示上一阶段完全结束，才可以正式开始下一阶段。这样就 无法支持迭代、自发性以及变更调整。 2 1 3h 模型 图2 - 2 软件测试w 模型 f i g u r e2 - 2s o f t w a r et e s tw - m o d e l v 模型和w 模型都存在不妥之处。首先，它们都把软件的开发视为需求、 设计、编码等一系列串行的活动。而事实上，虽然这些活动之间存在相互牵制 的关系，但在大部分时间内，它们是可以交叉进行的。因此，相应的测试之间 也不存在严格的次序关系。其次，v 模型和w 模型都没有很好地体现测试流程 的完整性。 为了解决以上问题，有专家提出了h 模型。它将测试活动完全独立出来， 北京工业大学工学硕士论文 形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。 图2 - 3 演示了在整个生产周期中某个层次上的一次测试“微循环”。图中的 其他流程可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非 开发流程，如s q a 流程等。也就是说，只要测试条件成熟了，测试准备活动完 成了，测试执行活动就可以( 或者说需要) 进行了。 概括地说，h 模型揭示了： 软件测试不仅仅指测试的执行，还包括很多其他的活动； 软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发 地进行； 软件测试要尽早准备，尽早执行； 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可 以是按照某个次序先后进行的，但也可能是反复的。 测试准备测试望警点 测试执行测试流程 双卜+ ：、 ： ： ：其他流程( 如设计流程) ：一一j 一 图2 - 3 软件测试h 模型 f i g u r e2 - 3s o f t w a r et e s th - m o d e l 2 2 再工程测试过程模型 经过对一次工程测试过程模型的分析，我们必然会提出这样一个疑问：什 么样的测试模型是适合再工程的呢? 这一节我们将就这个问题进行讨论。 2 2 1 软件再工程测试的特点 在再工程的实践工作中，我们总结得到，跟一次工程测试相比，再工程测 试总体上具有以下几个主要特点： 1 4 第2 章w e b 再工程测试过程模型研究 ( 1 ) 再工程匿对的首先不是原始需求，而是既存软件，是从既存软件出发开 发出新软件的过程。因此，缺少完整的需求规格说明书是再工程测试首 先要面对的一个问题。 虽然没有需求规格说明书，但是通常对于再工程来说，在一次工程中最 常见也最令人头疼的需求不明确的问题却往往不存在，这是因为软件的 原型( 既存系统) 已经存在了。这对于测试人员来说，无疑也是一个极 大的福音。 在再工程过程中，通常会伴随着大量的重构活动的进行，因此相对于一 次工程，再工程对于测试自动化尤其是单元测试自动化的需求更为强烈。 由于再工程的范围广阔，种类繁多，因此通常不同的再工程类型( 模式) 有不同的测试内容或测试重点。比如属于开发环境适应性维护 ( p o w e r b u i l d e r 、v b 、v c 、e x c e l 等开发环境的版本升级) 的这一类再工 程，由于通常没有涉及到体系结构的重构，所以测试的重点大多集中在 单元测试和功能测试等，有时甚至可以把这类再工程测试当作是对既存 系统进行修改后的一种回归测试。而对于某些运行环境适应性维护如将 既存客户机朋艮务器系统重构为基于i n t r a n e t 的w e b 系统的再工程则由 于重构的范围牵涉到体系结构重构、代码重构、数据重构等等，则测试 的内容也相对较多，通常会涉及到一次工程测试的绝大部分测试类型。 2 2 2w e b 再工程测试过程模型 通过对再工程测试特点的研究我们可以发现，由于再工程类型( 模式) 的 多样性，我们很难定义出一个通用的再工程测试过程模型能够适用于所有的再 工程测试过程。因此，我们只能从模式化的思路针对某一种具体的再工程类型 提出再工程的测试模型。在本课题中，我们将主要对目前需求比较多的w e b 再 工程过程进行研究。 我们知道，一次软件工程的过程是：需求一 设计一 既存系统；而w e b 再工 程的过程则是：既存系统一 设计一 w e b 系统。其中“既存系统一 设计”为逆向 工程过程，“设计+ 新需求一 w e b 系统”为正向工程过程。一次工程、w e b 再工程 ) ) ) 北京工业大学工学硕士论文 和正向工程的关系如图2 4 所示。 图2 - 4 一次工程、w e b 再工程和正向工程的关系 f i g u r e2 - 4t h er e l a t i o na m o n gf i r s te n g i n e e r i n g ， w e br e e n g i n e e r i n ga n d f o r w a r de n g i n e e r i n g 从图2 4 中我们可以清晰地看到，一次工程过程和w e b 再工程过程两者在 正向工程阶段达到了重合。也就是说，w e b 再工程过程从设计阶段往后的过程 跟一次工程是相同的。相应的，次工程中在设计阶段往后的各个阶段对应的 测试阶段也是可以应用到w e b 再工程的。于是，我们可以得到一个w e b 再工程 的测试过程的v 模型，如图2 5 所示。 第2 章w e b 再工程测试过程模型研究 图2 - 5w e b 再工程测试v 模型 从图2 5 我们看到，不但正向工程各阶段的测试过程在模型中得到了体现， w e b 再工程的系统测试的特点一可以利用同既存系统进行对比来进行测试一也 得到了体现。 另外，由于既存系统的存在，w e b 再工程的绝大部分需求都可以从既存系统 中得到明确，因此，v 模型最大的弊端一不能适应需求不明确的情况一在w e b 再工程过程中也基本上不存在了。 2 3 本章小结 本章先对一次工程的常见测试过程模型进行了讨论，随后在w e b 再工程过 程模型的基础上对w e b 再工程测试过程模型进行了探讨，在对一次工程测试v 模型的改进的基础上结合w e b 再工程的特点提出了一个适用于w e b 再工程的测 试v 模型。 第3 章w e b 再t 程测试自动化解决方案研究 第3 章w e b 再工程测试自动化解决方案研究 研究软件工程方法学的目的是使开发过程“纪律化”，就是要寻找一些规范 的过程，使开发工作能够有步骤、有计划地进行。但是，如果没有好的软件工 程支撑环境，再好的方法论也只能是一些美好的愿望。俗话说得好：工欲善其 事，必先利其器，往往有了好的工具就能收到事半功倍的效果，否则只能寸步 难行。 在上一章对w e b 再工程测试过程模型的基础上，本章将对w e b 再工程测试 自动化解决方案进行研究。 3 1 总体需求说明 在第2 章中我们对再工程测试的特点进行了分析，再工程测试的这些特点 给测试活动的实施和管理都带来了新的挑战。 首先，由于再工程种类繁多，各具特点，由此带来了再工程测试模式的多 样性，每一种测试模式的过程、方法以及所用的工具可能都会不一样，这给再 工程测试的管理带来了很大的难度。 其次，由于再工程测试与一次工程测试存在着很大差异如缺乏需求规格说 明书等，因此很多一次工程测试的方法和工具都不一定能适用于再工程测试。 这就给再工程测试人员在测试过程、方法和工具的选择上带来了很大的困惑。 第三，软件再工程的测试工作比例远大于一次工程。如果不对再工程测试 方法学进行研究，提高测试效率，测试将会逐渐成为再工程的瓶颈。 综上所述，有必要从模式化的角度出发，针对不同模式的再工程提供对应 的测试自动化解决方案，不仅通过自动化来提高测试的效率，更能使测试的过 程、方法和工具等资源都能够得到有效的重用。 本课题主要是研究面向w e b 化再工程的测试自动化解决方案。 北京工业大学工学硕士论文 3 2 系统目标 根据上一节所述的需求，w e b 再工程测试自动化解决方案有如下目标： 3 2 1 为测试各个阶段提供测试工具 将众多的测试实施工具和测试管理工具组成“工具箱”，在软件开发的各个 阶段，都提供相应的测试工具对测试进行辅助支持。这样不但可以实现工具的 重用，还可以为测试者选择好合适的工具，免除了测试者在众多的测试工具面 前无所适从的局面。 3 2 2 对测试过程进行自动化的管理与控制 经验表明测试自动化的好处只有在良好的测试过程下才能很好的体现。没 有过程管理的测试活动就好像软件开发不按照开发过程进行一样。测试过程管 理提供一个框架或者过程使得测试可以得到管理和控制。 w e b 再工程测试自动化解决方案对w e b 再工程的测试过程进行管理与控制， 使w e b 再工程测试按照解决方案内部预置的w e b 再工程测试过程模型逐个阶段 有序的进行，并且对每个阶段采用的测试方法、测试工具以及需要达到的目标 都作出明确的规定，保证了测试的标准性和可靠性。 为尽量减少人为因素对测试过程控制的干扰，应该尽量实现测试管理数据 的自动采集，保证管理数据的实时性与真实性。 3 2 3 实现测试资源的重用 能够将每一次测试过程中的资源和经验保存下来，以便下一次测试时重用。 由于再工程的测试工作量非常巨大，因此测试数据、测试用例等测试资源的重 用具有非常重要的意义。 第3 章w e b 再工程测试自动化解决方案研究 3 3 主要任务 要实现上述目标，需要完成以下任务： 3 3 1 测试过程管理模块的设计与开发 测试过程管理模块对测试过程进行管理与控制，控制的手段是通过事先设 定好测试过程的每个阶段的入、出口的基准以及测试过程中数据的采集点，然 后在测试过程中对采集到的数据来进行分析与计算，判断是否能够从一个阶段 进入到下一个阶段。 3 3 2 测试工具的集成 3 3 2 1 集成工具的种类 通常来说，我们可以把所有能够为软件测试活动提供辅助支持的工具简单 地划分为以下两种： ( 1 ) 测试支援工具：指为测试过程中各阶段提供测试辅助支持的自动化测试 工具，如单元测试环境模拟工具、测试用例辅助生成工具、测试覆盖率 监视工具等等。 ( 2 ) 测试管理工具：指为测试活动中的计划、人员、任务、测试用例以及b u g 等进行管理提供辅助支持的工具。 3 3 2 2 选取工具的原则 目前，测试支援工具的种类繁多，从商业工具到开源工具，各种各样的工 具应有尽有，各具特色。我们根据w e b 再工程测试自动化解决方案的特点与需 求，主要从功能、成本、可集成性等角度出发，制定了选择集成哪些工具时的 几个原则： ( 1 ) 工具满足需求或通过一定的改造后能够满足需求； ( 2 ) 如果有现成的则尽量使用现成的，或者将已有的进行改造。只有找不到 2 】 北京工业大学工学硕士论文 现成的工具或改造成本过大，才从头开发新工具； ( 3 ) 优先选择北京工业大学软件工程研究所自主研发的工具； ( 4 ) 对于功能相同的商业工具与开源工具，首选开源工具； 3 3 2 3 工具集成的主要工作内容 要将一个现有的工具集成到w e b 再工程测试自动化解决方案中，主要有两 个方面的工作需要完成： ( 1 ) 工具的组件化封装： 对工具进行组件化封装，使其符合a s v 的p l u g i n 接口。对于这一 过程，在我的上届同学楼燕青的论文面向领域模式的组件化再工程整 体解决方案研究中进行了具体的阐述，本文就不再赘述。 ( 2 ) 测试过程数据格式的标准化转换： 对于不同的测试工具，它在运行中产生的过程数据的格式都是不同 的，工具之间并没有统一的数据格式标准。这样就给测试工具之间的数 据共享和测试管理工具的数据自动化采集工作造成了极大的困难。 因此，工具集成的一个重要工作就是针对每一个测试工具，编写一 个格式转换模块，将各个测试工具的过程数据转换成统一的标准格式， 以便于数据共享和管理数据的自动化采集。 图3 - i 显示了w e b 再工程测试自动化解决方案中测试过程数据的格 式转换过程： 第3 章w e b 再工程测试自动化解决方案研究 o0o o0 标准数据格式 o ooo o00 图3 一l 测试过程数据的格式转换过程 f i g u r e3 - 1t h ep r o c e s so fd a t af o r m a tt r a n s i t i o n 3 4 本章小结 本章对w e b 再工程测试自动化解决方案的总体需求、系统设计目标和要完 成的主要任务进行了阐述。 第4 章w e b 再工程测试自动化解决方案设计 第4 章w e b 再工程测试自动化解决方案设计 在目前的w e b 再工程领域中，比较常见的w e b 再工程模式是集中式体系结 构向b s 的三层体系结构的转化和c s 两层体系结构向b i s 三层体系结构的转 化。 本章讨论的就是一个c s 结构向b s 结构转化( 既存系统开发语言为p b ， 升级后的目标系统为j s p s e r v l e t + j a v a b e a n s 体系结构) 的w e b 再工程测试 自动化解决方案。我们称之为t - p 2 j 。 4 1 设计思路和体系结构 4 1 1a s - v 简介 a s - v 是软件工程研究所独自研究和开发的面向模式的软件再工程自动化 解决方案集成平台。a s - v 以面向模式的思路将软件再工程过程中的所用到的工 具、经验和资源等积累下来，并以解决方案的形式有机组织起来，为以后的软 件再工程过程所重用。a s v 平台是c s 结构的、可即插即用的、支持团队协作 开发的集成开发环境。其体系结构如图4 - 1 所示： 北京工业大学工学硕士论文 图4 - 1a s v 体系结构图 f i g u r e4 - 1a s va r c h i t e c t u r e 4 1 2 与a s v 的