（计算机应用技术专业论文）面向gui的自动化回归测试技术研究.pdf

摘要 图形用户界面g u i ( g r a p h i c a lu s e ri n t e r f a c e ) 是现代软件的重要组成部分。由 于软件的功能主要是通过图形用户界面调用的，所以g u l 测试是现代软件测试的 关键环节。快速原型软件开发方法( r a p i dp r o t o t y p i n g ) 的普遍采用使得g u i 回归 测试变得尤为重要。目前业界采用的商用自动化g u i 测试工具均采用c p ( c a p t u r e p l a y b a c k ) 机制，它没能对g u i 的回归测试进行很好的支持。本文在国 家8 6 3 计划项目“基于高性能宽带通信网络的软件支撑体系研究”的支持下，对g u i 的自动化回归测试技术进行了研究。 本文分析了g u l 测试的特点及其面临的挑战。通过对目前g u i 测试工具优缺 点的分析，结合当前的自动化测试理论和技术，提出了一种改进的自动化测试解 决方案，重点从测试用例生成、测试结果验证和测试用例维护三方面对g u i 测试 过程提供支持，减少了人机交互的次数，简化了测试用例的生成和维护过程，避 免了繁琐的手工测试结果验证过程。本文还给出了依据改进的自动化测试框架所 开发的测试工具a t t i c 的功能模块设计以及原型实现。最后总结了课题研究的主 要工作、对下一步工作进行了展望。 本课题研究成果可以应用于包含g u i 的软件自动化测试领域。本课题的研究 有助于提高包含g u i 的软件测试的自动化程度，降低测试成本，提高g u 软件产 品的质量。 关键词：图形用户界面；回归测试；数据驱动：测试用例维护； 自动化测试框架 r e s e a r c ho na u t o m a t e dr e g r e s s i o nt e s t i n gt e c h n o l o g i e so fg u i s a b s t r a c t g r a p h i c a lu s e ri n t e r f a c e s ( g u i s ) c o n s t i t u t eav i t a lp a r to ft h et o d a y ss o f t w a r e s i n c et h ef u n c t i o n a l i t yo ft h ea p p l i c a t i o ni si n v o k e dt h r o u g hg u i ，g u it e s t i n gp l a y sa c r i t i c a lr o l ei nt o d a y ss o f t w a r et e s t i n g b e c a u s eg u i sa r et y p i c a l l yc r e a t e du s i n gr a p i d p r o t o t y p i n g , r e g r e s s i o nt e s t i n go fg u i s i sb e c o m i n gi n c r e a s i n g l yi m p o r t a n t t h e r ee x i s t m a n yc o m m e r c i a lt o o l sf o rt e s t i n gg u i s ，w h i c ha r ec a p t u r e p l a y b a c km e c h a n i s m b a s e d h o w e v e r ，t h e yh a v e n tp r o v i d e de n o u g hs u p p o r tf o rr e g r e s s i o nt e s t i n go fg u i s b a s e d o nt h er e s e a r c hw o r ko ft h en a t i o n a lh i g h - t e c hd e v e l o p m e n tp r o j e c t ( 8 6 3p r o j e c t ) “r e s e a r c ho ns o f t w a r e s u p p o r ts y s t e m b a s e do n h i 【g hp e r f o r m a n c e b r o a d - b a n d c o m m u n i c a t i o nn e t w o r k ”，o u rs t u d yf o c u s e so na u t o m a t e dr e g r e s s i o nt e s t i n go fg u i s i nt h i st h e s i s ，t h ec h a r a c t e r i s t i c sa n dc h a l l e n g e so fg u i st e s t i n ga r ea n a l y z e d a f t e r a n a l y z i n gt h ec o m m e r c i a lt o o l s ，w ep r o p o s e a ni m p r o v e dd a t a d r i v e nt e s t i n gf r a m e w o r k ， a u t o m a t i n gt h ep r o c e s so ft e s tc a s e sg e n e r a t i o n ，t e s tr e s u l t sv e r i f i c a t i o na n dt e s tc a s e m a i n t e n a n c e ，w h i c he f f e c t i v e l ys u p p o r t sr e g r e s s i o nt e s t i n go fg u i s i tm a k e sg u i s t e s t i n gm u c hm o r ee f f i c i e n ta n de f f e c t i v eb e c a u s ei tc a nn o to n l yg r e a t l yd e c r e a s et h e t i m e so fh m i ( h u m a nm a c h i n ei n t e r a c t i o n ) d u r i n gt e s tc a s e sg e n e r a t i o nb u ts i m p l i f y t e s tc a s e sm a i n t e n a n c ea n de v e rl a b o r i n t e n s i v ev e r i f i c a t i o np r o c e s s b e s i d e s ，t h e m o d u l ed e s i g na n dt h ep r o t o t y p ei m p l e m e n t a t i o na r ep r e s e n t e db a s e do no u rf r a m e w o r k - n a m e dg a r t a a n dac o n c l u s i o na n df u t u r ew o r ka r eg i v e n t h er e s e a r c hr e s u l t sc a nb ea p p l i e di n t oa u t o m a t e dt e s t i n go fs o f t w a r ew i t hg u i s ， w h i c hc a nn o to n l yi m p r o v et h ed e g r e eo fa u t o m a t i o ni nt e s t i n g , b u td e c r e a s et h ec o s t f o rt e s t i n ga n dm a k es o f t w a r eq u a l i t ya s s u r e d k e yw o r d s ：g u i ；r e g r e s s i o nt e s t i n g ；d a t a - d r i v e n ；t e s tc a s e sm a i n t e n a n c e ； a u t o m a t e dt e s t i n gf r a m e w o r k 大连海事大学学位论文原创性声明和使用授权说明 原创性声明 本人郑重声明：本论文是在导师的指导下，独立进行研究工作所取得的成果， 撰写成博士硕士学位论文：匦囱鱼型! 笪自塾丝回坦捌这整盔盟窥：。除论文 中已经注明引用的内容外，对论文的研究做出重要贡献的个人和集体，均已在文 中以明确方式标明。本论文中不包含任何未加明确注明的其他个人或集体已经公 开发表或未公开发表的成果。 本声明的法律责任由本人承担。 论文作者签名尊于、箩善讼旃弓愚日 l 7 学位论文版权使用授权书 本学位论文作者及指导教师完全了解“大连海事大学研究生学位论文提交、 版权使用管理办法”，同意大连海事大学保留并向国家有关部门或机构送交学位 论文的复印件和电子版，允许论文被查阅和借阅。本人授权大连海事大学可以将 本学位论文的全部或部分内容编入有关数据库进行检索，也可采用影印、缩印或 扫描等复制手段保存和汇编学位论文。 支0 辫筌瓷驴兀 第1 章绪论 1 1 选题的背景和意义 图形用户界面g u i ( g r a p h i c a lu s e ri n t e r f a c e ) 的出现是软件发展历程中一个重 要的里程碑，它给软件系统的使用者带来了方便。与此同时，它也给软件测试人 员带来了全新的挑战。图形用户界面是软件系统使用者同系统本身进行交互的接 口，系统的功能是通过用户对图形用户界面的操作来调用的，系统产生的结果也 是通过它反馈给用户的， 据统计，图形用户界面的代码量占包含它的软件系统的5 0 左右【蚓。软件系 统的图形用户界面的正确性对于确保整个软件系统的操作的正确性是至关重要 的。为了确保软件正确性，测试是最直接最有效的手段。所以，图形用户界面 的测试是非常重要的，它是对包含图形用户界面的软件系统测试的关键。然而， 正如每个测试人员和质量保证人员所了解的那样，测试并改正发现的错误并不是 一件简单的事隋，因为随着软件规模的扩大和软件复杂度的提高，对测试的要求 也变得越来越高i i 。人们尝试采用自动化测试工具去取代原有的手动测试，特别 是随着图形用户界面的出现和大规模应用，原有的软件测试和质量保证人员面临 着很多全新问题和挑战，它们不仅是技术层面的，还有方法论层面的。 1 g u i 手工测试已经无法满足s u i 测试要求 传统的g u l 手工测试( m a n u a lt e s t i n g ) 方法虽然可以发现绝大部分软件 缺陷，但是发现的时间比较晚，往往是在b e t a 测试阶段或者临近产品发布的 时候，而缺陷发现得越晚，修复就越困难，费用也越高【2 6 】；另外，对于g u i 的手工测试，效率也是一个不得不考虑的因素，同时手工测试过程本身同样会 出现错误【2 ”。 2 测试用例生成过程极其繁琐 包含g u i 的软件系统输入输出图形化的特点使得传统的针对命令行提示符 应用的测试用例生成方法无法应用于g u i 测试用例的生成过程。冈此，业界 目莳普遍采用的是基于捕获回放( c p ，c a p t u r e p l a y b a c k ) 机制的测试用例生成 方法，该方法虽然有一定的针对性，但测试用例生成过程要求大量的人机交互， 并且每一步操作都要求极高的准确性。据统计，产生一个包含5 0 个事件的测 试用例需要花费2 0 至3 0 分钟时问，为了达到一定的测试覆盖率，一个测试人 员一般至少需要开发1 0 0 - 3 0 0 个测试用例，过程之复杂，要求之苛刻显而易见。 3 测试执行过程要求高 针对g u l 的测试执行过程实际上是测试脚本在被测g u l 上的执行过程， 因为测试脚本包含着测试用例和与之对应的期待结果，基于捕获回放机制生 成的测试脚本是基于场景的，不仅脚本可读性差，调试复杂，更重要的是脚 本维护困难，一个微小的错误都会导致测试执行过程无法正常执行1 2 j 。 4 测试结果的验证过程效率低、出错率高 包括基于捕获回放机制的测试工具在内，目前的测试工具对测试结果的验 证过程的支持是非常有限的，所以测试人员往往需要在测试执行完毕后手动去 验证测试结果的f 确性，这样做不仅效率低，而且会产生很多人为的错误，无 法有效地发现被测g u i 对应软件系统潜在的缺陷。 5 回归测试阶段的测试用例可重用性差 g u i 输入输出状态的特殊性导致了g u i 测试用例的特殊性，同时g u i 大 多采用快速原型法创建，这决定了对g u i 的改动是极其频繁的，回归测试的 重要性显现无疑，而作为一个新的研究领域，目前没有比较成功的方法来解决 这个问题【2 1 。c p 工具作为业界广泛采用的解决方案虽然可以通过重新生成测 试用例的方法生成回归测试用例集，但从效率和节约成本的角度分析是不可取 的，因为测试用例的生成过程异常繁琐和耗时，放弃原有的测试用例，造成了 大量的人力和物力的浪费，大大增加了g u l 软件系统的测试成本。 基于以上闻题的总结和分析，本课题基于数据驱动自动化测试框架技术和美国 学者a t i f m m e m o n 的测试用例修复理论，提出了经过改进的g u i 自动化测试框架， 用于g u i 的自动化测试过程，重点对回归测试过程提供了有力支持。 本课题来源于国家8 6 3 计划项目“基于高性能宽带通信网络的软件支撑体系研 究”( n o 2 0 0 4 a a l l 6 0 1 0 ) 。作为项目的一个组成部分，软件产业国际化技术支撑 平台包括对日软件出口基地平台和软件质量保证平台两部分内容。其中软什质量 保证平台是整合大连市相关骨干企业现有的对f l 软件开发产品集成测试系统，结 合支撑软件中的软件配置管理系统j b c m 和软件测试管理与质量评价系统开发集 管理、配置、测试和评价与一体的软件质量保证平台。本课题主要承担的是g u i 自动化测试技术的研究工作。 本课题的研究目的和意义在于：测试人员可以把更多的精力放在g u i 测试用倒 的设计上，无需考虑测试执行过程和测试结果的验证过程技术细节：测试用例的 生成和维护得到了支持，从而有效减少了g u i 回归测试过程中测试人员的工作量， 最终达到高效进行g u i 软件测试、降低测试成本、提高g u i 软件产品的质量的目 的。 1 2 领域现状概述 作为软件系统的前端，g u i 提供给用户可视化的与系统交互的接口，大大简 化了操作的复杂度。与此同时，它也给包含g u i 的软件的测试带来了挑战。相对 命令行提示符应用( c o m m a n dl i n e b a s e da p p l i c a t i o n s ) 的输入方式而言，包含g u i 的软件系统的输入如鼠标移动和点击、菜单项选取、文本输入更加复杂；g u i 输 出的多样性和复杂性也是命令行提示符应用所不具备的。因此原有的测试命令行 提示符应用的方法无法应用于包含g u i 的软件系统的测试。目前对于g u i 的自动 化测试主要有如下几种方法： 1 手写静态测试自动化方法 该方法应用静态的测试脚本和固定的测试用例在被测应用的g u i 上运行。这 种自动化实际上只是体现在测试执行过程中【l j ，并且脚本需要反复调试，健壮性差。 2 随机输入自动化测试方法 这种方法的原理是让计算机模拟真实用户去进行各种g u i 操作【2 1 】，只不过是 测试过程本身涉及的行为是随机产生的，顺序也是随机产生的，它虽然可以发现 些测试人员无法发现的缺陷，但机会是很偶然的，因为测试程序本身并不知道 对于它所产生的每步操作及被测软件系统应该是如何反应的。 3 基于捕获回放( c p ) 机制的测试自动化方法 这种方法的本质是由测试人员与包含被测g u i 的软件系统进行交互，基于c p 的工具负责将交互过程的场景和g u i 操作捕获( c a p t u r e ) ，生成测试脚本，再将 这些操作进行回放( p l a y b a c k ) 。其优点是脚奉生成相对容易；但是缺点也很明显， 交互过程对测试人员的操作要求极高，并且脚本的可重用性非常差，对于回归测试 过程无法提供有效支持，这些缺点使得该方法无法完美解决g u l 测试的主要问题。 4 基于模型描述的自动化方法 这种方法的关键是对被测系统的行为进行形式化表述，形成模型，然后采用 有穷状态机f s m ( f i n i t es t a t em a c h i n e ) 从模型中产生测试用例n 通过这种方法 产生的测试用例可以有效的测试系统的具体行为是否满足系统设计要求，同时可 以根据测试标准有选择地进行测试用例生成和运行，但是缺点在于目前的系统规 模越来越大，对于系统行为的模型描述越来越困难。这也是为什么这种方法一直 无法在业界推广的一个主要原因。 5 基于数据驱动框架的自动化测试方法 一种自动化测试框架是许多假设、概念、和实践的集合，它能为自动化软件 测试提供支持【3 ”。数据驱动测试是一种框架，测试输入和输出是从数据文件( 数 据池，o d b c 源，c v s 文件，e x c e l 文件，d a o 对象，a d o 对象等) 中读取的， 然后赋值给获取的或者手动编码的脚本中的变量。测试脚本包含了每一个测试步 骤、数据文件的读取以及测试状态的日志和信息。这种方法的优点在于它将测试 执行过程和测试用例的生成过程分离，测试人员可以专心设计测试用例而无须过 多的考虑用例的执行过程方面的细节，并且测试结果的验证过程也因为测试数据 的脚本化而变得相对容易，测试人员完全可以采用其它自动化手段进一步完成测 试结果的自动化验证，从而大大提高测试过程的自动化程度，提高测试效率。 第一种方法仅仅适用于g u i 不作修改而只是对部分行为进行改进后的回归测 试；第二种方法虽然可以发现测试人员难以发现的缺陷，但由于每一动作的随机 性，使得根本无法将发现缺陷所经过的步骤一一再现，可以说，这种方法根本无 法支持回归测试过程；第三种方法虽然可以比较方便地生成测试脚本，但测试结 果的验证需要在c p 过程结束之后由测试人员手工完成，并且由于测试脚本是基 于场景的，一个哪怕微小的布局的变化都会导致测试脚本失灵，而修复测试脚本 既需要专业的编程背景，又要十分熟悉被测系统的行为，因而在进行回归测试的 时候，这些第三方提供的所谓的全自动测试工具变成了“全自动”；第四种方法 虽然可以通过对原系统和修改的系统的结构描述的比较来解决回归测试集的选择 问题，但前提足需要有一个比较通用的对于g u i 系统的形式化描述；第五种方法 4 是目前基于框架的自动化测试的一个比较具有代表性的方法，与上面的四种方法 相比，它不但可以将测试设计过程同测试执行过程分离，而且具有更多支持回归 测试过程的特点。 1 3 本文的主要研究工作 基于1 1 节中对目前g u i 测试方法存在问题的总结和分析，本文通过大量阅 读国内外相关领域文献，借鉴实际项目经验，提出了一套比较完整的g u i 自动化 测试解决方案，主要研究内容包括如下几个方面： 1 ) 测试用例生成技术：作为本文研究的重点之一，我们尝试采用改进的基于 c p # d l s t j 的测试用例生成技术。该技术首先对被测g u i 所包含的对象进行遍历， 并将信息填充于测试序列编辑器当中，然后由测试人员从编辑器中依次指定目 标操作对象及其对应的事件，并插入测试点( 待验证的对象属性) ，系统将自 动捕获这些信息，生成测试用例，这使得测试人员只需进行少量的人机交互就 能快捷、准确地生成测试用例。 2 ) 测试结果验证技术：本文的另一个研究重点是对三种典型的g u i 测试结果 的验证方式的研究，即具体对象验证、总结算验证和在前两者基础上的优化验 证。这三种方式各有优势，基本上可以满足g u i 测试对于验证方式的需求。 测试结果的自动验证过程将测试人员从原本繁琐的手工过程中解脱出来，更避 免了人为错误造成的缺陷被隐藏的情况发生。 3 ) 回归测试用例生成技术：该方面重点研究了基于测试用例修复技术的测试 用例维护。一个完整的回归测试用例集由修复的测试用例和新生成的测试用例 两部分组成，有了修复的测试用例，只需要再按照前面提到的测试用例生成方 法就可以生成回归测试用例集。 4 ) 测试脚本生成方法：目前基于场景的测试脚本中不仅包含测试用例，更多 的是与之对应的场景信息和底层实现细节，脚本可读性差，难于维护。本文的 研究工作在于让测试脚本仅包含测试用例，去除了场景信息和底层实现细节， 从而使得脚本可读性和可维护性大大增强。 5 ) 测试执行方法：测试执行过程是山测试脚本驱动的。本文要达到的目标是 对测试脚本的解析以及对测试用例包含的基本对象操作的底层实现。 在上述技术研究的基础上，我们开发了图形用户界面自动化测试工具a t t i c ， 实现了w i n d o w s 环境下针对钟语言编写的g u i 应用程序的自动化测试功能，用 以验证方案的可行性，并力求配合8 6 3 项目软件质量保证平台的建设。尽管a t t i c 目前支持的是w i n d o w s 下甜语言编写的g u i 应用程序的测试，但其思想和技术 可以进一步推广到其它平台下的g u i 应用程序的测试中。 g u i 自动化测试解决方案的研究对于g u i 软件测试具有重要的意义：测试人 员可以把更多的精力放在g u i 测试用例的设计上，无需考虑测试执行过程和测试 结果的验证过程技术细节，测试用例的生成和维护得到了自动化支持，从而有效 较少了g u i 回归测试过程测试人员的工作量，最终达到高效进行g u i 软件测试、 降低测试成本、提高g u i 软件产品的质量的目的。 1 4 本文的组织结构 本课题对当前的g u i 测试技术和g u i 测试存在的问题进行了分析，并结合当 前自动化测试工具的功能和缺陷总结，提出了一套比较完整和有针对性的g u i 自 动化测试解决方案，对回归测试过程进行了有力支持。课题的实现部分开发了一 个w i n d o w s 环境下的针对c 带语言编写的包含g u i 的软件的测试工具，用以验证 方案设计的可行性。 论文结构一共包括六章，分别为： 第一章说明了选题的背景和意义，介绍了本文的主要研究工作。 第二章介绍了g u i 测试相关的概念并论述了g u i 测试与包含g u i 的软件测 试的关系。 第三章给出了数据驱动的g u i 自动化测试框架和测试用例生成、测试用例修 复、测试结果验证的关键技术。 第四章介绍了改进的g u i 自动化测试框架g a r t a 和基于该框架的系统设 计。 第五章给出了原型系统a t t i c 的实现。 第六章总结了本文的主要工作，并且提出了下一阶段的工作展望。 第2 章面向g u i 的自动化测试 2 1g u i 测试所涉及的相关概念 2 1 1g u i 的定义 图形用户界面g u i ( g r a p h i c a lu s e ri n t e r f a c e ) 是一种软件系统的等级化的、图 形化的前端，这种系统接受的输入是来自一个固定的事件集合中由用户和操作系 统产生的事件，经过处理生成图形化输出。一个g u i 含有许多个图形对象，丽每 个对象又有固定的属性集合。 g u l 系统用户通过触发事件同系统进行交互，对图形对象进行操作。例如： ， 用鼠标托动某个图标，将一个文件夹放入回收站，从资源管理器的文件目录树型 结构当中选择某个文件夹等。以上这些事件都会导致所使用的系统的状态发生变 化。 很明显，g u i 有四个最突出的特点： 。 ( 1 ) 结构层次化，这种结构的层次性反映在窗体、对话框以及其它图形对象 的分组上。一个窗体中可能包含若干个子窗体，而不同的窗体中也可能含有若干 其它图形对象。 ( 2 ) 媒介作用，g u i 作为用户和系统交互的媒介，它起的作用不仅在于给用 户提供更好的用户体验( u s e re x p e r i e n c e ) ，更重要的是将系统的底层业务逻辑同 用户隔离开，这就决定了对g u i 的测试实际上跟底层代码的测试是两个不同的概 念。 ( 3 ) 事件驱动输入，对于每一个有效的事件，都会有一个对应的处理，只不 过是有些处理的结果是维持原有状态不变，而有些则是让系统转变到下一个状态。 ( 4 ) 输入和输出都是图形化的，这使得系统用户可以更方便直观地使用系统， 但对于g u i 测试人员来讲无疑是一个巨大的挑战，幽为传统的对于基于命令行提 示符应用程序的测试方法根本无法应用于g u i 测试过程当中。 2 1 2g u i 测试用例 在介绍g u i 测试用例之前，有必要先对如下几个概念进行说明。 1 g u i 的状态( s t a t e ) 。一个g u l 由若干分等级的窗体组成，而每一个窗体 里面都含有若干个相对独立的功能部件( 随着编程技术的日益进步，g u i 的开发 逐渐变得简单，程序开发人员可以方便地使用预先定义好的控件或者组件， m i c r o s o f t 的新一代支持面向对象开发的集成开发环境v i s u a ls t u d i o n e t2 0 0 3 ， 2 0 0 5 里就提供了非常多的功能强大且独立性很高的控件和组件) 。每个部件会有 许多属性( p r o p e r t y ) ，这些属性控制着包括部件位置( p o s i t i o n ) 、大小( w i d t h ， l e n g t h ) 、颜色( c o l o r ) 、可见性( v i s u a l ) 等许多方面，每个属性的变化都会导 致整个g u i 系统的状态的变化f i 】，所以哪怕有一个部件的一个属性不同，g u i 的 状态也是不同的。 2 g u i 的事件( e v e n t ) 。用户与g u i 系统的交互是通过触发事件来完成的i ”。 一个事件的执行结果是使得g u i 系统由一个前提状态到达一个结果状态。正如a t i f m m e m o n 的形式化描述那样，一个事件可以表示为如下的三元组 ，其中n a m e 是指事件的名称；p r e c o n d i t i o n 是一组前提条件 的集合，是一组布尔关系，例如i s c u r r e n t d e s k t o p b a c k g r o u d p i c t u r e ( w i n d o w s x p ) 表示当前桌面墙纸是名为“w i n d o w s x p ”的图片，只有这些布尔关系全部为真的 时候，才表示该事件的初始状态是可以达到的，该事件才是可以执行的；e f f e c t 是 一个结果状态。所以事件“更换桌面墙纸”可以描述为： n a m e ： c h a n g e d e s k t o p b a c k g r o u d p i c t u r e ( d e s k t o p ：w i n d o w s x p ， n e w p i c t u r e ： a u t u m n ) ； p r e c o n d i t i o n ：i s c u r r e n t d e s k t o p b a c k g r o u d p i c t u r e ( w i n d o w s x p ) ； e f f e c t ：d e s l 【t o p b a e k g r o u d p i c t u r c ( a u t u m n ) ； 有了上面对于g u i 事件的描述，就可以解释什么是g u i 测试用例。要对g u i 进行测试，就需要执行针对该g u i 的事件序列。 定义：一个合法的g u i 事件序列e 1 ；e ：；e 3 “；岛，其中眈，( o i n ) 可以紧随着e 执 行。例如，如图2 1 所示，在m i c r o s o f tw o r d 中，“插入”( i n s e r t ) 事件执行之 后可以紧随着执行“数字”( n u m b e r ) 事件，所以事件序y i j 是合法 的( 忽略键盘快捷键) 。 图2 1m i c r o s o f tw o r d 主界面截图 h g 2 1m a i nw i n d o wo fm i c r o s o f tw o r d 定义：g u i 测试用例tb 。，b ；p ：；巴；巴) ，其中乳是对于t 的初始状态， b ；：；已“；巴是一个台法的g u i 事件序列。 如果测试用例t 中指定的初始状态s 。是不可达的或者事件序列 e 。；e ：；已；巴是不合法的，那么t 是不可执行的。 很明显，一个测试用例可以用于回归测试过程需要满足的条件还是很苛刻 的，所以对于g u i 的改动，哪怕是布局方面的个细微变化，都有可能导致所有 用到某个事件的测试用例变得不可执行。而g u i 多是采用快速原型法( r a p i d p r o t o t y p i n g ) 开发的，更改是相当频繁，这就使得原有的花费大量人力物力得到的 测试用例变得无法执行。而重新运用原有的方法产生测试用例，又会消耗更多的 资源。 2 2g u i 测试的步骤 本课题研究的重点在于开发技术和工具束有效地支持g u i 的回归测试过程， 但在这之前，有必要先来描述一下g u i 测试的过程。g u i 需要特殊的测试技术， 但是实现这些技术的过程跟传统的过程是一样的【“。下面的部分提供了用来进行 g u i 测试所需要的几个步骤： 1 确定测试目标 通过覆盖标准的定义来确定测试目标。一个g u i 覆盖标准或许会要求执 行所有的用户接口事件来确定所执行的行为是否正确； 2 产生测试输入 从软件规约( s p e c i f i c a t i o n ) 和结构产生测试用例，对于g u i 而言，这 些测试输入主要是由鼠标点击、菜单选择、文本输入和对象操作组成，也就 是上面提到的事件序列： 3 产生期待输出 产生期待的输出同实际的结果进行比较，对于g u l 而言，这些期待 输出包括屏幕截图或者窗体对象的坐标等； 4 执行测试用例并验证输出 在被测应用程序上执行测试用例，然后比较实际结果和期待结果。该过 程一般是出测试先知( t e s to r a c l e ) 负责完成的； 5 确定完成的测试是否达到预期的测试目的 一旦所有的测试用例执行完毕，测试人员分析被测软件并检查其被测试 的部分，对于g u i 而言，这种分析主要是检查事件和与其对应的g u i 状态； 测试以后，对发现的缺陷进行修正，而这些修正需要回归测试来确定其结果 的正确性。 6 执行回归测试 回归测试集由两部分组成( a ) 原有测试用例集合的一个子集( 用来测试 原程序被修正的部分) ：( b ) 新的测试用例集合( 用来测试原程序中a 集 合没有测试到但是受到影响的部分) 。对rg u i 而言，回归测试包括分析 g u i 对象布局的变化i ”。 i j 2 3g 自动化测试的生命周期 自动化测试的生命周期有多长? 自动化测试的价值只有在被测应用程序修改 以后才能体现出来i l j 。除了几种少见类型的测试( 计时和压力测试) 之外，在对程 序进行修改之前重新进行测试等于在浪费时间：因为它只能发现跟以前一样的错 误。但是一个测试不会永远存在下去。在一定程度上，软件产品的修改会导致原 有的测试用例的失效。这些测试要么进行修复要么直接从测试集( t e s ts u i t e ) 中 剔除。如果j 下在使用的是基于c p 的工具，就要重复之前的测试用例生成过程， 这样傲可能会花费比第一次更多的人力和物力。如果你想使用测试脚本，就必须 理解当前的脚本，修改它，调试它，然后再运行它。如果你是一个有相当经验的 测试人员，去修复一个测试脚本可能会比重新生成新的脚本更节约成本。 t e s t c r e a t e d 。一- r e s t l r u n t e s t c o d e ”“r u n - - p 。”c h a n g e t e s f c o d e c h a n g e 图2 2 测试用例的生命周期 f i g 2 2l i f e c y c l eo f t e s tc a s e s t e s tr u n ： l t sd e a d 如图2 2 所示，测试用例的可重用性的高低直接影响黄测试用例的生命周期长 短。所以一个典型的问题摆在面前，人们往往看到的是自动化测试给软件测试带来 的效率和测试费用的降低，却往往低估甚至忽视了一个很重要的问题，那就是如 何能延长测试用例的生命周期。而g u i 通常是以快速原型法创建的，对它的修改 是非常频繁的，所以如果不能延长测试本身的生命周期，那就无法平衡开发自动 化测试的费用。 2 4g o i 回归测试 i e e e 对于回归测试( r e g r e s s i o nt e s t i n g ) 的定义为( i e e e 6 1 0 1 2 9 0 ) r e g r e s s i o nt e s t i n gi st h e “s e l e c t i v er e t e s t i n go fas y s t e mo rc o m p o n e n tt ov e i l f y t h a tm o d i f i c a t i o n sh a v en o tc a u s e du n i n t e n d e de f f e c t s 实际上，这种定义就是要确保以前已经通过测试的程序部分在程序进行修改之 后依然可以通过测试，并且程序的修改所影响的其他部分也可以通过测试。 学者b e i z e r 将回归测试定义为任何旨在表明软件的行为除非在需要的时候不 会发生变化的重复的测试。 学者b a l l 认为，回归测试选择分析的目标是用最简约的方式在不降低测试质 量的前提下回答下面的问题： 已知测试输入t 和程序o l d 和n e w ，n e w ( t ) 和o l d ( t ) 具有相同的发现行为 吗? 虽然学术界对于常规软件的回归测试已经有了足够的重视，但到目前为止， 除了美国马里兰大学的教授a t i fm m e m o n i z t j f l l 学者lw h i t e t z g ，几乎没有其他被 报道的专门针对g u i 的回归测试的研究。许多针对常规软件的回归测试策略已经 提了出来弘3 1 3 甜。一种策略是全部重测策略( r e t e s t a l ls t r a t e g y ) ，它主张将可用 的所用测试用例用于回归测试过程，但是这种策略需要大量的人力资源和物力资 源的消耗，另外受到原程序修改的影响，可以用于直接回归测试的测试用例数量 相当有限，这在很大程度上限制了回归测试发现问题的可能性。另外一种策略是 有选择性的重测策略( s e l e c t i v er e t e s ts t r a t e g y l 3 3 ，3 5 删) ，它试图通过只对选定的部 分程序进行测试的方法来减少所需的费用。这两种策略都将注意力放在两个问题 上：( 1 ) 从原有的测试用例集合中选择一个合适的子集： ( 2 ) 识别被测软件需 要进行额外测试的部分。那些导致程序结构中不同路径的执行的测试用例便可以 用于回归测试。 2 5g 测试与包含g i l l 的软件测试的关系 软件测试是确保软件产品质量的最直接最有效的手段。g u i 软件是现代软件的 典型代表，对g u i 软件的测试也随着其应用的扩大和规模的增大而变得越来越罩 要。g u i 在包含它的软件系统中起着极为关键的作用，它作为桥梁联系着系统用 户和底层逻辑代码。g u i 软件的输入和输出都是图形化的，软件系统的币确性是 表现在g u l 状态的正确性上的。底层逻辑代码通过了基本的单元测试环节是不是 意味着g u i 软件系统就基本没有缺陷了呢? g u i 测试可以回答这个问题。 图2 3g u i 与底层逻辑代码交互示意图 f i g 2 , 3i n t e r a c t i o n sb e t w e e ng u ia n du n d e r l y i n gc o d e s 从底层代码的角度来看，g u i 测试是一种特殊的集成测试( i n t e g r a t i o n t e s t i n g ) 。如图2 3 所示，对g u i 对象的操作会转化成相应的底层逻辑代码调用， 底层逻辑代码执行结果会通过g u i 状态的变化反映出来。 从g u i 自身的角度来看，g u l 测试是一种典型的黑盒测试( b l a c k - b o xt e s t i n g ) 。 它关心的只是每一个事件执行之后g u i 系统所到达的状态，而不考虑状态改变实 现的具体细节。 从整个软件系统的角度来看，g u l 测试是对包含g u i 的软件系统进行测试的 重要手段。 第3 章数据驱动的g u i 自动化测试框架 3 1 概述 本章包台六部分，3 2 指出了进行基于框架的全面的测试所应注意的几个关键 原则；3 1 3 论述了数据驱动的自动化测试框架以及基于框架的测试技术在g u i 测试 领域的应用；3 4 介绍了测试用例的生成技术；3 5 介绍了测试用例的修复技术； 3 6 介绍了测试结果的自动化验证技术。 3 ，2 开发全面的测试策略应遵循的原则 为了尽可能充分地利用我们的测试策略，我们需要使它是可重用的和可管理 的。为了达到这个目标，我们在开发完整的测试策略的时候应该遵循下面几个关 键的指导性的原则： l 。测试自动化应该是一个需要长期的不懈努力的过程； 开发测试框架的过程跟一个软件开发项目的开发过程应该是一样的。 2 测试设计和测试框架是相互之间完全分离的两个实体； 测试设计侧重的是如何对被测应用的某个特殊功能进行测试。它所提供的 信息是做什么，如何做和什么时候做以及所用的输入数据和期待结果。所有 这些细节都是针对具体的被测应用的。它几乎不要求知道也不需要关心是否 进行自动或者手动测试，它所关心的核心问题是如何做。而测试自动化框架 是自动测试的执行环境。它是一个完整的系统，我们的测试就是在这个系统 中完成的。框架的开发要求的技术是跟测试设计开发完全不同的技术。 3 。测试框架应当是独立于被测应用的； 虽然被测应用是各式各样的，但是组成它们的部件却是有很多共性。例 如利用s u n 公司j a v a 平台开发的g u i 应用，其g u i 部分所用的是j a v as d k 中的s w i n g 部件库所提供的图形类；而利用m i c r o s o f t 公司的n e t 平台开发 的g u i 应用，其g u i 部分往往采用的是从工具箱中拖放( d r a ga n dd r o p ) 的 控件米组成的，这些控件按照分类继承自相同的父类，当然也就具备很多相同 或者相似的属性( p r o p e r t y ) ，成员变量( f i e l d ) 或者成员方法( m e t h o d ) 。 1 4 所以，我们应当使自动化测试框架去处理这些相同的部件例，从而可以使得 我们的测试框架支持各种不同的被测应用，使得我们的框架的各个组成部分 具有较好的可重用型。 4 测试框架应该是易于扩展和维护的； 我们的一个目标是使得我们的自动化测试框架具备高度的模块化和可维 护性。一般地，每个模块应该是独立于其它的模块的，一个模块无需关心其 它模块的处理情况。由于3 所提到的部件的共性，测试框架中的底层对于g u i 的基本操作应该是可以扩展的，即随着测试需要，增加对于某种图形对象的 测试功能。为了便于维护，应当尽量避免测试设计涉及到实际的底层细节， 高度的抽象可以很好地解决这个问题，但是需要框架设计者有很强的分析和 抽象能力。 5 测试设计和测试策略相关的词汇应当是独立于测试框架的； 完整的测试策略定义的是测试所有应用程序所需的格式和底层词汇，就如 同自动化测试工具定义的脚本语言的格式和语法一样。而对于某个具体的被 测应用进行的测试设计定义的是高层词汇，这些词汇是针对具体的被测应用 的。举一个简单的例子，要测试一个登录界面，高层的指令就是指定在对应 的文本框中依次输入用户名和密码，无论我们用什么工具去完成。 6 测试设计应当把大部分测试人员从测试的框架的复杂性中解脱出来； 实际当中，我们不可能指望所有的测试人员都变成使用自动化工具的专 家。而一般地，测试人员就是测试人员，不是程序员。有时候他们是应用领 域的专家对软件开发需要的技术没有任何掌握。目前软件企业的测试人员绝 大多数是从编码人员转过来的，即便直接成为测试人员也需要有比较扎实的 软件编码基础。然而有了像上面5 提到的合适的测试策略和词汇，我们没有 理由不相信，测试人员不必去掌握任何测试工具的部署和计划的技能而只要 利用所有的测试资源进行测试设计就可以了。测试人员的任务就只是专注于 测试设计，而对这些设计的自动化执行过程由测试框架去完成。 3 3 数据驱动的自动化测试框架 数据驱动测试框架，顾名思义，是以数据驱动整个测试过程的进行。测试输 入和输出都是从数据文件( 数据池，o d b c 源，c v s 文件，e x c e l 文件，d a o 对 象，a d o 对象，x m l 文档等) 中读取的，然后赋值给获取的或者手动编码的脚本 中的变量。测试脚本包含了每一个测试步骤、数据文件的读取以及测试状态的日 志和信息。 3 3 1 数据驱动脚本 数据驱动脚本是那些用工具捕获或者手工编码所形成的针对具体被测应用的 脚本f 2 8 1 。对于数据来讲，测试脚本只是一种传递机制( d e l i v e r