（计算机应用技术专业论文）面向对象的自动化单元测试.pdf

武汉理：l = 大学颁士学位论文 摘要 信息技术的飞速发展，使软件产品应用到社会的各个领域，软件产品的 质量自然成为人们共f 司关注的焦点。为了更好地保证软件产品的质量，于是 产生了软件测试，因为软件测试是保证软件质量的唯一途径，已经成为软件 工程中不可缺少的部分。近些年来，由于软件规模的不断增大，传统的手工 测试已严重影响了软件的发展，它不但需要投入大量的人力、物力和时间， 最终还是由于测试的工作量太大，而无法保证软件测试的充分性，从而无法 保证软件的质量。正是由于上述原因，推动了软件测试自动化的发展。 虽然软件测试的自动化技术在国外已经发展了几十年，但是在国内还仅 仅是处于起步阶段，这是由多方面的原因造成的：1 ) 国内软件市场发展比较 缓慢，导致软件需求量较小，测试工作量较小，人工测试完全可以满足需求； 2 ) 国内高校没有引起重视；在国内设立软件测试自动化专业的高校几乎属于 空白。3 ) 软件钡4 试自动化本身对软件测试人员来说需要更高的软件编程和软 件测试技能；正是由于这些障碍，导致了软件测试自动化技术对大多数人来 说是比较新的东西，更是属于目前业界的前沿课题。 本文提取出在软件测试过程中应用最多且最重要的单元测试进行详细论 述，并结合目前自动化单元测试发展的最新技术，给出了单元测试自动化的 两种不同解决方案：1 ) 利用商业的自动化单元测试工具；2 ) 根据特定的需求 定制自动化单元测试框架。这两个方法都大大地改善了手工单元测试的弊端， 缩短了软件开发的生命周期，同时有效地保证了软件产品的质量。本文最后 还以一个基于c o r b a 的分布式应用程序开发了一个自动化单元测试框架模型 系统，从而证明了软件单元测试自动化的可行性和必要性。 关键词：软件测试，单元测试，自动化技术 武汉理工人学硕士学位论文 a b s t r a c t s o f t w a r ep r o d u c ti sa p p l i e di ne v e r yf i e l d so fc o m m u n i t yw it ht h e d e v e l o p m e n to fi n f o r m a t i o nt e c h n i q u e ：t h eq u a l i t i e so fw h i c hb e c o m e af o c u sa n di tp r e s e n ti t s e l fa ss o f t w a r et e s tt h a ti so n l ya p p r o a c h t og u a r a n t e et h eq u a l i t i e so fs o f t w a r ep r o d u c ta n d n e c e s s a r yc o m p o n e n t i ns o f t w a r ee n g i n e e r i n gi no r d e rt og u a r a n t e eq u a l i t i e so fs o f t w a r e p r o d u c t i nr e c e n ty e a r s ，t r a d i t i o n a ls o f t w a r et e s t ，w h i c hd e m a n da m a s so f m a n p o w e r m a t e r i a lr e c o u r s e sa n dt i m eb u tc a n n o tg u a r a n t e et h e s u f f i c i e n c y o fs o f t w a r et e s ta n dt h eq u a l i t i e so fs o f t w a r ef o r c o n t i n u o u si n c r e a s eo fs o f t w a r es c a l e i nt h i sr e a s o n ，t h ed e v e l o p m e n t o fa u t o m a t e ds o f t w a r et e s ti s p r o m o t e d t h ei n l a n dt e c h n i q u eo fa u t o m a t e ds o f t w a r et e s ti su n d e r w a y ，w h i c h h a se v a l u a ti v ef o rs e v e r a ld e c a d e s t h er e a s o ni n v o l v e d m a n y f a c e t s ：1 ) m a n u a lw o r ki sc o m p e t e n ta sf o rl e s ss o f t w a r er e q u i r e m e n ta n d l e s ss o f t w a r et e s tt a s kt h a tc o n d u c e db ys l o wd e v e l o p m e n to fi n l a n d s o f t w a r em a r k e t ；2 ) i ti sv a c u i t yt h a ts e t t i n gu pa u t o m a t e ds o f t w a r e t e s tt ow h i c hi n l a n du n i v e r s i t i e sa t t a c hf e wi m p o r t a n c ei ni n l a n d u n i v e r s i t i e s ：3 ) s o f t w a r et e s ti t s e l fa s kf o rl o f t ys k i l ls o f t w a r e p r o g r a ma n d s o f t w a r et e s to fs o f t w a r et e s t p e r s o n a l ：a u t o m a t e d s o f t w a r et e s t ，t h et e c h n i q u eo fw h i c hi ss t i l lc o m p a r a t i v e l yn e wt h i n g s f o rm o s tp e o p l ea n df o r m e rd i s c u s s i o no fp r e s e n ts o f t w a r ec i r c l e s t h et e c h n i q u eo fa u t o m a t e du n i tt e s t ，w h i c hi sm o s ta p p l i e da n d m o s t i m p o r t a n t i ns o f t w a r et e s t ，isr e c o m m e n d e dind e t a ili nt h i s d i s c o u r s ea n d2k i n do fr e s o l v ep r e c e p tf o rt h ea u t o m a t e dt e s t ：1 ) m a k e u s eo fc o m m e r c i a lt o o l sf o ra u t o m a t e dt e s t ：2 ) c u s t o m i z ef r a m e w o r kf o r a u t o m a t e dt e s tb a s e do ng i v e nr e q u i r e m e n t t h i st w ok i n d so fp r e c e p t g u a r a n t e et h eq u a l i t yo fs o f t w a r ep r o d u c te f f e c t u a l l y ，b yw h i c ht h e a b u s eo fm a n u a lu n i tt e s ti s i m p r o v e da n dt h e1 i f e c y c l eo fs o f t w a r e d e v e l o p m e n ti ss h o r t e n e d ，w h i l eaf r a m em o d e ls y s t e mo ft h ea u t o m a t e d i i 武汉理工大学硕士学位论文 u n i tt e s to fad i s t r i b u t i n ga p p li c a t i o nb a s e do nc o r b ai sa c t u a l i z e d a tt h es e c o n dh a l f o ft h i sd i s c o u f s ei no r d e rt ot e s t i f yt h ef e a s i b i l i t y a n dn e c e s s a r yo fa u t o m a t i o no fs o f t w a r et e s t k e yw o r d s ：s o f t w a r et e s t ，u n i tt e s t ，a u t o m a t e dt e c h n i q u e 1 1 1 武汉理1 ：人学硕十学位论文 第1 章引言 1 1面向对象软件测试的起源 1 1 1 软件质量的重要生 信息技术的飞速发展，使软件产品应用到社会的各个领域，软件产品的 质量自然成为人们共同关注的焦点。不论软件生产者还是软件使用者，均生 存在竞争的环境中，软件开发商为了占有市场，必须把产品质量作为企业的 重要目标之一，以免在激烈的竞争中被淘汰出局。用户为了保证自己业务的 顺利完成，当然希望选用优质的软件。质量不佳的软件产品不仅会使开发商 的维护费用和用户的使用成本大幅增加，还可能产生其他的责任风险，造成 公司信誉下降，继而冲击股票市场。在一些关键应用( 如民航订票系统、银 行结算系统、证券交易系统、自动飞行控制软件、军事防御和核电站安全控 制系统等) 中使用质量有问题的软件，还可能造成灾难性后果。 1 1 ，2 软件错误是不可避免的“1 软件危机曾经是软件界甚至整个计算机界最热门的话题。为了解决这场 危机，软件从业人员、专家和学者做出了大量的努力。现在人们已经逐步认 识到所谓的软件危机实际上仅是一种状况，那就是软件中有错误，正是这些 错误导致了软件开发在成本、进度和质量上的失控。有错是软件的属性，而 且是无法改变的，因为软件是由人来完成的，所有由人做的工作都不会是完 美无缺的。问题在于如何去避免错误的产生和消除已经产生的错误，使程序 中的错误密度达到尽可能低的程度。给软件带来错误的原因很多，具体地说， 主要有如下几点o ，： 1 ) 交流上有误解或者根本不进行交流：在应用应该做什么或不应该做什 么的细节( 应用的需求) 不清晰的情况下进行开发。 2 ) 软件复杂性；图形用户界面( g u i ) ，客户服务器结构，分布式应用， 数据通信，超大型关系型数据库以及庞大的系统规模，使得软件及系统的复 武汉理r 人学硕士学位论文 杂性呈指数增长，没有现代软件_ 丌发经验的人很难理解它。 3 ) 程序设计错误：象所有的人一样，程序员也会出错。 4 ) 需求变化；需求变化的影响是多方面的，客户可能不了解需求变化带 来的影响，也可能知道但又不得不那么做。需求变化的后果可能是造成系统 的重新设计，设计人员日程的重新安排，已经完成的工作可能要重做或者完 全抛弃，对其他项目产生影响，硬件需求可能要因此改变，等等。如果有许 多小的改变或者一次大的变化，项目各部分之间已知或未知的依赖性可能会 相互影响而导致更多问题的出现，需求改变带来的复杂性可能导致错误，还 可能影响工程参与者的积极性。 5 ) 时间压力；软件项目的日程表很难做到准确，很多时候需要预计和猜 测。当最终期限迫近和关键时刻到来之际，错误也就跟着来了。 6 ) 代码文档贫乏；贫乏或者差劲的文档使得代码维护和修改变的异常艰 辛，其结果是带来许多错误。事实上，在许多机构并不鼓励其程序员为代码 编写文档，也不鼓励程序员将代码写得清晰和容易理解，相反他们认为少写 文档可以更快的进行编码，无法理解的代码更易于工作的保密( “写得艰难必 定读的痛苦”) 。 7 ) 软件开发工具：可视化工具，类库，编译器，脚本工具，等等，它们 常常会将自身的错误带到应用软件中。就象大家所知道的，没有良好的工程 化作为基础，使用面向对象的技术只会使项目变得更复杂。为了更好地解决 这些问题，软件界做出了各种各样的努力。 1 1 3 软件测试的产生 人们曾经认为更好的程序语言可以使我们摆脱这些困扰，这推动了程序 设计语言的发展，更多的语言开始流行，为了使程序更易于理解开发了结构 化程序设计语言，如p l i ，p a s c a l 等；为了解决实时多任务需求开发了结构 化多任务程序设计语言，如m o d u l a ，a d a 等：为了提高重用性开发了面向对 象的程序设计语言，如s i m l a s a 等；为了避免产生不正确的需求理解，开发 了形式化描述语言，如h a l s 等，这使得建立基于自然语言的描述成为可能， 人们以形式化语言来描述需求；为了支持大型数据库应用，开发了可视化工 2 武汉理j 二大学硕士学位论文 具，如v i s u a ls t u d i o 、p o w e rb u il d e r 等。程序语言对提高软件生产效率起 到了一定的积极作用，但它对整个软件质量尤其是可靠性的影响，与其他因 素相比作用较小。 可能是因为程序语言基于严格的语法和语义规则，人们企图用形式化证 明方法来证明程序的正确性。将程序当作数学对象来看待，从数学意义上证 明程序是正确的也是可能的。数学家对形式化证明方法最有兴趣，在论文上 谈起来非常吸引人，但实际价值却非常有限，因为形式化证明方法只有在代 码写出来之后才能使用，这显然太迟了，而且对于大的程序证明起来非常困 难。受到其他行业项目工程化的启发，软件工程学出现了，软件开发被视为 一项工程，以工程化的方法来进行规划和管理软件的开发。 针对需求不确定的应用，可以使用渐进和迭代类的开发模型。还可以采 用快速应用程序开发( r a d ) 和协同应用程序开发( j a d ) 技术，由软件开发者 和用户代表共同参与开发软件规范。r a d 和j a d 的基本思路是开发者和用户 共同设计系统中的屏幕，开发者迅速地把实现这些屏幕的最基本功能编写好， 然后把它们交给用户看，然后用户和开发者回顾这些屏幕以确认它们达到了 用户的要求，这个周期一直持续到系统的基本部分定义完毕。一旦设计被用 户接受，开发者将完成完全实现屏幕需要的代码。e a d 和传统软件开发项目 之间的一个基本区别是：应用程序r a d 系统是按阶段发布的。传统项目一般 一次发布，也叫“b i gb a n g ”。p 3 j ) 方法使用高效开发工具，开发者能够非 常迅速地设计出系统的基本屏幕，允许用户在开发周期中很早就能见识到系 统将来看起来怎么样，避免了在传统开发项目中长篇大论并且枯燥难懂的说 明。 事实上，对于软件来讲，还没有象银弹那样的东西。1 。不论采用什么技 术和什么方法，软件中仍然会有错。采用新的语言、先进的开发方式、完善 的开发过程，可以减少错误的引入，但是不可能完全杜绝软件中的错误，这 些引入的错误需要测试来找出，软件中的错误密度也需要测试来进行估计。 测试是所有工程学科的基本组成单元，是软件开发的重要部分。自有程序设 计的那天起测试就一直伴随着。统计表明，在典型的软件开发项目中，软件 测试工作量往往占软件开发总工作量的4 0 以上。而在软件开发的总成本 武汉理工大学硕士学位论文 中，用在测试上的丌销要占3 0 到5 0 。如果把维护阶段也考虑在内，讨论 整个软件生存期时，测试的成本比例也许会有所降低，但实际上维护工作相 当于二次开发，乃至多次开发，其中必定还包含有许多测试工作。因此，测 试对于软件生产来说是必需的，问题是我们应该思考“采用什么方法、如何 安排测试? ” 1 2 面向对象软件测试自动化的产生 1 2 1 面向对象软件测试为什么要自动化 软件测试的工作量很大( 据统计，会用到4 0 的开发时间；一些可靠性 要求非常高的软件，测试时间甚至占到总开发时间的6 0 ) 。1 ，但测试却是 在整个软件过程中极有可能应用计算机进行自动化的工作，原因是测试的许 多操作是重复性的、非智力创造性的、需要细致注意力的工作。计算机就最 适合于代替人类去完成这些任务。企业在这方面的投资，会对整个开发工作 的质量、成本、和周期带来非常明显的效果。 手动测试可能引入错误，人为的输入错误很容易发生，尤其在数据量大 的情况下；大量重复性的手动测试可能成本较高，如果考虑软件发生改动而 需要重复手动测试的情况，这个成本还会更高：手动测试的覆盖面不广，只 能够测试系统的输入和输出；没有办法对组件进行隔离的测试，从而导致发 现问题和解决问题的成本都太高。 1 2 2 面向对象软件测试自动化的发展现状 在软件开发生命周期中软件测试是一个非常重要的环节。据了解，目前 国内很多软件开发公司存在一个通病，那就是开发出来的软件产品质量一直 得不到很好保证，很多产品在正式交给用户使用后总是存在诸多的问题。其 原因是多方面的。1 ，一方面是软件开发的管理水平不高，尤其是一直以来忽 视了对软件产品进行必要和充分的测试：另一方面是由于国内在测试技术方 面的研究远远落后于i n 夕l - ，缺少先进和成熟的测试技术指导，软件测试的效 率低下。 4 武汉理l ：人学硕士学位沦文 在国内很少有企业采用自动化测试技术，往往是使用手工方式执行各种 测试用例。手工执行测试的弊端在于工作量巨大、资源浪费和执行效果难以 评估。尤其是在回归测试轮数很多的时候，如果选择的测试用例过多将极大 的延长执行周期；如果选择的过少又将无法保证验证的充分性。另外测试完 全由手工执行将导致测试最终的质量由个人的能力以及状态等诸多因素决 定，在测试活动结束后难于正确和全面的评估执行结果及质量是否达到预期 要求。 由于国内测试业发展缓漫，导致国内高校对于软件测试的重视程度不够， 绝大部分计算机院系没有专门从事测试研究方面的专业，大多数学生对于测 试的理解还只停留在软件工程课程中关于测试方面一两个章节的描述中。只 是模糊的知道软件产品在开发完成后需要经过测试才能发布，但是对于该在 什么情况下开始测试活动、如何执行测试、什么情况下结束测试活动、由什 么人来执行、采用什么样的测试技术、测试过程数据该如何统计、怎样评估 测试结果、测试的模型是什么样的、测试的生命周期又是如何管理的等等内 容知之甚少。更不要说对于自动化测试方面的研究了。而实际上目前从事软 件行业的人员中，有接近1 ：4 的人员专职从事测试相关的活动。在微软公司 的某些产品开发团队中，测试人员和开发人员的比例更是达到了1 ：1 0 3 。由 此测试在整个产品开发过程中的重要性可见一斑。 国外对于软件测试技术和管理活动的研究，在2 0 世纪7 0 年代“软件危 机”之后开始兴起，至今已有三十余年，涌现出大量的研究成果和专著。就 软件测试技术而言，从统计各种测试覆盖率的工具、到代码静态动态语法检 查和内存使用情况检查等的工具、再到各种应用于测试各个阶段活动的自动 化工具和语言，简直是琳琅满目，应有尽有。在测试语言方面，国际上成熟 的就有t c l 、p y t h o n 、p e r l 、r u b y 、p h p 、r e b o l 等等( 本论文选用的测试语 言就是p y t h o n ) 。 目前，i s 0 9 0 0 0 质量体系认证越来越得到软、硬件公司的重视，而测试 是i s 0 9 0 0 0 中质量保证实施的一个重要环节，中国加入w t o 后越来越多的公 司的产品要面对国际市场优秀产品的竞争，产品的质量更是企业生存之本。 近几年来国内已经越来越重视软件测试方面的研究工作。翻译了一大批 武汉理- j 人学硕十学位论文 关于软件测试理论、测试技术、测试管理、以及自动化测试方面的专业著作 和书籍。越来越多的人员投身于测试技术的研究之中。而如何实现软件的自 动化测试更是目前业界的前沿课题。 1 3 本课题研究的目的、意义 在面向对象的软件开发占主流的今天，人们越来越意识到测试在软件开 发过程中的重要性。做好软件测试，尤其是面向对象的软件测试，是一件很 不容易的事，同时自动化测试又是测试发展的方向。故制定这个论文题目， 旨在通过论文的完成过程来掌握面向对象系统的自动化单元测试技术，缩短 产品开发的整个生命周期，使产品的变更易于验证和受控。 单元测试将一个完整的软件划分成若干个独立的测试单元，针对这些测 试单元进行隔离测试。它是在软件开发过程中最低级别的测试活动。 传统上，单元测试虽然具有工作量大、乏味的特点，却是整个测试过程 中成本最低、效率最高的测试活动。根据开发者心理活动的特点，编码时开 发者对代码逻辑最为熟悉。如果在编码过程中及时进行单元测试，将会得到 更优质的代码。而缺乏单元测试的代码，在模块完成后发生错误时，由于开 发者的遗忘以及强大的工作进度压力，往往会给问题的修改和验证造成时间、 人员的匮乏，导致难以做出彻底的更正。 传统的单元测试缺乏自动化钡l 试过程是限带8 其普及的一个主要因素。由 于传统单元测试的繁琐，开发者往往倾向于只编写代码，而不做”乏味且缺少 创新”的单元测试工作。如果能够在编码过程中方便地构造测试用例并自动执 行，可有效地解决上述矛盾。基于此，本文引入了自动单元测试的概念。自 动单元测试通过提供测试用例的自动回放、比较机制，实现单元测试的批量 自动运行。本文通过实现一个基于p y t h o n 的自动化单元测试框架，对基于 c o r b a 通讯的跨平台系统进行自动化单元测试。 6 武汉理i ：人学硕十学位论文 第2 章面向对象中自动化单元测试的原理 在详细介绍本章之前，来让我们再来温习一下单元测试的概念，单元测 试是将一个完整的软件划分成若干个独立的测试单元，针对这些测试单元进 行隔离测试。自动化单元测试实际上是弥补手工单元测试的不足，让一部分 工作由计算机来自动完成，不需要人工干预的测试。它的原理比较简单：通 过编写测试脚本或利用自动化单元测试工具来发现程序的错误并把测试结果 记录到测试报表中。我们首先来看一看脚本自动化测试；脚本自动化测试根 据其书写的位置不同，能够把它分为两种：一种是内嵌型自动化单元测试， 另一种比较型自动化单元测试。而自动化单元测试工具通过自动生成测试脚 本来达到测试目的的。下面分别介绍这几种自动化单元测试。 2 1 引入自动化单元测试工具 自动化单元测试工具是通过分析用户的代码自动生成测试脚本来实现单 元测试的自动。它实际上集成了代码分析工具、测试脚本产生工具和测试输 出分析工具，通过对这些工具的合理运用达到对被测代码的最优检测。随着 软件发展技术进一步成熟，这些自动化单元测试工具也确实比较先进，都要 自己的一套测试界面，测试经验和测试理论作为支撑。 在现在的市场上根据不同的语言有不同的自动化单元测试工具，基于n e t 平台有t e s t ，基于j a v a 语言的有j t c s t ，基于c + + 语言的有c + + t e s t 自动化单 元测试工具。下面简单的介绍p a r a s o f f 公司推出的c + + 代s t 单元自动化测试 工具。它能够自动。1 ： 1 1 建立每个被测类的测试驱动程序。 2 1 建立任何必要的桩函数，并允许你定制这些桩函数的返回值或加入自 己的桩函数。 3 ) 单键执行自盒测试的所有步骤。 4 ) 生成黑盒测试用例的基础集合，运行黑盒测试用例，生成黑盒测试的 输出结果。 5 ) 执行回归测试。 印跟踪测试覆盖性。 7 武汉理工大学硕卜学位论文 从上面来看自动化单元测试工具确2 e 给不少软件企业带来利润，特别是 给那些开发时间短，软件质量要求高的项目提供了可靠的质量保证。通过引 入自动化单元测试工具，既保证软件开发的质量又为软件产品进入市场赢得 了宝贵的时间。其唯一的缺点是需要花钱买，给软件开发增加了成本。所以 在引入现成的自动化单元测试工具最好评估一下其带来的效益不要盲目的引 进。 2 2 编写测试脚本 通过编写测试脚本来达到自动化单元测试，基本上符合测试工业的良性 发展循环，因为大多数测试员是从程序员出身的，他们并不愿一直都进行枯 燥无味的单元测试，他们更愿写测试脚本来简化测试，再通过维护测试脚本 来达到测试的反复进行，并且可以避免测试中人为带来的错误。所以通过测 试脚本来进行单元测试已经成为许多大多数公司的首选目标。 2 2 1 内嵌型自动化单元测试 内嵌型自动化单元测试实际上是在编码阶段，内嵌一些测试语句对程序 运行情况进行监控，如果程序没有按照这种情况进行运行，则测试代码要么 中止程序的运行要么会记录到运行日志中，报告程序出错。这种自动化单元 测试通常包括两种：断言 蜒| | 试和跟踪日志测试。内嵌型的自动化单元测试 是在原来的程序中增加一些额外的测试代码来发现程序运行中的错误，这些 代码不但不支持用户的需求，反而在系统运行时会降低系统的性能，所以在 软件发布时通常都会将这些代码屏蔽掉，以提高系统的性能。 断言( a s s e r t ) 断言是一种有效的测试手段。在程序发生断言时，它能够中止程序的运 行，来使测试员在早期发现这些错误，从而避免以后程序运行时错误的发生。 这种手段是通过将很小的问题通过断言来放大，迫使程序在加入断言测试的 地方正确来达到测试目的的。目前支持这种测试的编译器很多，如c 、c + + 和 c # 的编译器都支持这种测试，j d k 从1 4 版本以后也新增了对这种内嵌测试 的支持。断言是一个定义正确执行的必要条件的布尔表达式。断言类似于一 8 武汉理j 二大学硕 ：学位论文 位不知疲倦的审计员。他不停地依据一些必要条件进行审核，一旦发现违反 规则就做出报告。断言可以表达特定于实现的约束，或独立于实现的类的责 任。断言的一般用途包括： 检查特定于实现的假设： 检查在方法的入口必须为真的条件( 前置条件) ； 检查在方法的出口必须为真的条件( 后置条件) ； 检查在任何时候对于一对象必须为真的条件( 不变式) ； 它的优点有： 1 ) 断言能够避免错误：责任、假设和它们的含义是明显的和可行的，这 种清晰、简单的行为常常可以揭示错误和遗漏； 2 ) 断言鼓励良好的文档代码；尽管从专业上讲，缺乏合适的文档是不可 原谅的，而且会导致高额的软件维护费用，但是很多程序设计人员和软件开 发经理都认为任何形式不可执行的文档开支应当减少到最小。责任断言的完 整集合可咀通过提供可执行的和精确的文档来满足这两种考虑； 3 ) 当系统测试开始时，外部驱动的单元测试常常落后于编码而被弃之不 用。相反，断言检查在断言被编码时即开始并自动地继续到被禁止为止。在 最初的系统狈4 试运行阶段，断言一般保持激活状态，这就扩充了单元测试的 有效范围。它开始得更早，结束得更晚。这样断言给形式化开发的外部测试 包提供低代价的扩展。每当一个消息被发送到一个具有被允许的断言的对象 时，消息及其结果即被检查。常用的对象常常查出由未预料的情况导致的断 言相悖。 4 ) 在其它的程序文档不可使用或不精确时，基于责任的测试实例可以由 基于责任的断言派生： 5 ) 及早地、自动地捕获“哑”( d u m b ) 错误。若不需要检查前置条件， 一般的接口缺陷( 如发送不正确的或不一致的消息) 可能容易逃逸而进入域 系统( f i e l ds y s t e m ) 。例如，如果在所有的方法中对消息变量的边界条件使 用断言，那么就能够减少边界值测试，就可以将预算用到其它形式的测试， 结果是测试脚本和驱动器可能较小而且较简单。 6 ) 断言鼓励复用并减少维护费用，其原因是能够使断言用将类的契约文 9 武汉理i 大学硕七学位论文 档化。不像注释或独立的不可执行的设计文档，断言必须是可编译的。与可 编译的详细设计表示相比，当代码被修改时，断言大多会保持通用和一致。 跟踪e l 志( t r a c ei o g s ) 跟踪日志是在完成特定的任务前后有计划的输出一个测试日志来报告系 统运行的状态。用这种方式来进行自动化单元钡4 试，能够解决软件中一些 在一般情况下解决不了的棘手问题，如难以重现的问题。通常象难以重现的 问题，只要重现了一次，然后根据程序的输出日志，一般都能定位和解决问 题。跟踪日志除了可以进行自动化单元测试外，在维护阶段也能启颡一定的 作用如网上问题渴题的解决，程序员不可能至慨场去定位发现问题，只能通 过测试日志来定位解决问题。 在设计程序的时候，适当地记录系统运行的日志是一个比较好的设计， 因为跟踪日志的一些输出信息对系统是否正常运行及系统运行出错时的闯题 定位都是很有援助的。 2 2 2 比较型自动化单元测试 比较型自动化单元测试是在测试阶段，通过写特定的测试脚本对特定的 代码进行测试的方法。它与内嵌型自动化测试最大的不同是，它的测试脚本 与被测代码是分开的，运行也是分开的。它测试目的不是针对程序运行中的 变量检查，而是对程序运行的结果与期望的结果进行对比，看它们是否相同， 如果相同则程序运行正确，如果不相同则程序运行失败，并且会记录失败原 因。 测试样式 比较型的自动化单元测试是用测试实例产生预期的结果和测试实例的实 际结果进行比较，来判断测试是否通过还是不通过的机制。自动化预测试的 样式有：精确自动化单元测试和逼近自动纯单元测试。 1 ) 精确自动化单元测试，手工开发预期结果或从参考文献中获取。测试 结果都是固定的( 要么一眼就知道结果要么通过特定的计算能够得到精确的 结果) ，大多数自动化测试都属于这种测试。它的示意图见图2 1 。 1 0 武汉理一人学硕士学位论文 测试输入选择j 淝腻实例输入 抽协i 盘硼l 矧示结果f 。业 r g测试实例期望结果 图2 1 精确自动化单元测试 2 ) 逼近自动化单元测试，是测试那种在现实生活中不能获得精确结果的 测试。如天气预报和地质探测中的复杂仿真。在这种情况下，不存在检查被 、狈8 对象所生成输出的简单技术。它的示意图见图2 2 。 眄赢司燮堕塑塑了i 磊 坚 l转按的期环结呆 图2 2 逼近自动化单元测试 测试比较器 测试比较器是决定程序测试自动化的关键部件。它决定着测试结果是通 过还是不通过。测试的比较器是和特定的应用需求相关的，不同的应用实例 可能会有不同的比较器。常用的比较器有：系统实用程序、灵敏比较器和特 定应用比较器。 1 ) 系统实用程序：将预期结果和实际结果都写入文件中，并且这些文件 可以用基本的比较工具进行比较，如u n i x 的d i f f 。因此，如果实际结果文 件与预期结果文件不相同，就表示错误。 2 ) 灵敏比较器：提供比一般的比较器更大的控制权。提供各种跨平台或 跨数据库的比较工具，一般都是比较专用的。 3 ) 特定应用比较器：它是根据不同的应用开发出来的比较器，是目前应 用最多的种比较器。 武汉理j ：人学硕士学位论文 2 2 ，2 比较型自动化单元测试实施 内嵌型自动化单元测试技术和引入自动化单元测试工具进行自动化单元 测试比较简单，感兴趣的读者可以参考其它书目和自动化工具使用说明手册， 在这里不一一论述。本章重点介绍的是比较型自动化单元测试的实施策略。 比较型自动化单元测试的实施包括测试装置的构造、测试用例和测试日志。 测试装置可以认为是执行测试用例所需的框架。 2 2 2 1 单元测试用例 单元钡5 试用例也即t e s t c a s e ，它是单元测试中最基本的组成单元。它的 实例获取必要的测试条件后，向测试对象发送消息，并评估结果是否通过， 它包含测试前条件、钡4 试消息和期望结果的完备的、准备执行的表达式。测 试实例有三个主要步骤：启动、执行并评估和清除”1 。 启动：测试实例必须构造被钡4 对象、被测对象应用服务器对象和测试实 现需要的运行环境。环境包括运行测试需要的系统资源，这些资源可能位于 远程计算机上。例如，启动包括给存根或代理发送消息，给对象和实例变量 发送消息，这些对象和实例变量发送给被测对象的消息中的参数； 执行并评估：测试实例必须构造测试实例需要的参数，然后将测试消息 发送给被测对象，同时比较实际返回的结果和预期结果，结果应该显示出来 或被记录下来； 清除：释放资源和恢复运行环境。测试后需要清除有两个原因：是将 被测的环境恢复到名义上的测试后状态，可以增大测试实例可复用的范围： 二是未释放的资源可能引起测试运行的失败，原因是内存不够或相关性能的 退化： 常见的单元测试用例的类图( 见2 3 图) 和方法说明： 图2 3 测试用例 1 2 武汉理i 人学硕十学位论文 s e t u p 0 ：用i 柬建立运行这个用例所需的环境，如资源的申请，环境的出 始化等。 r u n0 ：用来执行并评估测试结果。 c l e a r u p 0 ：是用来释放在s e t u p 0 方法中申请的资源，把测试环境恢复 到测试前的环境，目的是不影响下个用例的顺利执行。 2 2 2 2 单元测试装置 测试装置( t e s th a r d n e s s ) 是支持有效和可重复的自动化测试的系统， 它是测试环境的中心部分“。测试装置是启动被测对象，给被测对象发送测 试消息，然后评估测试通过未通过结果的系统。自动化单元测试装置是为自 动化单元测试而设计的一套完整的框架系统。测试装置、测试用例和测试日 志它们之间的关系如图2 4 。 图2 al 坝0 试装置体系结构 目前国内外用得最多的单元涣l 试装置是增量式单元测试框架，它主要提 供支持测试实例和测试包( t e s t s u i t e ) 开发和执行的用户接口，通过提供方 便地定义测试实例添加测试用例到测试包以及运行测试实例的能力，来支持 迭代和增量开发。它是目前比较流行的框架设计模式。 应用场合：在类和簇作用域支持单元和集成测试，特别适应快速迭代和 增量开发。类图如图2 5 。 武汉理i ：大学硕士学位论文 图2 5 增量测试框架 框架类： 基本的框架类有三个类：t e s t r e s u l t ，t e s t c a s e 和t e s t s u i t e 。 t e s t r e s u l t 记录测试实例或测试包的一次特别运行的结果，有以下责任脾1 ： i ) 在未预料的异常抛出列表中添加异常项； 2 ) 记录测试运行的开始； 3 ) 记录测试实例的开始； 4 1 记录测试运行的结束； 5 ) 报告一次测试运行中所有的错误： 报告一次测试运行中所有没有通过的项； 7 1 报告一次测试运行中没有通过项的个数； 8 ) 报告一次测试运行中测试执行的全部个数； 9 ) 报告整个测试运行的状况( 全部通过或部分通过) 。 t e s t c a s e 是一个抽象类，为测试实例的设置、执行、评估和清除提供通 用接口，有以下责任： 1 4 武汉理一i 大学顶士学位论文 1 ) 给一个测试实例建立一个空的t e s t r e s u l t 对象； 2 ) 分配一个测试实例的名字； 3 ) 报告这个测试实例的名字： 4 ) 提供完成测试实例设置的接口； 5 ) 提供运行测试实例的接口并返回t e s t r e s u l t 对象； 6 ) 提供完成测试实例清除的接口。 t e s t s u i t e 遵循c o m p o s i t e 样式。t e s t s u i t e 支持任意测试实例的任意深 和复杂的层次结构，它具有以下责任： 1 ) 将一测试实例子类添加到这个测试包中： 2 ) 报告这个测试包中测试实例的个数； 3 ) 运行所有的测试元素并返回t e s t r e s u l t 对象。 用户部件： t e s t c a s e 类的子类：子类实现了t e s t c a s e 有关设置、评估和清除方法 的抽象接口，有以下责任： 1 ) 提供完成测试实例设置的代码； 2 ) 提供完成测试实例清除的代码； 3 ) 针对每个测试实例，实现一个方法，该方法发送设置所必要的消息， 向被测对象发送测试消息，给类属比较器传递实际结果和预期结果， 以及给清除方法发送消息。 执行的过程： 当执行t e s t r u n n e r 对象时，开始测试运行( 例如j a v a 中，通过对该类 中的m a i n 方法进行编码使其作为命令行应用运行) 。测试包( p a c k a g e ) 可以 装载一个现存的测试包对象或运行将包( p a c k a g e ) 中的测试实例添加到测试 包的代码。r u n 消息发送给测试包( s u i t e ) 对象，它建立一新的t e s t r e s u l t 对象。该包给每个测试实例或测试包发送r u n 消息，如果元素是一个 t e s t c a s e a p p ，那么钡5 试实例进行设置、执行、评估和清除，并将一记录添加 到t e s t r e s u l t 对象中。如果元素是一个( 不同的) t e s t s u i t e 对象，那么在 其元素上应用r u n 消息。当运行完最后一个测试包元素后，控制将返回给 t e s t r u n n e r 对象，显示t e s t r e s u l t 对象的内容，表明哪个测试通过或未通 】5 武汉p i l l 火学硕十学位论文 过。 22 2 3 针对类的测试装置 下面介绍几种常用的设计类范围测试驱动装置的测试样式“： 1 ) 测试驱动器超类( t e s td r i v e rs u p e r c l a s s ) ，将一般的测试服务实 现为驱动器超类；定义抽象超类( t e s t d r i v e r ) ，目的是提供通用接口和测试 服务，可由特定类驱动去继承。应用场合：当开发任何基于继承的驱动器的 时候使用。类图如图2 6 。 图2 6 测试驱动器超类 t e s t d r i v e r 类实现下列保护的方法，其它一般的测试服务用这种方法实 现并由测试驱动器类继承。 s t a r t t e s t c a s e ( o b j e c tt e s t c a s e ) 生成具有测试实例的开始日期和 实际的测试记录项： f i n i s h t e s t c a s e ( b 0 0 1p a s s ) 记录生成具有测试实例完成的日期和 时间的通过未通过结果； t e s t d r i v e r 类实现下列私有方法： o p e n t e s t l 0 9 0 打开测试运行记录，记录环境变量( 例如：操作系 统版本、t e s t d r i v e r 版本，c p u 系列号等) ； c l o s e t e s t l o g0 关闭测试运行记录，记录环境变量( 例如：操作系 统版本、t e s t d r i v e r 版本，c p u 系列号等) ： 2 ) 对称驱动器( s y m n u t r i cd r i v e r ) ，作为与被测类层次对称的层次实 现的驱动器，每个驱动器类向被测类的对象发送一条测试消息。对称层次类 图如图2 7 。 武汉理l ：人学硕七学位论文 i e s t d f i v e r - 图2 7 对称驱动器 3 ) 子类驱动器( s u b c l a s sd r i v e r ) ，将驱动器实现为一被测类的子类 子类驱动器的类图嘲，类图如图2 8 。 图2 8 子类驱动器 4 ) 私有访问驱动器( p r i v a t ea c c e s sd r i v e r ) ，通过采用使封装无效的 特定语言的机制的优点达到可控制和观察的目的，并支持扩展范围中的新对 象。它是有语言限制的，在c + + 中可以用f r i e n d 关键字来达到目的，但在j a v a 中没有任何方法可以达到这个目的。私有访问驱动器的类图如圈2 9 。 7 武汉理l ：人学觏一 ：学位论文 t e s t d r i v e r 图2 9 私有访问驱动器 5 ) 内嵌测试驱动器( b u i l t i nt e s td r i v e r ) ，将驱动器实现为被测类 的一部分。内嵌测试驱动器的类图如图2 1 0 。 t e s t d d v e r 1 ，j 审一、 l 型堕 l 一潞 i t e s t j b o o j t e s t _ b a r 0 图2 1 0 内嵌测试驱动器 2 2 。2 4 单元测试日志 单元测试日志是用来记录在自动化单元测试过程中执行失败和发生错误 的用例信息。它能够把己发生的错误按照规定的格式记录下来，以好在单元 测试结束后进行测试统计。单元测试日志的格式不定，它可能按照公司的不 同而有不同的格式，但内容一般都含有用例号、问题级别、问题发生时间、 版本号、问题简述和问题详述等信息。本文用的单元测试同志的格式如图 1 8 武汉理l ：人学坝十学何论文 2 儿。 图2 1 1 单元测试日志 武汉理【：大学硕l 学位论文 第3 章基于c o r b a 分布式应用的自动化单元测试框架 随着软件业的不断发展，国内面向对象的自动化测试也蓬勃地发展起来 了。目前不少大公司都专门成立了自己的测试部门，对自己开发的软件产品 进行测试，虽然他们用的测试方法各不相同，但有一点不可否认他们在他们 的测试过程中都或多或少的使用了自动化测试技术。 为了更好地理解前面章节所介绍的内容，学会在实际工作中利用自动化 单元测试来减少单元测试的工作量，提高单元测试效率。本章将介绍如何用 p y t h o n 实现基于c o r b a 的分布式应用程序的自动化单元测试，以好起到抛砖 引玉的效果。 3 1 基于o o r b a 应用程序的自动化单元测试过程 一个基于c o r b a 的应用程序通常是c s 模式，有自己的客户端和服务器 端，对这样的程序进行单元测试必须同时对客户端和服务器端进行单独的单 元测试。由于客户端一般是只