（系统分析与集成专业论文）命令行程序测评框架的研究与应用.pdf

摘要 随着现代信息技术的迅速发展，计算机技术在金融、航天、通讯等各个行业 的广泛应用，对软件系统性能和稳定性要求越来越高。同时，软件开发周期不断 缩短，而软件系统却日益庞大。在此情况下，软件产品质量自然成了开发商关注 的焦点 仅仅依靠以密集劳动为特征的传统手工测试，已经不能满足快节奏软件开发 和测试的需求。自动化为测试为此提供了成功解决方案。自动化测试是测试体系 中新发展起来的一个分支。实施正确合理的自动化测试能够分担手工测试特别是 回归测试的工作量，降低性能测试的难度，从而在保证软件质量的前提下缩短 测试周期，降低软件成本。 阐述了自动化测试相关概念和理论，概括和比较了其适用范围、工具分类和 组织结构，进而以自动化为主线贯穿软件测试过程中的单元级别测试、系统级别 功能则试和性能测试，深入分析了多种自动化关键原理和技术，然后结合现代企 业级软件开发的特点，根据自动化测试的设计原和不同阶段采用的自动化测试技 术，扶单元、系统和性能测试角度构建了企业自动化测试框架：最后以一个命令 行测试框架证明了自动化测试在企业级应用开发中的实用性。 关键字：命令行：测试；框架；自动化 a b s t r a c t r e c e n t l y , w i t ht h er a p i dd e v e l o p m e n to fm o d e mi n f o r m a t i o nt e c h n o l o g y , t h e w i d ea p p l i c a t i o no fc o m p u t e r si nm a n yi n d u s t r i e ss u c hf i n a n c e ，a e r o i n d u s t r ya n d c o m m u n i c a t i o ni n d u s t r y , i tb r i n g sm o r en e e do ft h ep e r f o r m a n c ea n ds t a b i l i t yf o r s o f t w a r es y s t e m a tt h es a m et i m e ，t h ep e r i o do fs o f t w a r ed e v e l o p m e n ti sb e c o m i n g s h o r tb u tt h es o f t w a r es y s t e mi sb e c o m i n gm o r ec o m p l e xt h a nc v c lt h eq u a l i t yo f s o f t w a r eu n d e rs u c hp r e s s u r ei sk e yp o i n tf o re n t e r p r i s e st oa c h i e v es u c c e s s i no r d e rt od om o r ew i t hl e s s ，o r g a n i z a t i o n sw a n tt ot e s tt h e i rs o f t w a r eb e t t e ra n d m o r eo f t e nw h i l ef a s t e ra n dc h e a p e rd e p e n d i n go no n l ym a n u a lt e s t ，w h i c hf e a t u r e d b yl a b o r - i n t e n s i v e , c o s t l ya n dt i m e - c o n s u m i n g , c o u l dn ol o n g e rm e e tt h e s en e e d s a u t o m a t e dt e s t i n g , ar i s i n gt e c h n i q u ei nu l t i m a t em e a n st ot h i se n d i fe m p l o y e d c o r r e c t l ys o f t w a r et e s t i n gi n d u s t r y , i st h ei tc o u l dl a k eo v e rag r e a ta m o u n to fh e a v y w o r kf i o mm a n u a lt e s t i n g , e 昌，i nr e g r e s s i o nl e s ta n dp e r t b r m a n c el e s th e n c es h o r t e n t h e s o f t w a r eq a l i f e c y c l ea n dc u tt h ec o s t ，w i t h o u tl o s i n gh i g hq u a l i t yo fp r o d u c t i n t h i sp a p e r , c o n c e p t sa n dt h e o r i e sr e l a t e dw i t ha u t o m a t e dt e s t i n gw e r ef i r s t d i s c u s s e d t h e nw i t ht h ec u eo fa u t o m a t i o n , k e yt e c h n i q u e sw i t h i nu n i tt e s t ，s y s t e m t e s ta n dp e r f o r m a n c et e s tp h a s e ，i n c l u d i n gd a i l y n i g h t l yb u i l d , c a p t u r e r e p l a y , o b j e c tr e c o g n i t i o n , d a t a d r i v e n ，k e y w o r dd r i v e na n dp e r t b r m a n c ep r o f i l i n gw e r e a n a l y z e di nd e p t h f u r t h e r , f o l l o w i n g i h ea u t o m a t e dt e s t i n gd e s i g np r i n c i p l e ，a l l e n t e r p r i s e a u t o m a t i o nt e s tf r a m e w o r ki sc o n s t r u c t e df i o mt h ea b o v et h r e e p e r s p e c t i v e s f i n a l l y , t h ep r a c t i c ei nac o m m a n d l i n et e s tf r a m e w o r kp r o v e dt h a t t h e p r a c t i c a b i l i t yi nt h ed e v e l o p m e n to fe n t e r p r i s ei n f o r m a t i o ns y s t e m k e yw o r d s ：c o m m a n d l i n e ；t e s t ；f r a m e w o r k ；a u t o m a t i o n 湖北大学学位论文原创性声明和使用授权说明 原创性声明 本人郑重声明：所呈交的论文是本人在导师的指导下独立进行研 究所取得的研究成果。除了文中特别加以标注引用的内容外，本论文 不包含任何其他个人或集体已经发表或撰写的成果作品。对本文的研 究做出重要贡献的个人和集体，均已在文中以明确方式标明。本人完 全意识到本声明的法律后果由本人承担。 论文作者签名：王遂 隰2 呷年步月争日 学位论文使用授权说明 本学位论文作者完全了解学校有关保留、使用学位论文的规定，即： 按照学校要求提交学位论文的印刷本和电子版本；学校有权保存并向国 家有关部门或机构送交论文的复印件和电子版，并提供目录检索与阅览服 务；学校可以允许采用影印、缩印、数字化或其它复制手段保存学位论文； 在不以赢利为目的的前提下，学校可以公开学位论文的部分或全部内容。( 保 密论文在解密后遵守此规定) 作者签名：互箍 指导教师签名：劣乡， 日期：沙哆6 _ 甲 吼叩川 第一章软件质量和软件测试概论 第一章软件质量和软件测试概论 1 1 软件质量概述 信息技术的飞速发展，使软件产品应用到社会的各个领域，软件产品的质量自然成 为人们共同关注的焦点。不论软件的生产者还是软件的使用者，均生存在激烈竞争的环 境中，软件开发商为了占有市场，必须把软件质量作为企业的重要目标之一，以免在激 烈的竞争中被淘汰出局。用户为了保证自己业务的顺利完成，当然希望选用优质的软件。 质量不佳的软件产品不仅会使开发商的维护费用和用户的使用成本大幅增加，还可能产 生其他的责任风险。在一些关键应用( 如民航订票系统、银行结算系统、证券交易系统 等冲使用质量有问题的软件，还可能造成灾难性的后果。 软件质量是指与软件产品满足规定的和隐含的需求的能力有关的特征和特性的全 体。通常来说，软件质量应该包含六方面的特性； ( 1 ) 功能性：软件所实现的功能达到它的设计规范和满足用户需求的程度； ( 2 ) 可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度； ( 3 ) 易使用性：对于一个软件，用户学习、操作、准备输入和理解输出所作努力的 程度； ( 4 ) 效率：在指定条件下，用软件实现某种功能所需的计算机资源( 包括时 间) 的有效程度； ( 5 ) 可维护性：在一个运行软件中，当环境改变或软件发生错误时，进行相 应修改所做努力的程度； ( 6 ) 可移植性：软件从一个计算机系统或环境移植到另一个系统或环境的容 易程度 软件质量是一个软件企业成功的必要条件，其重要性无论怎样强调都不过分。软件 质量与传统意义上的质量概念并无本质差别，只是针对软件的某些特性 进行了调整 1 2 软件测试 软件危机曾经是软件界甚至整个计算机界最热门的话题。为了解决这场危机，软件 从业人员、专家和学者做出了大量的努力。现在人们已经逐步认识到所谓的软件危机实 湖北大学硕士学位论文 际上仅是一种状况，那就是软件中有错误，正是这些错误导致了软件开发在成本、进度 和质量上的失控。有错是软件的属性而且是无法改变的，因为软件是由人来完成的， 所有由人做的工作都不会是完美无缺的。问题在于我们如何去避免错误的产生和消除己 经产生的错误。使程序中的错误密度达到尽可能低的程度 1 2 1 软件测试的概念 软件测试的定义有许多种，其中比较权威的是i e e e 在1 9 8 3 年提出的：“使用人工 或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是 弄清预期结果与实际结果之间的差别。” 1 2 2 软件测试的重要性 软件测试在软件生命周期中占据重要的地位，在传统的瀑布模型中，软件测试学 仅处于运行维护阶段之前，是软件产品交付用户使用之前保证软件质量的重要手段。近 来，软件工程界趋向于一种新的观点即认为软件生命周期每一阶段中都应包含测试， 从而检验本阶段的成果是否接近预期的目标，尽可能早的发现错误并加以修正，如果不 在早期阶段进行测试，错误的延时扩散常常会导致最后成品测试的巨大困难 事实上，对于软件来讲，不论采用什么技术和什么方法，软件中仍然会有错。采 用新的语言、先进的开发方式、完善的开发过程，可以减少错误的引入。但是不可能完 全杜绝软件中的错误，这些引入的错误需要测试来找出，软件中的错误密度也需要测试 来进行估计。测试是所有工程学科的基本组成单元，是软件开发的重要部分。自有程序 设计的那天起测试就一直伴随着。统计表明，在典型的软件开发项目中，软件测试工作 量往往占软件开发总工作量的4 0 以上。而在软件开发的总成本中，用在测试上的开 销要占3 0 到5 0 。如果把维护阶段也考虑在内，讨论整个软件生存期时，测试的成 本比例也许会有所降低，但实际上维护工作相当于二次开发，乃至多次开发，其中必定 还包含有许多测试工作。 在实践中，软件测试的困难常常使人望而却步或敷衍了事，这是由于对测试仍然存 在一些不正确的看法和错误的态度。这包括： ( 1 ) 认为测试工作不如设计和编码那样容易取得进展，难以给测试人员某种 成就感； ( 2 ) 以发现软件错误为目标的测试是非建设性的，甚至是破坏性的，测试中 2 第一章软件质量和软件测试概论 发现错位是对责任者工作的一种否定； c 3 ) 测试工作枯燥无味，不能引起人们的兴趣； ( 4 ) 测试工作是艰苦而细致的工作； ( 5 ) 对自己编写的程序盲目自信，在发现错误后，顾虑别人对自己的开发能 力的看法 这些观点对软件测试工作是极为不利的，必须澄清认识、端正态度，才可能提高软 件产品的质量。 1 2 3 软件测试的目的 如果测试的目的是为了尽可能多地找出错误，那么测试就应该直接针对软件比较复 杂的部分或是以前出错比较多的位置。如果测试目的是为了给最终用户提供具有一定可 信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设。 在谈到软件测试时，许多人都引用g r e n f o r dj m y e r s 在( t h e a r to f s o t h m et e s t i n g 一书中的观点： ( 1 ) 软件测试是为了发现错误而执行程序的过程； ( 2 ) 测试是为了证明程序有错，而不是证明程序无错误： ( 3 ) 一个好的测试用例是在于它能发现至今未发现的错误； ( 4 ) 一个成功的测试是发现了至今未发现的错误的测试。 这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功 能。但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一 目，查找不出错误的测试就是没有价值的，事实并非如此。首先，测试并不仅仅是为了 要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当 前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性 地检测方法，改善测试的有效性。其次，没有发现错误的测试也是有价值的，完整的测 试是评定测试质量的一种方法。【1 5 】 1 3 软件测试的组织与管理 随着软件开发规模的增大、复杂程度的增加，咀寻找软件中的错误为目的的测试工 作就显得更加困难。然而，为了尽可能多地找出程序中的错误，生产出高 质量的软件产品，加强对测试工作的组织和管理就显得尤为重要。 湖北大学硕士学位论文 从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确， 测试的可操作性相对较强。但是，由于测试的依据是规格说明书、设计文档和使用说明 书，如果设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时， 修改的代价是相当昂贵的。因此，较理想的做法应该是对软件的开发过程，按软件工程 各阶段形成的结果，分别进行严格的审查 i 3 1 测试的过程及组织 当设计工作完成以后，就应该着手测试的准备工作了。一般来讲，由一位对整个系 统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合 理的测试用例，以便系统实现后进行全面测试。在开发组将所开发的程序经验证后，提 交测试组，由测试负责人组织测试，测试一般可按下列方式组织： ( 1 ) 首先，测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明 书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写 测试计划，设计测试用例，作好测试前的准备工作。 ( 2 ) 为了保证测试的质量，将测试过程分成几个阶段，即：代码审查、单元 测试、集成测试、确认测试和系统测试。 ( 3 ) 代码会审 代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。会审小组 在充分阅读待审程序文本、控制流程图及有关要求、规范等文件基础上，召开代码会审 会，程序员逐句讲解程序的逻辑，并展开热烈的讨论甚至争议，以揭示错误的关键所在。 实践表明，程序员在讲解过程中能发现许多自己原来没有发现的错误，而讨论和争议则 进一步促使了问题的暴露。 ( 4 ) 单元测试 单元测试集中在检查软件设计的最小单位模块上，通过测试发现实现该模块的实际 功能与定义该模块的功能说明不符合的情况，以及编码的错误。 ( 5 ) 集成测试 集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有 关的问题。如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题 而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受 的误差可能积累到不能接受的程度：全程数据结构可能有错误等。 4 第一章软件质量和软件测试概论 ( 6 ) 确认测试 确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试 后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本榫除 了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性 能如同用户所合理期待的那样。 ( 7 ) 系统测试 软件开发完成以后。最终还要与系统中其他部分配套运行，进行系统测试。包括恢 复测试、安全测试、强度测试和性能测试等。 经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结 束。经验收后，将软件提交用户 1 3 2 测试的人员组织 为了保证软件的开发质量，软件测试应贯穿于软件定义与开发的整个过程。因此， 对分析、设计和实现等各阶段所得到的结果，包括需求规格说明、设计规格说明及源程 序都应进行软件测试。基于此，测试人员软的组织也应是分阶段的。 ( 1 ) 软件的设计和实现都是基于需求分析规格说明进行的。需求分析规格说明是 否完整、正确、清晰是软件开发成败的关键。为了保证需求定义的质量，应对其进行严 格的审查。 ( 2 ) 设计评审。软件设计是将软件需求转换成软件表示的过程。主要描绘出系统 结构、详细的处理过程和数据库模式。按照需求的规格说明对系统结构的合理性、处理 过程的正确性进行评价，同时利用关系数据库的规范化理论对数据库模式进行审查。 ( 3 ) 程序的测试。程序的测试是指软件测试是整个软件开发过程中交付用户使 用前的最后阶段，是软件质量保证的关键。软件测试在软件生存周期中横跨两个阶段： 通常在编写出每一个模块之后，就对它进行必要的测试( 称为单元测试) 。编码与单元测 试属于软件生存周期中的同一阶段。该阶段的测试工作，由编程组内部人员进行交叉测 试( 避免编程人员测试自己的程序) 。这一阶段结束后，进入软件生存周期的测试阶段， 对软件系统进行各种综合的测试。测试工作由专门的测试组完成，负责整个测试的计划、 组织工作。测试组的其他成员由具有一定的分析、设计和编程经验的专业人员组成，人 数根据具体情况可多可少，一般3 5 人为宜。 5 湖北大学硕士学位论文 第二章测试管理与自动化测试 缺陷管理的目标是要收集缺陷、统计缺陷、处理缺陷，而自动化测试则是要发现 缺陷，用脚本代替人去执行繁琐重复的工作。特别是g u i 功能测试。如果说缺陷管 理是整个测试管理的核心部分，那么自动化测试则是实现这个核心过程中的手段。 2 1 测试管理内容 软件的测试管理包括多方面的内容，从不同的角度划分，可以有不同的集合。从 实施阶段上软件测试管理可以分为软件测试团队组织管理、软件测试计划管理、软件 测试用例管理、软件缺陷( 错误) 跟踪管理这四个部分： c a ) 软件测试团队组织管理：就是应该如何分配测试活动中的角色、组织相关 人员以及促进团队人员之间的知识交流和沟通等。 ( b ) 软件测试计划管理：具体内容涵盖软件测试策划、软件测试技术、测试进 度管理、成本管理等几个部分。其中测试策划工作主要是指具体测试活动实旄之前傲 好策划工作，如制订测试计划：软件测试技术工作主要是指测试团队应根据软件项目 的具体实际制订出所要采用的测试技术；测试进度管理工作主要是指排出各项测试的 时间进度及人员安排：测试成本管理工作的内容即列出测试活动中所涉及到的资 源需求。 ( c ) 软件测试用例管理目的是建立测试人员的用例库。它是测试团队在长期实 践过程中逐步积累起来的测试经验、测试工具、规格文档。测试用例库管理工作做得 越好，测试团队在实际测试过程中就能越少走弯路，测试团队内部的知识交流和传递 就越充分，测试用例或规格文档的重复开发工作也就能被有效地避免。 ( d ) 软件缺陷跟踪管理就是要确保找到新的缺陷并报告给缺陷管理系统、检查 缺陷的状态、所发现的缺陷是否都己经被开发团队纠正或处理过，并且没有引入新的 缺陷错误等等。通常这个过程称为回归测试。回归测试如发现问题，继续通过交流平 台报告给开发团队，按上述流程循环，直至回归测试最终通过。 从测试阶段上来分，测试管理包括： ( a ) 测试计划：根据项目的工期和成本的要求来给测试分配时间和资源，是对 整个测试过程的把握和对测试阶段所需时间的估计。 ( b ) 测试方案：根据软件质量应该达到的要求和测试计划的要求确定测试的方 6 第二章测试管理与自动化测试 法、步骤和周期，规定测试环境，设计测试用例和准备测试数据等。 ( c ) 测试实施和缺陷跟踪：依照测试方案进行测试并填写测试记录以便缺陷 跟踪。 f ( d ) 测试总结与报告：对测试过程中发现的问题的总结，使项目管理人及时发 现问题、解决问题的前提，同时也是测试经验的积累。从设计的角色上分，包括六种 角色的人员：项目管理人员、测试负责人员、测试用例编写人员、配置管理人员、测 试实施人员和软件开发人员。项目管理人需要掌握测试的质量和控制测试的时间。测 试负责人需要制定测试方案和编写测试报告。测试用例编写人需要编写测试用例。配 置管理人需要完成实际的测试工作并填写测试报告。软件开发人需要根据测试发现的 问题列表来维护编码 2 2 测试管理的过程 测试管理过程主要包括：测试方案管理、用例管理、流程管理、缺陷管理和测试 报告管理等部分，如下图所示： 测试对象 图2 i 测试流程 其中测试方案管理的内容为：单元测试、集成测试和系统测试的测试计划的录入、 修改、删除、查询和打印。设计测试用例，准备测试数据。需求变更管理：修改测试 用例和测试数据，记录测试日志。测试用例管理：建立用例库，对测试用例的增、删、 改、拷贝和查询以及对缺陷的追踪，例如查询测试状态包括：己提交，己分配，修改 中，待验证等，除此之外还包括测试用例的输入、编号和归档等操作 7 湖北大学硕士学位论文 测试流程管理：测试进度管理，测试流程标识，记录测试日志及状态报告以及 对一些边界模糊的用例达成通过，失败标准 缺陷管理：测试中的缺陷处理流程、缺陷登记、缺陷分配、缺陷修复、缺陷复测、 缺陷查询、缺陷统计分析以及缺陷与测试用例的关联。 测试报告管理：追踪统计缺陷。生成单元测试、集成测试和系统测试的测试报告。 此过程中的关键环节为测试用例管理和缺陷管理，它们的实施对于项目测试的实 旌、测试质量、效率的提高有着重要的作用。 2 3 缺陷管理 缺陷管理是测试管理过程中的一个核心部分，测试的目的是为了尽早发现软件系 统中的缺陷，因此，对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处 理是测试工作的一项重要内容。 2 3 1 缺陷的描述 软件缺陷( 也称“b u g ”) 是任何可以影响到程序完整而有效地满足用户要求的错误 的总称。例如语法错误、拼写错误、标点错误，或者是一个不正确的、冗余的程序语 句或有缺陷的程序段。缺陷可能出现在程序中、设计中，甚至出现在需求规格说明或 其他文档中。软件缺陷不仅影响用户使用，而且是经费超支和时间延期的主要原因。 但软件缺陷是客观存在的，没有哪个软件产品是没有缺陷的。 从来源上讲。软件缺陷3 6 - - - 3 9 来自软件实现阶段，6 1 - - 6 4 来自软件分析设 计阶段，也就是说编程阶段并不是软件缺陷的唯一来源，甚至不是主要来源。为什么 软件分析设计阶段会引起很多的缺陷昵? 主要有以下几个原因： ( a ) 设计错误。虽然对问题深思熟虑，却做出了错误的设计决定。 ( b ) 知道怎样做设计，但由于疏忽大意，出现了一些简单的错误。 ( c ) 由于不理解需求，而不知道要做什么，设计虽然正确地实现了你认为需要 完成的功能，但所完成的功能并不是系统所需要的。软件测试就是有计划、有设计、 有实现的去发现软件缺陷、改正这些缺陷，从而提高软件可靠性，提高软件质量的活 动。 2 3 2 缺陷的生命周期和管理流程 s 第二章涮试管理与自动化测试 缺陷可以按照生命周期基本分为以下的状态： ( a ) 已提交( s u b m i t t e d ) ：缺陷的初始状态。 ( b ) 己分配( a s s i g n e d ) ：缺陷的等待状态，已分配表示缺陷己有项目经理分配 给相关的开发人员，缺陷周期开始。 ( c ) 修改中( o p e n e d ) ：缺陷的修改状态，正在修改中。 ( d ) 待验证( r e s o l v e d ) ：缺陷的已修改待验证状态，缺陷已经修改了，需要再次 测试验证。 ( e ) 问题重现( r e o p e n e d ) ：缺陷的问题重现状态，缺陷经过回归测试后，尚存 在，需重新修改。 ( f ) 结束( d o s e d ) ：缺陷的问题已解决 ( g ) 拒绝( r e j e c t e d ) ：不认为是缺陷 缺陷的生命周期中还应有以下的角色组成： 测试入员：进行测试的入员，缺陷的提交者 测试经理：对整个测试工作负责，制定测试计划，并确认和分配缺陷。 开发人员：执行修复缺陷的人员 评审委员会：对缺陷进行最终确认，在项目成员对缺陷达不成一致意见时，行使 仲裁权力，一般由需求人员组成 测试人员使用执行用例进行系统测试后( 或外部人员在使用系统中) ，若发现缺 陷则记录下来，并登记在缺陷管理系统中，项目经理对其进行审核。如果不是缺陷， 则拒绝，缺陷状态设置为r e i e c t e d ；如果确认是缺陷，分配给相应的开发人员，设置缺 陷状态为a s s i g n e d ，得到确认的缺陷被“激活”，缺陷进入了生命周期，此时的状态为 待解决，缺陷得到解决后，设置缺陷状态为r e s o l v e d , 测试人员这时会检查缺陷管理系 统，并重新验证，根据问题是否重现，设置缺陷状态，对于不能解决和延期解决的 b u g ，不能由开发人员自己决定，一般要通过某种会议( 如评审会) 通过才能认可。 【6 - 1 2 】 2 3 3 缺陷管理系统的意义 缺陷能够引起软件运行时产生的一种不希望或不可接受的外部行为结果，软件测 试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理具有以下现实意义： ( a ) 确保每个被发现的缺陷都能够被分配处理( 即使在此迭代周期内没有修正， 9 湖北大学硕士学位论文 也要修改该缺陷的状态) 。 ( b ) 收集缺陷数据、并根据缺陷趋势曲线识别测试成果，来确定测试过程是否 结束。 ( c ) 收集缺陷数据并在其上进行数据分析，作为组织的过程财富。一个运行良 好的组织中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件 质量相关的数据。缺陷管理系统不仅实现了缺陷生命状态的控制与转换，使每个缺陷 都能够被全程跟踪和管理，而且采取种种措施加快了缺陷处理的速度，进而提高了开 发人员和管理人员对缺陷生命周期的控制能力。通过缺陷管理系统设置缺陷的级别、 优先级别、重现性、缺陷类型等参数，可以分清软件缺陷的轻重缓急，对于重要豹软 件缺陷，优先进行处理；软件缺陷类型和修改类型参数，能帮助分析错误所在，修改 后分析错误原因，记录修改类型有利于问题的回放和经验的积累。缺陷管理系统可以 监控管理每个缺陷的生命过程，直至解决这个缺陷；而测试人员可以参加缺陷的讨论， 提出处理意见和方法。这样可以最大限度地发挥每一个人的智慧，使缺陷处理进程不 至于被难题耽搁。提高缺陷处理的速度 2 4 自动化测试 手工测试是个劳动密集型的工作，出错率高，成本也较高，不支持那些可能由 自动测试工具完成的相同种类的质量检查。软件自动化测试作为软件测试的一个重要 组成部分，它可以替代许多手工测试繁琐的测试过程，实现手工测试无法实现或者难 以实现的测试。正确、合理的实施自动化测试，能够快速、彻底的对软件进行测试， 从而提高软件质量，节省经费，缩短产品发布周期。基于工具的软件测试技术的自动 化，也是软件测试的发展趋势。引入自动测试工具能够用更有效、可重复的自动测试 环境代替传统的手工测试活动。减少测试开销，增加有限时间内的测试。更加快速地 开发出高质量的软件产品。 在这种形势下，传统的人工测试己经很难满足要求，发展自动化测试成为必然的 趋势，因而基于工具的软件自动测试在软件工程中的应用将会越来越广泛。 2 4 1 动态测试方法的分类 软件测试的方法和技术是多种多样的。对于软件测试技术，可以从不同的角度加 以分类：从是否需要执行被测软件的角度，可分为静态测试和动态测试从测试是否 1 0 第二章测试管理与自动化测试 针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试、黑盒测试和灰盒 测试。 1 ) 黑盒测试 黑盒测试也称功能测试或称数据驱动测试的测试，是一种重要的测试方法，在进 行黑盒测试时，仅把软件当作一个黑盒，并不涉及程序的内部构造一般己知产品所 应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时完全不考虑程 序内部结构和内部特性的情况下，测试者对程序接口进行测试，它只检查程序功能是 否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确 的输出信息，并且保持外部信息( 如数据库或文件) 的完整性。因此黑盒测试是从用 户的观点出发的测试，它是从软件需求出发，根据软件需求规格说明设计测试用例， 并按照测试用例的要求运行被测程序的测试方法。黑盒测试方法主要有等价类划分、 边界值分析、因果图、缺陷推测等，主要用于软件确认测试。黑盒法着眼于程序外部 结构，不考虑内部逻辑结构，针对软件界面和软件功能进行测试。黑盒法是穷举输入 测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有 的缺陷。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对 那些不合法但是可能的输入进行测试。传统意义上的黑盒法是在程序的接口上进行的 测试，主要是为了发现以下几类缺陷： 是否有不正确的或遗漏的功能： 在接口上，输入能否正确的接受，能否输出正确的结果( 界面缺陷) ： 是否有数据结构缺陷或外部信息( 如数据文件) 的访问缺陷： 性能上是否能够满足要求： 是否有初始化或终止性缺陷。 黑盒测试和白盒测试一者的测试侧重点不同，使用场合也有差别。在进行单元测 试时大都采用白盒测试，而在功能测试和系统测试时一般采用黑盒测试。 ( b ) 白盒测试 白盒测试也称结构测试或称逻辑驱动测试。采用这种测试方法，测试者必须有被 测程序的源代码，在进行白盒测试时，它需知道软件( 程序) 的内部机制，通过测试 来检测软件( 程序) 内部机制是否按照规格说明书的规定正常进行，按照程序内部的 结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不管它的 功能。白盒测试要分析程序的内部结构，并根据内部构造结构设计测试用例。因此白 湖北大学硕士学位论文 盒测试是一种按照程序内部的逻辑结构和编码结构设计并执行测试用例的测试方法。 白盒测试的主要方法有逻辑驱动、基路测试等。“白盒”法全面了解程序内部逻辑结 构、对所有逻辑路径进行测试，是一种穷举路径测试。在使用这一方案时，测试者必 须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。不太起眼”的非 主流逻辑路径上可能始终存在。在白盒测试过程中，要求针对程序在特定条件、特定 路径下执行的特殊结构做到尽可能的覆盖，即做到所有独立路径至少执行一次、所有 逻辑判定取“真”和“假”两种情况至少执行一次、在循环的边界和边界内执行循环 体、所有内部数据结构被测试，以确保这些特殊结构执行的有效性和可靠性。动态白 盒测试根据静态测试得到的软件复杂度，推算出代码中独立路径的条数，并依据独立 路径设计测试用例，然后手工或自动地运行被测代码，得到实际代码运行中的各项结 构覆盖率。 ( c ) 灰盒测试 灰盒测试是对软件的规格说明和它的底层实现都进行测试的测试，灰盒测试的一 个目标就是找出软件中的一些独有的奇怪的缺陷。它是将白盒测试和黑盒测试结合起 来形成的一种测试方法，吸收了两种方法的优点。综合上述，白盒测试主要针对开发 人员的单元测试和集成测试，而黑盒测试主要针对功能测试，在系统测试中需要进行 大量的黑盒测试才能完成检验系统功能，找出系统缺陷的任务，但同时，开发人员在 修复缺陷时。仍然需要对代码进行自盒测试。 2 4 2 功能测试的过程 软件测试从软件工程的项目生命周期上可以分为：单元测试、集成测试、系统测 试和验收测试。其中在集成测试和系统测试阶段、按测试的对象不同又可以分为两种； g u i 功能测试和性能测试。 软件功能测试是用来测试软件是否具有满足用户需求的功能，主要使用动态黑盒 测试技术。黑盒测试技术注重于软件的功能错误和遗漏、界面问题、数据计算或外部 数据库访问错误、性能错误、初始化和终止错误等，通过划分程序的输入和输出域来 确定测试用例，功能测试在软件开发的各个阶段甚至在软件发布后的维护或升级中都 相当重要。现在对大型软件的测试一般都使用自动化测试技术。 自动化功能测试的过程主要有脚本的录制、修改和回放三个环节，如图2 - 2 所示： 1 2 第二章测试管理与自动化测试 图2 - 2 功能测试的过程 ( a ) 设计测试案例。主要包括：确定用例执行前所需要的测试环境和先决条件： 确定所要测试的目标；确定对输入数据的要求和期望的输出设计测试案例时应：努 力提高覆盖率，尽量减少执行、调试和结果分析的工作量：减少测试案例的数量、加 强其独立性、并精确地文档化等来加强可维护性。 ( b ) 录制测试脚本。录制测试脚本之前，严格按照测试用例录制测试脚本。 ( c ) 配置数据和优化脚本。大型软件依赖和共享的数据较多，业务流程较复杂， 因此配置数据时要用一份文件详细描述：哪些数据需要引入数据池，如何对全局的、 过程问的参数命名，数据怎样放置和联系优化脚本时往往要设置分支和循环，设置 对象的属性，设置检查点和数据的输出等，以使脚本能按照测试案例的要求适应各种 情况。 ( d ) 执行测试任务，分析并报告测试结果。 2 4 3 录制回放技术 ( 1 ) 实现级别 录制回放技术是在窗口系统的基于消息管理机制的基础上实现的，通过对被测系 统的监控，获得被测系统的运行信息，把用户在被测试的系统上所做的操作和输入按 照时间顺序全部记录在指定的测试脚本中。 以w i n d o w s 操作系统为例，通常这一操作是通过实现w i n d o w ：底层消息处理函 数来完成的。用户在被测试的g u i 上的各种操作实际上最终可以归结产生了键盘消 息和鼠标消息。这样测试工具就可以对这些消息进行捕获，从消息信息中获取被测系 湖北大学硕士学位论文 统的窗口或控件句柄，根据获得的句柄，进一步获得窗1 2 1 或控件的详细信息，然后将 这些信息记录到指定的测试脚本中，完成用户操作的记录。例如：输入文字的时候取 得键盘消息k e y b o a r d - m e s s a g e ，鼠标按下的时候取得鼠标消息m o u s e - m e s s a g e 。对于 用户输入的捕获，g u i 录制回放工具将以三种级别捕获，即硬件级别、操作系统级 别和进程级别。 ( a ) 硬件级别是最低的级别，主要是采用硬件完成对用户输入的录制和回放， 比如鼠标的双击、键盘输入某个字符等。之所以采用硬件进行录制和回放，是出于安 全的考虑，硬件设备可以捕获键盘敲击的键值，从而监控该计算机的使用，或者它可 以加密键盘扫描码，以防止底层恶意代码对计算机的监听 ( b ) 操作系统级别，在这个级别下，录制和回放功能采用软件完成。软件实现 主要是使用本机代码( n a t i v e - c o d e ) 方式调用的系统a p i 函数。操作系统级别的录制 和回放工具主要用于在系统级别对键盘或鼠标的输入进行监控，由于每个g u i 组件 都存在一个在系统级别里可被识别的g l o b a li d ，所以系统级别的录制回放工具可以 从系统级别的输入队列中提取出所需的g u i 组件的输入。但是，在操作系统级别下， 由于是调用系统a p i 完成录制和回放，工具无法做到完全识别j a v a 对象，因为j a v a 对象在必须在j a v a 虚拟机( j v m ) 之上被识别和使用；并且使用本机，a p i 的调用与操 作系统平台相关，使得这种级别的录制和回放工具无法做到很轻巧 ( c ) 进程级别是录制和回放工具对特定的进程进行监控，一般来说，这个级别 的录制回放工具可以采用 + + 或者j a v a 语言实现，并且通过在测试工具中对不同语言 编写的目标程序加挂针对该语言的包，就可以监控大多数语言编写的目标程序，其中 加挂的不同语言包主要是针对这种语言编写的g u i 组件的识别信息。特殊地，对于 j a v a 编写的目标应用程序，同样采用j a v a 编写的进程级录制回放工具来监控会比较 简单有效，因为这样目标程序和测试工具都在j v m 解释下执行，测试工具可以通过 j a v a 语言中的反射机制识别到目标应用程序内部的j a v a 类、成员函数和成员变量， 扩展第一类g u i 录制回放工具的功能。 ( 2 ) 技术类型 g u i 的录制回放( r e c o r d - p l a y b a c k 是g u i 自动化测试使用的主要手段之一，也 是目前主流测试工具的实施方法，当今的g u i 录制回放技术共有三种类型， ( a ) 自动提供对用户手工操作的录制和回放； ( b ) 采用脚本语言模拟用户在被测程序上的操作； 1 4 第二章测试管理与自动化测试 ( c ) 对类型( a ) 和( b ) 的综合 第一类录制回放工具主要用于被测应用程序( 目标应用程序) 的回归测试中，这 类工具需要测试人员第一次人工地进行对g u i 的操作，来完成测试脚本的录制过程， 在录制过程中这类测试工具会首先记录目标应用程序g u i 的组件层次结构和组件自 身的信息，随后会截获测试人员在目标程序g u i 组件上触发产生的事件，随后解析 该事件，得到事件的各个参数，保存到测试脚本中，作为将来回放的依据。测试脚本 多以文本格式存放，主要记录两部分内容，一是目标程序的g u i 组件结构以及组件 自身的属性信息；另一部分就是对测试人员手工操作步骤，也可以理解为对手工操作 引发的事件的记录。回放时，会使用某种脚本语言解析该记录文件，脚本语言可以分 为两大类：外部类型和交互类型。外部类型的脚本只能进行整个被测程序的调用( 如 某个j a v a 应用程序) ，它无法单独地针对被测程序内部的某个方法进行调用，因此外 部类型的脚本语言经常是用来记录一系列的黑盒测试步骤：而对于交互类型的脚本语 言，它可以访问到放测程序内部的所有属性和方法并与之交互，例如对于j a v a 程序 来说，交互型脚本语言应该能够访问j a v a 的类，类成员函数以及成员变量。当脚本 语言根据记录的事件信息重新构建了一个事件，随后会通过记录的组件信息找到作为 该事件触发源的组件，然后将重新构建的事件操作再次应用到该组件上来完成回放功 能。 此类录制回放工具是最基本，同时也是最有效的，大部分为了完成回归测试的自 动化工具都会选择这一种方式。另外，对于脚本录制得比较清晰，结构化比较好的测 试脚本，还可以进行修改和添加，以更好地满足回归测试的需要。大多数这种类型的 g u i 录制回放工具完成简单的黑盒录制和回放而不需要交互型脚本语言的介入，它 们仅仅是简单地录制用户的操作步骤并回放，被测程序运行时( r u n t i m e ) 的内部状态 在这种方式下是不可见且无法修改的。 第二类录制- 回放工具借助交互型脚本语言，完成录制和回放的功能。这类脚本语 言在一个s h e l l 环境下，以一系列的命令的方式，对特定功能调用，一旦某个功能调 用完毕，进程控制又会返回到s h e l l 命令行，同时，当前程序的运行时上下文会被保 存到脚本的s h e l l 环境下，这样就可以在模拟用户与被测程序g u i 对象的交互时完成 “单步”操作。采用交互型的脚本语言模拟被测运行程序单步执行的过程类似于程序 开发中的“调试”过程，用户可以通过在脚本设置对被测应用程序设置断点，使得被 测应用程序在特定情况下的特定地方停止执行( 这取决于脚本语言本身的功能) ，而 湖北大学硕士学位论文 这种“单步运行”优与调试的地方在于，采用脚本语言，用户可以动态地改变运行环 境参数第二种类型的录制回放工具采用的是交互型的脚本语言。它们并不是直接 录制用户的操作步骤，而是编写出一批脚本以备回归测试进行回放，采用脚本方式完 成录制回放的g u i 测试工具包括j v e r i f i e r , r e p l a y j a v a , s u nw o r k s h o p v i s u a lr e p l a y 等。 以典型的r e p l a y j a v a 具为例子，r e p l a y j a v a 采用了j a c l 脚本语言，j a c l 是t c l 语 言( t o o lc o m m a n dl a n g u a g e ) 的j a v a 实现。最初的t c l 解释器( 即t c ls h e l l ) 由c 语言编写，属于交互式可嵌入的命令脚本化语言，“可嵌入”是指把很多应用有效、 无缝地集成在一起，“命令”的意思是指每一条t c l 语句都可以理解成命令加参数的 形式。t e l 解释器类似于u n i x 的s h e l l ，它允许t c l 命令在一个s h e l l 中被交互地使 用或者从某个文件读入( 有可能是录制好需要重放的脚本) 。另外，t e l 几乎可以完 全编写复杂的图形应用程序