（计算机应用技术专业论文）基于eds的自动化测试框架的研究与实现.pdf

摘要 摘要 软件测试作为保证软件质量，提高软件可靠性的重要手段，在软件开发中起 着不可替代的作用。随着计算机在各个领域的普及，软件规模的增大和开发模式 的变化，测试的工作量也随之不断增大。测试自动化技术可以提高测试的效率和 有效性，缩短软件的测试周期，降低测试成本。因此，对测试自动化技术的研究 具有十分重要的理论价值和实用价值。 本文较全面系统地阐述了软件测试领域的主要研究方向和迄今为止具有代表 性的研究成果，基于e d s ( e v e n td r i v es y s t e m ) 思想提出了一种新的简单有效的 g u i 自动化测试模型，并以这个模型为基础设计实现了g u i 自动化测试平台e d s 测试系统。实验表明：本文设计和实现的测试平台在可扩性、可靠性和稳定性等 方面都有很好的表现。 本文的工作主要有以下几个方面： 1 ) 基于e d s 的思想提出了一种简单而有效的g u i 元素表示模型。这个模型从g u i 测试的角度出发将g u i 元素抽象为事件和属性的集合体，放弃了基于g u i 的 消息表示法。这种表示方法更能被测试人员接受，更接近于g u i 自动化测试 的表示策略，这也是本文研究的基础； 2 ) 基于g u i 元素表示模型，提出了g u i 元素测试模型。该模型主要用来指导自 动化测试工具的测试方法。针对g u i 测试模型提出了测试失效模型和测试覆 盖率模型。其中测试失效模型可有效的检测出隐藏在g u i 中的缺陷，测试覆 盖率模型可帮助测试人员分析当前测试的充分性； 3 ) 设计并实现了一个e d s 自动化测试工具。该系统具备以下特性：第一、它是 一个开放的平台，用户可以根据自己测试对象逻辑的需要构建自己的g u i 元 素类，提高测试工具的灵活性和可扩展性；第二、这个工具支持对 w p f ( w i n d o w sp r e s e n t a t i o nf o u n d a t i o n ) 控件的测试，w p f 控件是微软主推的控 件，但是当前的g u i 自动化测试工具并不能支持对它的测试。本工具解决了 当前g u i 自动化测试工具不能测试w p f 控件的缺陷；第三、系统的测试用例 管理模块是在工厂模式基础上使用钟来实现，使用相当方便，用户无需学习 其它语言和编程方法；最后，系统是基于微软的u ia u t o m a t i o n 开发库，兼容 w i n d o w s 平台之前的控件类型。 摘要 关键词：软件测试，自动化测试平台，g u i 测试模型，e d s l i a b s t r a c t a b s t r a c t a sa ni m p o r t a n tm e 缸l st og u a r a n t e es o f t a r eq u a l i t ya n dr e l i a b i l i 坝s o f b c c a r et e s t i n g p l a y s 锄i r r e p l a c e a b l er o l ei nt h ep r o c e s so fs o f t w a r ed e v d o p m e n t a st h ew i d e l yu e s d o ft h es o r w a r e ，t h e e x p a n s e o fs 0 1 a r e s c a l e , t h ec h a n g e a b l e o ft h es o f t w a r e d e v e l o p m e n tm o d e l i t si n v i t a b l et oi n c r e a s et h et e s t i n gw o r k l o a d s o f t w a r ea u t o m a t i o n t e s ta i m st o i m p r o v e s o f t w a r e t e s t i n ge f f i c i e n c y , s h o r t e n s o f t w a r e d e v e l o p m e n t l i f e c y c l e , r e d u c es o f t a r et e s t i n gc o s t s o i t sv a l u a b l et o s t u d yt h es o f t w a r et e s t a u t o m a t i o nt e s t a f t e ras u r v e yo fm a j o rr e s e a r c hf i e l d sa n dr e p r e s e n t a t i v ea c h i e v e m e n t si nt h ea r e ao f s o r w a r e t e s t i n g ，t h i st h e s i sp r e s e n t sa n e wg u ia u t o m a t i o nt e s tm o d e lw h i c hi sb a s e do n t h ee d s ( e v e n td r i v es y s t e m ) t h e r o y b a s e do nt h em o d e l ，w ed e s i g na n di m p l e m e n ta l l a u t o m a t i o nt e s ts y s t e m e d st e s t i n gs y s t e m s o m ee x p e r i m e n t a lr e s u l t si l l u s t r a t et h a t t h et e s t i n gs y s t e mi ss c a l a b i l i t y , r e l i a b i l i t ya n ds t a b i l i t y w o r k si nt h i st h e s i sa r em a i n l yf o c u s e do nt h ef o l l o w i n ga s p e c t s ： 1 ) t h i st h e s i sp r e s e n t san e wg u ie x p r e s s i o nm o d e lw h i c hi sb a s e do nt h e e d s ( e v e n td r i v es y s t e m ) t h e r o y t h eg u ie l e m e n t s w i l lb ea b s t r a c t e d 鹤 c o l l e c t i o no fe v e n t sa n dp r o p e r t i e sb yt h em o d e lw h i c hg i v e su pt h eg u i s m e s s a g e t h i sm o d e lw i l lb ea c c e p t e db yt h et e s t e rm o r ee a s i e r ，c l o s e st ot h e g u ia u t o m a t i o nt e s ts t r a t e g ya n di st h eb a s i so f t h et h e s i s 2 ) b a s e do nt h eg u ie x p r e s s i o nm o d e l ，t h i st h e s i sp u t sf o r w a r dag u it e s t i n gm o d e l w h i c hw i l lb eu s e dt op r o v i d eam e t h o dh o wt ot e s tt h eg u ii t e mw i t ht h eg u i a u t o m a t i o nt e s tt 0 0 1 g u it e s t i n gf a i l u r em o d e la n dt e s t i n gc o v e r a g em o d e lh a v e b e e np r e s e n t e dt os u p p o r tt h eg u it e s t i n gm o d e l g u it e s t i n gf a i l u r em o d e lc a n f i n dt h eb u gh i d d e ni nt h eg u ii t e m se f f c t i v e g u it e s t i n gc o v e r a g em o d e lc a n h e l pt e s t e rt oa n a l y z e t h ea d e q u a c yo f t e s t 3 ) d e s i g n sa n di m p l e m e n t sa l la u t o m a t i o nt e s ts y s t e m e d st e s t i n gs y s t e m t h e s y s t e mh a st h ef o l l o w i n gc h a r a c t e r i s t i c s ：f i r s t l y , i t sa no p e np l a t f o r m ，u s e r sc a n d e f i n et l l e i ro w ng u ii t e mc l a s sa c c o r d i n gt ot h e i rt e s t i n gs t r a t e g yw h i c hw i l l i m p r o v et h ef l e x i b i l i t yo fs y s t e m s e c o n d l y , t h es y s t e mc a n t e s tt h ew p f i i i f w i n d o w sp r e s e n t a t i o nf o u n d a t i o n ) i t e r nw h i e l li st h em a i np u s ho ft h e m i c r o s o f t n l i sc h a r a c t e r i s t i cm a k e su pf o rt h ec u r r e n tt e s tt o o l sd e f c c tw h i c h d o e s n t s u p p o r tt h ew p fi t e m s a u t o m a t i o nt e s t t h i r d l y , s y s t e mt e s tc a s e m a n a g e m e n tm o d u l ei sb a s e do nt h ed e s i g np a t t e r no ft h ef a c t o r ya n dp r o g r a m s w i 也c 撑s ot h eu s e rc a nu s ei te a s i l ya n dn on e e dl e a r n i n go t h e rp r o g r a m i n g l a n g u a g e f i n a l l y , t h es y s t e mi sb a s e d o nt h em i c r o s o r su ia u t o m a t i o nl i b r a r y , s o t h et e s t i n gt o o li sc o m p a t i b l ew i t hp r e v i o u sg u ii t e r no f w i n d o w s k e y w o r d s ：s o f t w a r et e s t ，a u t o m a t i o nt e s tp l a t f o r m ，g u it e s t i n gm o d e l ，e d s i v 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工 作及取得的研究成果。据我所知，除了文中特别加以标注和致谢的地 方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含 为获得电子科技大学或其它教育机构的学位或证书而使用过的材料。 与我一同工作的同志对本研究所做的任何贡献均己在论文中作了明 确的说明并表示谢意。 签名：么垒屿。日期：z 矽7 年岁月日 关于论文使用授权的说明 本学位论文作者完全了解电子科技大学有关保留、使用学位论文 的规定，有权保留并向国家有关部门或机构送交论文的复印件和磁 盘，允许论文被查阅和借阅。本人授权电子科技大学可以将学位论文 的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或 扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后应遵守此规定) j 丕参扩 日期：沙砷年岁月 日 第一章引言 1 1 课题背景 第一章引言 随着计算机系统在各行各业中得到广泛的应用，计算机软件也越来越趋向于 多样化、复杂化和大规模化。但是到目前为止软件系统，仍是依靠大量技术人员 的思维活动共同开发出来的。由于个体之间技术的差异以及思维的局限性，软件 的质量却一直是令人头疼的问题。因此，保证软件质量，提高软件可靠性成为软 件开发中的重要环节，也成为决定软件成败的关键。 作为软件工程重要组成部分的软件测试是软件质量的有力保证。软件测试对 于软件开发的重要性不仅仅表现在检验系统是否可靠、是否达到预期目标，还可 以给开发人员提供一种反馈。当然软件测试并不能完全找出所有的b u g ，但是通过 软件测试可以将软件中存在b u g 的几率限制在一个可以控制的范围内。例如 m o t o r o l a 的6 s i g m a 标准就是其中的一种度量方式。大量统计资料表明，软件测试 阶段投入的成本和工作量往往要占软件开发总成本和总工作量的4 0 到5 0 甚至 更多。正是由于软件测试在软件开发过程中的重要价值及其工作的复杂和繁重性， 提高软件测试的效率已经变得越来越重要了。但是传统的软件测试技术和方法已 无法满足大型的、复杂的软件测试需要。因此软件测试技术的研究就成为当前软 件界的重点和难点，有关软件测试技术的研究和软件测试工具的开发越来越受到 业界的重视。对软件测试方法和技术的研究长期以来都是软件工程领域中的热门 研究课题，无论在测试理论上还是在工程应用上都受到了广泛而深入的研究。但 是直到今天对于软件测试的定义仍没有给出一个统一的定义。 对于软件测试的定义主要有以下几种： “程序测试是为了发现错误而执行的一个程序或者系统的过程。【l p g l e n f o r d m y e r s “测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软 件质量的度量。 一b i l lh e t z e l ； “测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施 和维护的整个生命周期过程。 2 1 一i u c k & s t e f a n ； “对软件系统或软件系统组件进行检测和评估的过程，通过人工或自动的方 电子科技大学硕士学位论文 式来验证是否满足了特定的规定和需求，确认实际运行结果与所期望的运行结果 之间的差异【3 】 i e e e 提出的软件工程标准术语： 早期的软件测试主要是通过调试的方式来完成的，但是在上世纪5 0 年代人们 从一些大型的软件项目的失败中认识到测试的重要性。软件测试真正确立是在2 0 世纪7 0 年代，以1 9 7 2 年6 月在美国北卡罗来纳大学召开的首届软件测试正式技 术会议为主要标志。随即形成了相对独立的研究方向；8 0 年代一些简单的测试方 法和测试策略开始用于确认和验证；软件测试有了较快的发展是在9 0 年代以后， 测试方法更加细化，同时开始借助于数学的方法来提高测试的效率。但是由于传 统的手工测试存在速度太慢，效率太低，周期太长的不足，人们开始尝试使用自 动化的方法来完成测试，通过编程来完成一些繁琐的重复的工作，保证测试的可 重复性，提高测试的效率。但是自动化测试也是通过编程来模拟人工的操作，它 对测试工具以及所测软件的条件要求比较高，对于自动化测试的可用性和实用性 是一个很大挑战，由于自动化测试本身的复杂性以及其很强的实用价值，很多国 内外的专家学者也都在研究这一课题。 1 2 软件测试技术 1 2 1 软件测试模型 在软件测试领域已经提出了一些比较成熟的测试模型，这些模型对指导测试 工作的进行具有重要的意义。其中主要测试模型有以下几种： 1 ) v 模型：v 模型是最广为人知的模型。它最早是由己故的p a u 瓜o k 在8 0 年代 后期提出，在英国国家计算中心文献中发布，旨在改进软件开发的效率和效果。 v 模型描述了一些不同的测试级别，并说明了这些级别所对应的生命周期中不 同的阶段。它的优势在于它非常明确地标明了测试过程中存在的不同级别，并 且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。 2 ) w 模型：w 模型是v 模型的发展，相对于v 模型，w 模型更科学。它强调的 是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序。需求、功能 和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。 当然w 模型也有局限性。w 模型和v 模型都把软件的开发视为需求、设计、 编码等一系列串行的活动，无法支持迭代、自发性以及变更调整。 3 ) x 模型：x 模型也是对v 模型的改进，x 模型提出针对单独的程序片段进行相 互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程 2 第一章引言 序。x 模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这 一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但 这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比 较高。 们h 模型：在h 模型中，软件测试过程活动完全独立，贯穿于整个产品的周期。 h 模型揭示了以下原理：( 1 ) 软件测试的执行，还包括很多其他的活动；( 2 ) 软 件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行； ( 3 ) 只要某个测试达到准备就绪点，测试执行活动就可以开展； 5 ) 前置模型：前置测试模型是一个将测试和开发紧密结合的模型，此模型将开发 和测试的生命周期整合在一起，随项目开发生命周期从开始到结束每个关键行 为。前置测试模型体现了以下的要点：( 1 ) 开发和测试相结合；( 2 ) 对每一个交 付内容无论是文档还是代码进行测试；( 3 ) 坝0 试设计和软件设计同时进行；( 4 ) 让验收测试和技术测试保持相互独立；( 5 ) 开发和测试交替进行； 1 2 2 软件测试的方法和策略 软件测试方法根据是否要运行程序可划分为两大类如图1 1 ，即静态方法和动 态方法 4 】； 静态测试是不执行程序代码而寻找程序代码中可能存在的缺陷或评估程序代 码的过程。静态测试主要通过以下形式，由人工进行的代码审查、代码走查、桌 面检查以及由软件工具自动进行的静态分析。软件需求分析和设计阶段的技术评 审可以认为也是一种静态测试【5 】； 动态测试是使用测试数据和追踪程序执行过程的测试方法，通过执行程序检 查程序的运行状态与结果是否正确，来发现程序中存在的逻辑错误和算法错误。 动态测试包括生成测试数据、运行程序和验证程序的运行结果三部分核心内容， 同时还包括文档编制、数据管理、操作规程及工具应用等辅助性工作。 电子科技大学硕士学位论文 软件测试技术 静态测试技术软件测试技术 码码面态术 审走检分评 查查查析审 白 试技术合的测试技术试技术 厂t - t 耳 控域符程变数 制测号序异据 流试执插测流 测行装试测 试 厂t _ r 语分 条代 句支件码 覆覆覆审 盖盖 盖查 试 厂 全全 定引 值用 覆覆 盖盖 分验 试 设 计 图i - i 软件测试技术分类图 根据测试活动和测试任务之间的关系，测试又可以分为以下几种： 单元测试：单元测试是在软件开发过程中要进行的最低级别的测试活动，在 单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测 试。 集成测试：集成测试也叫组装测试或联合测试。在单元测试的基础上，将所 有模块按照设计要求( 如根据结构图) 组装成为子系统或系统，进行集成测试。 性能测试：性能测试是通过各种工具和手段模拟出多种正常、峰值以及异常 负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测 试。 1 2 3 手动测试的局限性 手动测试的出现是在计算机发展的初期，当时的软件规模比较小，同时计算 机也是非常宝贵的资源，在程序交给计算机运行之前都要进行仔细的检查，以避 免各种可能的程序错误。但是随着行业软件在各个应用领域的普及，软件功能越 来越强，规模也不断增大；测试工作变的越来越复杂，传统的手动测试就表现出 以下缺点： ( 1 ) 引入人为性错误：由于人本身的具有不确定性，人为的输入错误很容易发 4 第一章引言 生，尤其在数据量大、工作压力比较大、大量重复劳动的情况下；( 2 ) 成本高：大 量重复性的手动测试需要大量的测试人员的投入，这样就使得测试成本大大增加， 如果考虑软件发生改动而需要做大量重复的手工测试，成本将会更高；( 3 ) 覆盖面 窄：由于手动测试的局限性，只能够测试系统的输入和输出，使得覆盖面不广；( 4 ) 不能进行隔离测试：手工测试没有办法对组件进行隔离的测试，无法对不可视组 件进行单独测试，从而导致发现问题和解决问题的成本太高。( 5 ) 不能适应新的开 发模式：新的软件工厂式的开发模式要求每周都要出一个新的软件版本来进行测 试，传统的手动测试无法完成相应的测试工作。 对于手动测试存在的这些问题，可以通过自动化测试过程来解决。自动化测 试的优点在下一节中将有详细的描述。 1 3 软件自动化测试 “软件自动化测试就是使用软件工具来代替手工进行的一系列测试动作， 减少人工介入到非技术性( u n s k i l l e d ) 、重复性( r e p e t i t i v e ) 、冗长( i 司u n d a n t ) 的测试活 动里，来验证软件是否满足需求【6 1 。 1 3 1 软件自动化测试国内外研究现状 自动化测试已经有二三十年的发展经历，随着技术的进步，这个领域还在不 断的自我完善和改进。在西方国家( 美国、欧洲等) ，自动化测试有着非常庞大的研 究机构和协会，而我国最近几来年才开始认识到其重要性，因此发展较为缓慢技 术比较落后。在软件测试自动化理论和自动化测试工具的实现方面都有一定的突 破。主要集中在以下几个方面： ( 1 ) 测试用例的自动生成：t s a i 针对关系代数查询表示的规格说明设计测试用 例，提出的从关系代数查询表示的规格说明中生成测试数据的方法【7 】，适合于数据 库和数据处理系统。w e y u k e r 提出的基于布尔规格说明的测试数据生成方法峭j ，该 方法将l o v e s o n 的基于过程控制的形式化规格说明方澍9 】进行改进，用a n d i o r 表 来描述规格说明中的条件，适合于过程控制系统。h a l l 提出的利用z 规格说明进行 软件测试数据生成的方法【1 0 】【1 l 】。a t i f m e m o n 等人运用逆转工程技术实现了测试用 例自动生成的过程 1 2 】。虞凡提出的一种基于时序逻辑语言x y z b 软件规范说明的测 试用例自动生成方法【1 3 】，该方法采用x y z e 描述，首先确保规范与被测软件的语 义一致，其次，利用x y z e 规范的逻辑程序属性，实现了对测试用例中输出期望 电子科技大学硕士学位论文 i 拘p r o l o g ( p r o g r a m m i n gi nl o g i c ) 自动生成。 ( 2 ) 测试自动化脚本技术：在自动化测试过程中，因为有大量的测试脚本需要 被编写，测试人员希望能够指定一些简单的脚本，通过这些脚本信息能够指导测 试的自动化进行。但是，不同自动化工具开发商采用了不同的脚本语言，如果测 试人员想基于这些自动测试工具开发自己需要的测试平台，学习一种新的测试自 动化脚本语言。这样无疑公司的开发成本，而且增加了工作量。若能发展标准化 且易于掌握的测试脚本语言则可以简化自动测试的复杂性和减少测试人员的工作 暑 1 4 1 5 1 1 6 1 ：j e v ( 3 ) 测试自动化框架：由于项目开发的动态特性，以及项目开发中同时包含两 种测试情况：可实现自动化的测试活动和不能实现自动化的测试活动，这就要求 设计出具有较灵活性的自动化测试模型，可在较少改动或者配置的情况下，最大 化适应自动化测试的需求。a n o t m a t e dt e s t i n gl i f e - c y l em e t h o d o l o g y ( a l t m ) 模 型从自动化测试生命周期与软件开发生命周期相融合的角度进行了详细探讨，各 种自动测试框架模型也从不同角度对自动测试框架进行研究和设计【1 7 1 8 】【1 9 】【2 0 】【2 1 1 。 ( 4 ) 测试自动化中的预测方面：在自动化测试的性能和效率方面，虽然测试的 活动本身已经能够较好的实现自动化，但对测试结果的判定仍然是依赖于人的手 动干预。如果能通过特定的评测标准使其在测试过程中准确判断当出现什么样的 结果的时候是程序错误，那么自动测试就能够实现真正的自动化。因此，测试预 测是自动测试技术中非常关键而又困难的研究内容，直接关系到测试结果的准确 性。目前，对测试自动化中的预测问题的研究仍相对较少，研究大多集中在使用 外部规则说明产生测试预测瞄】【2 3 1 【2 4 1 ，这些规则说明被作为自动测试过程发现程序 错误的一种参照标准。 ( 5 ) 自动测试与可靠性分析方面：自动测试大量用于回归测试中，它是一个反 复的过程，自动化测试的可靠性方面一直都是技术人员所非常关心的方面。在什 么样的情况下可以信任自动测试的结果，以及在什么条件下所完成的测试才是充 分的，不同自动化测试策略和测试技术的引入是否会对测试结果产生影响以及测 试评测的可信度【2 5 】【2 6 】【2 刀。这些都使得对自动测试的可靠性分析的研究非常有必要。 ( 6 ) 自动化安全测试方面：该领域的研究集中在网络通讯设备和通讯协议的安 全性测试方面。随着网络的普及，网络信息问题也日益受到人们的重视，网络应 用程序以及网络设备，如防火墙等的安全性也成为测试的重要内容。针对网络安 全的有限状态自动测试机模型是该领域的主要研究内容【2 8 】【2 9 】【3 0 1 等，在该方面进行 6 第一章引言 了详细的研究。 1 3 2 当前主要的自动化测试框架 ( 1 ) 关键字驱动自动化测试框架【3 l 】【3 2 】：关键字驱动自动化测试框架是以关键词 句作为测试事件的驱动，以减少测试脚本的自动化开销，简化测试脚本编写为目 标，基于测试能够被分解成为若干独立步骤的观点提出的。关键字技术是将测试 步骤细化、分解，在此基础上建立一个能够被大量引用的功能词句库。关键字驱 动的实质是实现了“三个分离：f 1 界面元素名与测试内部对象名的分离；b 测试 描述与具体实现细节的分离：c 脚本与数据的分离； ( 2 ) 数据驱动的自动化测试框梨3 3 】：数据驱动自动化测试是一种把测试数据包 含在输入文件( o d b c 源，文本文件等) 中，并通过输入的数据来控制自动化测试 脚本执行的流程和动作的测试。输人测试数据从外部数据源读入，独立于测试脚 本程序开发的过程。数据驱动测试的一个好处就是用很少的代码量就可以产生大 量的测试用例。在这个框架中，变量不仅用来存放输入值，还用来存放输出的验 证值。对于数据而言，脚本仅仅是一个“驱动器 或者是一个传送机构。 ( 3 ) 混合测试自动化框架：最普遍的执行框架是将上面两种框架结合起来，取 其长处，弥补其不足。这个混合测试框架是各个项目根据自己项目的需要而灵活 使用的。 1 3 3g ui 自动化测试对象 g u i 自动化测试主要包括：界面显示的自动化测试和界面功能的自动化测试。 g u i 自动化测试是在有图形界面( g u i ) 的应用程序上做的黑盒测试，而不是模块级 的。不需要深入研究其内在结构，而是“表面化 地使用软件，同模块级的测试 一样，g u i 功能测试也是通过输入不同的数据序列后，得到应用的反馈来检测该 应用程序是否具有功能完备性。一般说来，g u i 的测试主要的对象是被测试应用 程序所用到的所有有关的g u i 的控件，例如：按钮、文本框、下拉列表、菜单等； 同时还包括基于这些控件的事件触发及事件的路由情况。g u i 的测试主要基于以 下几个方面进行测试：a g u i 的显示性：所有的控件是否都显示出来并且位置也是 正确的；b g u i 元素功能的完整性：即基于g u i 元素的事件是否能够触发以及触 发后会不会驱动元素的属性发生变化；c g u i 元素之间的依赖关系是否正确：g u i 元素之间按照设计文档所应当有的依赖关系是存在且正确；d g u i 界面的稳定性： 7 电子科技大学硕士学位论文 就是在经过反复的测试各个控件的功能依然能够正常的工作。 1 3 4 当前主要g ui 自动化测试工具 h p - m e r c u r y 公司提供的q u i c k t e s tp r o f e s s i o n a l ：是一个功能测试自动化工具， 主要应用在回归测试中。通过录制回放的方式自动捕获，检测，和重复用户交互 的操作。q u i c k t e s t 针对的包括传统的w i n d o w s 应用程序，以及现在越来越流行的 w e b 应用。 i b m 提供的r a t i o n a l 系列自动化测试工具：它可以在测试人员学习高级脚本 技术之前帮助其进行成功的测试。集成在测试人员的桌面m mr a t i o n a l t e s t m a n a g e r 上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动， 包括手动测试报告。 国产的自动化测试工具a u t o r u n n e r ：它是一款国产的自动化测试工具，可以 用来完成功能测试、回归测试。具有独立的脚本语言提供针对脚本跟踪和调试功 能的、支持m 测试和w i n d o w sn a t i v e 测试的自动化测试工具，是目前国内最好的 银行业务测试工具。支持自动录制脚本、所见即所得的资源和脚本编辑，稳定的 自动同步功能。 1 4 课题意义 从1 3 节中可以看出就软件测试自动化方面国内外在一些基本理论研究方面 已经取得了一些成果。但是这些理论还并不是很完善，有一些方面还很不成熟。 在g u i 自动化测试理论方面，虽然已经有商业软件但是g u i 自动化测试所要 用的数学模型还没有完全建立起来，g u i 自动化测试的失效模型和g u i 自动化测 试的覆盖率的计算都还没有完整的理论依据。 在g u i 自动化测试工具方面，当前的主流的测试软件一方面不能很好的适应 当前新的工厂式基于代码自动生成的开发模式。另一方面都不能对微软的w p f 应 用程序的测试有很好的支持。 本文对自动化软件测试技术的研究正是在这样的背景下展开的。对软件自动 化测试中的一些技术和方法进行研究，主要集中在g u i 自动化测试理论方面，自 动化测试工具和框架的研究和开发。这些对提高g u i 测试的可信度，保证自动测 试的有效性，提高测试工具的可扩展性和扩大自动测试工具的适用范围等都有极 大的现实意义和研究价值。 第一章引言 1 5 本文工作及章节安排 基于作者一年多来在自动化测试工具方面的开发和学习。依据开发过基于 w i n r u a n e r 和r o b o t 的自动化测试平台的经验和对n e t 的u ia u t o m a t i o n 库的了解， 首先提出了一个全新的简单可用的g u i 自动化测试的数学模型，并在这个模型的 基础上实现了一个基于e d s 的自动化测试软件系统。 本文的结构如下： 第一章，引言。主要是对软件测试进行简单的介绍，对手动测试的局限性做 了分析；同时提出了自动化软件测试技术，对国内外自动化测试的现状进行了简 单分析；然后介绍了一下当前主要的g u i 测试框架；最后分析了g u i 自动化测试 的对象和当前主要测试工具的不足； 第二章，基于n e t 下开发g u i 自动化测试工具的相关技术。这一章主要是对 在n e t 下开发自动化测试工具所要用的类库和一些关键的技术进行简单的介绍。 第三章，g u i 测试模型。当前的g u i 测试模型大多比较复杂，不具有实用性。 针对这一不足，作者根据自身的工作经验提出了一个新的简单而有效的g u i 自动 化测试模型；在这个测试模型的基础上给出了g u i 测试的失效模型和测试覆盖率 模型；依据这个模型来指导测试工具的开发和测试用例的编写。 第四章，e d s 自动化测试系统的功能设计。这一章根据e d s 自动化测试系统 的设计目标，对e d s 系统所要完成的功能进行了详细的描述。为下一章测试工具 的详细设计和实现提供依据。 第五章，e d s 自动化测试系统的设计与实现。这一章主要是设计和实现了一 个完整的g u i 自动化测试系统，出了各个模块的详细设计。 第六章，e d s 自动化测试系统的测试实。通过实验验证系统的各部分功能的 完备性。同时通过反复的测试验证了系统的稳定性和可靠性。 第七章，总结和展望。主要是对整个文章的一个总结给出了本文的一些主要 研究成果，同时明确了以后的研究方向。 9 电子科技大学硕士学位论文 第二章n e t 下开发g ui 自动化测试工具的相关技术 2 1w i n d o w s 消息机制 本文中研究的测试工具是在w i n d o w s 操作系统下实现的，w i n d o w s 操作系统 最大的特点就是其图形化的操作界面，图形化界面是建立在基于g u i 元素的事件 触发产生消息，再对消息进行处理的基础之上的。w i n d o w s 系统的驱动方式是事 件驱动，就是不由事件的顺序来控制，而是由事件的发生来控制，所有的事件是 无序的。对一个程序员来说，在编写程序时并不知道用户先按哪个按钮，也不知 道程序先触发哪个消息，它的任务就是对正在开发的应用程序要发出或要接收的 消息进行排序和管理。事件驱动程序设计是密切围绕消息的产生与处理而展开的 【3 4 1 。从外部来看是触发的事件来推动程序的发展的。 2 1 1win d o w s 消息 消息，就是指当外界触发某个应用程序的某个事件，w i n d o w s 发出的一个通 知告诉这个事件已经被触发。例如，单击鼠标、改变窗口尺寸、按下键盘上的一 个键；都会使w i n d o w s 发送一个消息给应用程序。消息本身是作为一个记录传递 给应用程序的，这个记录中包含了消息的类型以及其他信息。 w i n d o w s 操作系统中包括以下几种消息：a 标准w i i l d o w s 消息：这种消息以 w m 打头；b 通知消息：通知消息是针对标准w i n d o w s 控件的消息。这些控件包 括：按钮、组合框、编辑框、列表框、l i s t v i e w 控件、t r c c v i e w 控件、工具条、菜 单等。每种消息以不同的字符串打头；c 自定义消息：编程人员根据自己编程的需 要自定义消息； 消息可以由系统或者应用程序产生。系统在发生输入事件时产生消息。但并 不是每个控件都能接收消息，转发消息和绘制自身，只有具有句柄( h a n d l e ) 的控 件才能做到。有句柄的控件本质上都是一个窗体( w i n d o w ) ，它们可以独立存在，可 以作为其它控件的容器；对于没有旬柄的控件，如l a b e l ，是不能独立存在的，只 能作为窗口控件的子控件，它不能绘制自身，只能依靠父窗体将它绘制来。w i n d o w s 通过窗体句柄( h a n d l e ) 识别每个窗体、控件、菜单和菜单项的。当程序运行时，它 所包含的每个部件都有一个唯一确定的句柄同其它的部件相区别，旬柄在w i n d o w s l o 第二章n e t 下开发g u i 自动化测试工具的相关技术 a p i 中具有举足轻重的作用。 句柄的本质是一个系统自动维护的3 2 位的数值，在整个操作系统的任一时刻， 这个数值是唯一的。但该句柄代表的窗体释放后，旬柄也会被释放，这个数值又 可能被其它窗体使用。也就是说，句柄的数值是动态的，它本身只是一个唯一性 标识，操作系统通过句柄来识别和查找它所代表的对象。 由于有了句柄，窗体能够接收消息，也就知道了该什么时候绘制自己，绘制 子控件，知道了鼠标在什么时候点击了窗口的哪个部分，从而作出相应的处理。 2 1 2w i n d o w s 消息系统组成 w i l l d o w s 消息系统由三部分组成： 消息队列：w i n d o w s 为每一个应用程序( 进程) 建立一个消息队列，并维护该队 列。应用程序必须从自己的消息队列获取消息，然后根据消息句柄分派给程序的 某个窗口。 消息循环：应用程序通过消息循环机制从消息队列获取消息，再把消息分派 给某个窗口，然后继续从消息队列检索下一条消息，再分派给某个窗口，如此循 环不止，直到应用程序关闭。 窗口过程：每个窗口都有一个窗口过程，来接收和处理传递给它的消息。窗 口过程是一个回调函数，处理一个消息后，它要返回一个值给w i n d o w s 。 2 1 3w p f 的事件路由 w p f 做为微软未来界面的一个主要发展方向，当前的许多自动化测试工具都 不支持这一种新的g u i 界面，这也是本文实现的测试框架对g u i 元素的支持的一 个主要技术，这里对w p f 的相关技术进行一些研究。 2 1 3 1w p f 体系结构 w p f 是w i n d o w s 操作系统中一次重大变革，与早期的g d i + 不同。w t f 是基 于d i r e c t x 引擎的，支持g p u 硬件加速，也可以使用软件绘制。高级别的线程进 行绘制，提高使用者的体验。自动识别显示器分辨率并进行缩放。v i s t a 就是一个 非常典型的例子。w p f 主要编程模型是通过托管代码公开鲥3 5 1 。 电子科技大学硕士学位论文 囡幽 图2 1w p f 系统结构图 图2 1 说明了w p f 的主要组件。对于结构图中p r e s e n t a t i o n f r a m c w o r k 、 p r e s e n t a t i o n c o r e 和m i l c o r e 三个部分是w p f 的主要代码部分。在这些组件中， 只有一个是非托管组件那就是m i l e o r e 。 2 1 3 21 | i p f 元素树和事件路由 典型的w p f 应用程序中包含许多元素。无论这些元素是在代码中创建的还是 在x a m l 中声明的，它们都由共同所在的元素树关联起来。 路由事件使用以下三个路由策略之一： 冒泡：针对事件源调用事件处理程序。路由事件随后会路由到后续的父元素， 直到到达元素树的根。大多数路由事件都使用冒泡路由策略。冒泡路由事件通常 用来报告来自不同控件或其它g u i 元素的输入或状态变化。 直接：只有源元素本身才有机会调用处理程序以进行响应。这与w i n d o w s 窗 体用于事件的“路由 相似。但是，与标准c l r 事件不同的是，直接路由事件支 持类处理，而且可以由e v e n t s e t t e r 和e v e n t t r i g g e r 使用。 隧道：最初将在元素树的根处调用事件处理程序。随后，路由事件将朝着路 由事件的源节点元素( 即引发路由事件的元素) 方向，沿路由线路传播到后续的 子元素。在w p f 中提供的输入事件通常是以隧道冒泡对实现的。隧道事件有时 又称作p r e v i e w 事件，这是由隧道冒泡对所使用的命名约定决定的。 1 2 第二章n e t 下开发g u i 自动化测试工具的相关技术 路由事件在w p f 平台中的常见用法之一是用于事件输入。在w p f 中，按照 约定，隧道路由事件的名称以单词“p r e v i e w 开头。输入事件通常成对出现，一 个是冒泡事件，另一个是隧道事件。例如，k e y d o w n 事件和p r e v i e w k e y d o w n 事 件具有相同的签名，前者是冒泡输入事件，后者是隧道输入事件。偶尔，输入事 件只有冒泡版本，或者有可能只有直接路由版本。当存在具有替换路由策略的类 似路由事件时，路由事件主题交叉引用它们，而且托管引用页面中的各个节阐释 每个路由事件的路由策略。 为了说明输入事件处理的工作方式，请考虑下面的输入事件示例。在下面的 树图中，叶元素# 2 是先后发生的p r e v i e w m o u s e d o w n 事件和m o u s e d o w n 事件的 源，其基本的流程如图2 2 。 图2 - 2 w p f 的事件路由图 2 2 n e t 的a u t o m a tio n 库 m i c r o s o f tu i 自动化是m i c r o s o rw i n d o w s 的新增辅助功能框架，可用于支持 w i n d o w sp r e s e n t a t i o nf o u n d a t i o n ( w e d 的所有操作系统。u i 自动化对桌面上的大 多数用户界面的g u i 元素提供编程访问，从而使辅助技术产品能够向最终用户提 供有关g u i 元素的信息，并通过标准输入以外的方式操作g u i 元素。u i 自动化 还允许自动化测试脚本与g u i 元素进行交互。 u i 自动化