（系统分析与集成专业论文）gui自动化测试框架的实现与研究.pdf

摘要 随着软件工程体系的不断规范化和标准化，软件质量的要求也越来越高。图形用户 界面( 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 ) 被测程序覆盖率、发现缺陷时间分析； ( 2 ) 通过h o f f m a n 的投资回收分析公式对该框架进行了定性分析分析结果显示在使用 了g u i 测试自动化框架后不但节省了测试资源，而且对被测程序g u i 或流程的更改适应 性较好，使用测试框架能提高测试效率，增加测试案例的可维护性。 关键词：g u i ；自动化测试；框架；对象识别；数据驱动；关键词驱动 a b s t r a c t g r t t h t h en o r m a l i z a t i o na n ds t a n d a r d i z a t i o no f $ o t q w a l f ce n g i n e e r i n g , t h es t a n d a r do f s o f t w m eq u a l i t yi si n c r e a s i n g g u it e s t i n gi san e c c s s s i yp a r to fs o f t w a r et 咖垂u s i n g a u t o m a t i o nt o o l sf o rg u it e s t s 锄i n c r e a s et e s te f f i c i e n c y , r e d u c et h ec o s to far e g r e s s i o n t e s t so f ap r o d u c t , m a k et h et e s tc a s e sc o n s i s ta n dr e p e a t a b l e g u it e s ta u t o m a t i o nf r a m e w o r k c 锄e n c a p s u l a t ec o m m o nu t i l i t i e s c o m m o nf u n c t i o n sa n dt e s t c a s e 8 s ow h e na p p l i c a t i o n u n d e rt e s tc h a n g e si t sg u io rf u n c t i o n , g u it e s ta u t o m a t i o nf r a m e w o r k 啪m a k et h ec h a n g e o f t e s tc a s e sl e s sa n di m p r o v et h em a i n t a i n a b i l i t yo f g u it e s tc a s e s t h i sp a p e rf i r s t l yi l l u s t r a t e sb a c k g r o u n dk n o w l e d g eo fs o f t w a r et e s t i n ga n dp r o b l e m si n s o f i w m - et e s t i n ga n dg u it e s t i n g , t h e ni ti n t r o d u c e sb a s i cc o n c e p t sa n dm e t h o d s o f a u t o m a t i o n t e s ta n da u t o m a t i o nt e s tf r a m e w o r k ，g e n e r a l i z e st h ec o n c e p to fa u t o m a t i o nf r a m e w o r k , a n d c o m p a r e s2t y p i c a ls o f t w a r ea u t o m a t i o nf r a m e w o r k sa n dt h e i ra d v a n t a g e sa n dd i s a d v a n t a g e s a n dt h e nag u ia u t o m a t i o nf r a m e w o r kw a si n v o l v e d t h r o u g h2 锄p e c t s ，t h i sp a p e ra n a l y z e s t h ef r a m e w o r k ：( 1 ) ，t h ec o v e r a g eo f t h ef r a m e w o r k , t h ed e f e c tf o u n do f t i m e ( 2 ) r o if o r m u l a o fh o i f a n a nw a su s e dt oa n a l y z et h ea u t o m a t i o nf r a m e w o r k t h ea n a l y s e ss h o w st h a tt h eu s e o fa u t o m a t i o nf i - a m e w o r ks a v e sal o to fl a b o rt e s ta n dt h ef r a m e w o r k 锄m a k et h eg u it e s t c a s e se a s i e rt om a i n t a i n k e y w o r d s ：g u i ；a u t o m a t i o n ；f r a m e w o r k ；o b j e c tr e c o g n i t i o n ；d a t ad r i v e n ；k e y w o r dd r i v e n 湖北大学学位论文原创性声明和使用授权说明 原创性声明 本人郑重声明：所呈交的论文是本人在导师的指导下独立进行研 究所取得的研究成果。除了文中特别加以标注引用的内容外，本论文 不包含任何其他个人或集体已经发表或撰写的成果作品。对本文的研 究做出重要贡献的个人和集体，均已在文中以明确方式标明。本人完 全意识到本声明的法律后果由本人承担。 论文作者签名：在- 韦 日期：刎年6 月了日 学位论文使用授权说明 本学位论文作者完全了解学校有关保留、使用学位论文的规定，即： 按照学校要求提交学位论文的印刷本和电子版本：学校有权保存学位论文的印刷 本和电子版，并提供目录检索与阅览服务；学校可以允许采用影印、缩印、数字 化或其它复制手段保存学位论文；在不以赢利为目的的前提下，学校可以公开学 位论文的部分或全部内容。( 保密论文在解密后遵守此规定) 作者签名：伺讳 艚教师签名：留 日期：2 明6 名 6 g - 第一章绪论 1 1 软件测试的发展 第一章绪论 软件测试是当前工业界普遍采用的度量和提高软件质量的重要手段，是软件工程学 术界研究的主要内容之一。软件测试是成功实现软件产品的预先步骤，是软件开发的 重要环节和保证软件质量的关键过程。欧洲阿丽亚娜五型火箭升空不久后就爆炸，主 要是由软件错误引起的。另外，据统计，品质不高的软件系统给美国经济带来的损失 每年约几十亿到几百亿美元( “e c o n o m i cc o s t so ff a u l t ys o f t w a r ei nt h eu s r a n g ei n t h et e n so f b i l l i o n so fd o l l a r sp e ry e a r ) 1 1 。 1 9 7 9 年，g l e n f o r dm y e r s 作出了当时最好的软件测试定义【2 】：“测试是为了发现错 误而执行的一段程序或者系统的过程。”1 9 8 3 年，i e e e 提出了软件工程标准术语，其 中对软件测试的定义为。使用人工和自动手段或测试某个系统的过程，其目的在于检验 它是否满足规定的需求或是弄清预期结果与实际结果的差别”，这个定义明确提出软件 测试是以检验是否满足需求为目标【”。 从上个世纪9 0 年代开始，产业界意识到被动的以监测和发现错误为目的的软件测 试无法避免软件开发过程中由于软件需求和设计等方面带来的巨大风险，于是产业界开 始从软件质量控制( s q c ，s o f t w a r eq u a l i t yc o n t r 0 1 ) 转移到软件质量保i t 正( s q a ，s o f l w a x e q u a l i t ya s s u r 龇c e ) ，从而使软件测试从单纯的缺陷检查和发现覆盖到整个软件过程【4 】。 2 0 0 2 年，i u c k 和s t e f a n 中对软件测试作了进一步的定义。测试是为了度量和提高被 测软件质量，对测试件进行工程设计、实施和维护的整个生命周期过程。”按照软件测 试自动化技术m mr a t i o n a l 技术白皮书嘲，如图1 1 所示，一个典型的软件测试过程分为测 试需求分析，测试设计，测试开发，测试执行，缺陷和配置管理过程等多个不同的阶段。 湖北大学硕士学位论文 图1 1 软件测试的不同阶段 软件测试技术按照不同的划分方法和测试要求细化为不同的类别： ( 1 ) 按照测试的阶段：分为需求测试、单元测试、集成测试、系统测试和验收测试； ( 2 ) 按测试用例设计方法：分为白盒测试和黑盒测试； ( 3 ) 按测试过程和测试手段：分为手工测试和自动化测试； ( 4 ) 按测试时是否执行测试代码：分为静态测试和动态测试等。 测试专家总结了很多的测试模型，比如v 模型、w 模型、r u p 模型等；在测试的过 程改进方面提出了t m m ( t e s t a b i l i t ym a t u r i t ym o d e l ) l ；l 】，t i m ( t e s ti m p r o v e m e n tm o d e l ) 嗍， t p l ( t e s tp r o c e s si m p r o v e m e n t ) 9 】等模型概念；在单元测试、自动化测试、负载压力测试 以及测试管理方面涌现了大量的软件测试工具，如i b m 的r a t i o n a l 系列套州1 0 l 、m e r c u r y i n t e r a c t i v e 系列套件川等。这些工具以及经典理论对软件测试的理论化和体系化产生了 巨大的影响。 1 2 软件测试中的问题 测试是软件的软件开发的重要环节。一方面是要求通过测试活动验证的软件在功 能上满足软件需求中描述的特性，性能上满足客户要求的负载压力和时问和吞吐量的要 求；另方面，还要在有限的时间预算内尽快向市场和客户发布产品。 传统的软件测试流程一般是先在软件开发过程中进行少量的单元测试，然后在整个 软件开发结束阶段，集中进行大量的测试，包括功能和性能的集成测试和系统测试。随 着开发的软件项目越来越复杂，传统的软件测试流程不可避免地给测试工作带来以下问题： 问题一：项目进度难于控制，项目管理难度加大，造成大量的软件错误往往只有到 了项目后期系统测试时才能够被发现，解决问题所花的时间无法预料，经常导致项目进 2 第一章绪论 度无法控制，同时在整个软件开发过程中，项目管理人员缺乏对软件质量状况的了解和 控制，加大了项目管理难度 问题二：对于项目风险的控制能力较弱，项目风险在项目开发较晚的时候才能够真 正降低。往往是经过系统测试之后，才真正确定该设计是否能够满足系统功能、性能和 可靠性方面的需求。 问题三：软件项目开发费用超出预算，在整个软件开发周期中，错误发现的越晚， 单位错误修复成本越高，错误的延迟解决必然导致整个项目成本的急剧增加。据产业界 的大量研究表明，设计活动引入的错误占软件过程中出现所有错误数量的5 0 6 0 0 2 。 统计表明：软件测试与维护的费用要占到整个软件开发费用的5 0 以上，图1 - 2 给 出了估计修复软件缺陷费用的行业标准【1 3 1 ，表明缺陷发现的越晚，费用将很快增长。 图1 - 2 修复软件缺陷费用的行业标准 1 3 本文研究内容及组织结构 本文研究的内容是：如何设计g u i 自动化测试框架，使得测试更加有效，自动化测 试框架更易于维护；在被测程序发生改变的时候，如何将测试脚本的维护量降到最少， 而将尽可能多的维护工作通过修改测试数据或测试框架来实现。 本文的组织结构如下：第一章介绍了软件测试的发展以及软件测试中遇到的问题。 第二章阐述了自动化测试的相关概念，指明了其优点和局限性，对g u i 自动化软件测试 中的问题，自动化工具，自动化组织和自动化级别进行了概括。第三章讨论了自动化测 试框架，并对两种经典的自动化测试框架进行了总结和比较，并在此基础上，给出了一 个实际应用中的g u i 测试框架。第四章详细分析这个g u i 框架在实际中应用的情况， 3 湖北大学硕士学位论文 然后从两方面对该g u i 自动化测试框架进行了分析：( 1 ) 被测程序覆盖率、发现缺陷时 问分析；( 2 ) 通过h o f f m a n 的投资回收分析公式对该框架进行了定性分析；分析结果显示 测试框架不但节省了测试资源，而且对g u i 或被测程序流程的更改适应性较好 4 第二章自动化测试相关理论 第二章自动化测试相关理论 2 1 自动化测试的概念 测试自动化是使用软件工具来测试并验证被测软件反应和行为的测试活动。自动化 测试一般采用商业测试软件工具或自己编写的软件工具来实现自动化测试。 采用自动化工具的目的就是在产品开发后而在发布前的有限时问内对产品进行尽 可能的自动化测试，从而发现尽可能多的缺陷。自己编写测试工具的测试人员需要对一 种开发语言熟练掌握，而使用商用测试软件的测试人员则需要熟悉某种测试工具软件厂 商的脚本语言。 成熟的测试自动化机制，是在机器空闲时候由自动化测试工具执行无用户参与的自 动测试。自动测试是可重复的测试，在相同的测试案例中使用完全相同的测试数据进行 再测试。自动测试以较小的代价进行比较全面的系统测试。 根据测试的功能的复杂程度，测试脚本有的是需要其他语言进行解析的，有的是批 处理甚至类似于t c l 语言的强大的脚本语言程序片断。当前主要使用的测试脚本主要 由三种方式产生【1 4 1 。 ( 1 ) 人工编辑测试脚本，采用特定的编程语言，编写一系列在特定环境和平台上运行 的代码，运行这些代码来进行测试。 ( 2 ) 采用测试工具利用“面向对象的软件逆工程”方法来产生自动测试脚本，主要用 于单元测试中。对于采用o o 方式设计的目标应用程序，单元就是程序中的各个类，针 对这些类的单元测试采用“面向对象的软件逆工程”方法，在提供的被测单元的源代码 中人工选择需要测试的方法，产生多个测试脚本。 ( 3 ) 采用“录制回放”技术，多用于g u i 测试。由测试人员手动对目标进行一次用 例测试，由测试工具记录下手工操作的步骤和对象，作为测试脚本运用到以后的多次机 械重复测试中去，以提高效率，减少重复劳动。 j 5 湖北大学硕士学位论文 2 2 自动化软件测试中的问题 2 2 1 自动化软件测试中的优点和局限性 自动化测试在下列方面具有优势： ( 1 ) 自动化测试更快：对程序的新版本运行之前版本已有的测试，即回归测试时，自 动化测试比手工测试更快。另外，自动化测试避免了手工测试时测试人员延时或者是分 心。经验表示自动化执行相同的测试测试场景的时间比手工测试该场景快2 5 到5 0 。 ( 2 ) 自动化测试能不问断进行：自动化能按照每天2 4 小时和每周七日的时间来执行。 使用手动测试，测试人员得全程点击按钮等操作。而采用自动化测试后，测试人员需要 做的就是启动测试和评价测试结果。这意味着测试组织按照每人工作8 小时每天的进度 一下子提高到由自动化工具来执行每天2 4 小时的测试，从而将测试周期缩短了6 7 。 考虑到周末和节假日，则效果更加突出。假设一个手工测试人员工作2 0 0 0 个小时每年， 测试由测试采用2 4 7 的自动化测试，则测试周期能压缩7 5 。 ( 3 ) 自动化具有一致性和可重复性：对于自动重复多次相同的测试能重复多次相同的 测试，这样就能获得测试的一致性。 ( 4 ) 自动化的投入成本是：购买测试工具的成本、先期构建自动化测试的成本和运行 中维护和修正自动化测试成本三者之和。 先期购买产品的价格通常是固定的，也就是说产品的代价是静止不变的，价格不随 着使用而上下波动。对测试人员的代价，如写测试脚本或培训是可变的花费，也就是说 人工的代价随着分配在自动化上的时间在上下波动。一旦测试团队变得对购买的产品熟 悉了，将会花费更少的时间来写测试脚本，从而降低自动化的总体花费。 自动化是一项投资，最初的投资可能很多，但投资的回报也很丰厚。自动化运行1 5 次后，测试就是免费的了l ”】。 另一方面，自动化测试是有局限性的。 没有经过良好设计的自动化测试机制将会耗费掉高昂的先期构建成本并带来无休 无止的维护工作，而设计合理的测试机制能够大大降低测试执行的成本，并提高测试效 率。若在自动化前的手工测试没有按照详尽的测试需求文档或规范来运作，则自动化后 运行的测试也不会提高测试的效果，反而会占用有限的测试资源，甚至误导测试的效果。 一般来说，步骤越具体的手工测试越容易被自动化。步骤越模糊的手工测试越容易造成 6 第二章自动化测试相关理论 二义性的问题。测试工具不会处理异常事件，一些需要人工测试的测试点无法由自动化 来完成，自动化测试无法取代手工测试。 进行自动化测试有如下准则6 1 ： ( 1 ) 如果被测程序不复杂且不太大，不要自动化。 ( 2 ) 如果只接受几个( 3 个或更少) 构建版本，不要自动化。 ( 3 ) 如果一个特征不是1 0 0 有效，不要进行自动化。 ( 4 ) 如果开发周期的时间表很紧，每次交付的时间很短，就没时问自动化。 ( 5 ) 如果一个特征不能通过自动化测试达到1 0 0 准确测试，就不要进行自动化了。 2 2 2g u i 自动化软件测试中的问题 2 2 2 1g u i 测试定义以及分类 g u l ( 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 i 组件通常指窗口、菜单、按钮等。用户通过拖动鼠标，点击按钮等来驱动软件完成 需要的功能。g u i 输入主要是由一系列事件或行动组成，输入和状态转移不仅与当前输 入事件相关，还与以前的输入事件相关。g u i 往往允许多个窗口被激活，彼此之间存在 一些同步机制。这些特点使得g u i 测试非常困难，向测试研究者与实际测试人员提出了 许多新的问题。比如，如何描述g u i 测试需求，如何定义g u i 测试充分性，如何生成g u i 测试用例等等。 蔡开元采用如下的方法来定义g u i 测试用例0 7 1 ：将g u i 测试用例库定义为一个由 有限符号集生成的形式语言，引入形式语言的维数，发现任一有限形式语言具有唯一的 维数和相应的递阶划分，从而对形式语言的每个字或g u i 测试用例库中的每个测试用例 引入阶这个概念，阶的取值唯一确定。一个测试用例应该实现g u i 的某种特定功能，不 应该是离散事件的随机组合。 g u i 程序的图形界面和功能代码是相互独立的，相同的代码可能会对应不同的界 面；不同版本的g u i 可能只对界面部分作了调整，而功能代码部分却没有改变；功能代 码所对应的消息或方法是对应它所关联的事件的，而程序代码的检查却没有对事件交互 进行检测。 针对g u i 程序的测试过程是执行用户操作步骤、获取检测状态和对比验证内容，由 于用户操作的随意性，可能会出现无限种事件交互方式，所以必须考虑各种复杂事件的 7 湖北大学硕士学位论文 情况，以及各种验证状态和内容。为提高效率，必须避免极耗资源的手工测试，而采用 自动化测试。 对基于窗口的应用程序进行测试，都应该考虑到程序内g u i 的一致性，以及不同应 用程序间相似的标准外观，还应具备标准的键集来执行程序。g u i 应用程序的测试分为 以下四类【1 町： ( 1 ) 标准化测试：主要集中在应用程序中标准化的部分，应该具备和其他应用程序一 样的标准外观。如窗口是否具备符合自身内容的标题等 ( 2 ) 属性测试：主要集中在一些窗口组件的属性上，如是否每个窗口的确认和取消键 能正常工作。 ( 3 ) 确认测试：主要集中在应用程序中需要确认的部分，如对空密码和错误密码弹出 警告等。 ( 4 ) 业务规则测试：主要集中在应用程序中需要验证的功能部分，测试的内容是随软 件而变化的，一般针对软件功能说明书的功能测试和软件需求说明中的需求测试。 2 2 2 2g u i 组件识别问题 g u i 组件的识别功能是测试工具提供的功能。自动化测试人员希望建立平台无关 的、g u i 组件易于识别的、测试脚本自动化的且易于管理的测试。g u i 界面是各种各样 的，有传统的c s 模式的，也有基于网页模式的，有标准组件，还有许多无法被测试工 具识别的第三方组件。通常测试工具通过对界面上的控件进行识别，标记出各个组件的 识别码，记录在各自对应的脚本中，然后在回放中通过这些基本的识别码来定位控件而 实现基本的操作。 g u i 组件可以通过名字、在层次中的位置、组件类、父窗体的标题、程序员赋给的 标签或者d 等特性来被测试工具记录和处理。在每次对话或者运行的程序中，g u i 组 件的位置都是由屏幕上的唯一的属性确定的。由于g u i 组件的部分特征随着程序版本， 平台和屏幕的分辨率而改变，测试脚本中应该避免硬编码。 例如r o b o t 将窗口中的某个组件的l a b e l ，i d ，o b j e c t - - i n d e x 等属性都识别出来， 但是在记录的脚本中只记录主要属性。这个能通过r o b o t 的设置来改变。 8 第二章自动化测试相关理论 比如对一个1 曲对象的识别： t a b c o n t r o l - m e t h o d s o b j e c t n a m e二 t e x t d i n d e x 在r o b o t 工具中默认对一个t a b 对象的识别就是按照上面的顺序从上向下的顺序识 别的。这样在记录的脚本中就会优先记录上面的属性。 2 2 2 3g u i 组件更改频率 g u i 组件会随着功能需求而被改变。g u l 组件更改的频率直接影响到了g u i 测试 框架的更改频率。在产品型软件中，某个版本的软件对界面进行了大量的改变，g u i 自 动化测试的所受的影响就会很大：之前能运行的g u i 测试用例现在都需要经过修改才能 运行。如果采用合理的测试框架就会降低需要更改的文件的数量，设计优良的自动化测 试框架应该将尽可能多的维护工作从测试案例中转移到测试数据或自动化测试框架上 频繁的g u i 组件的更改会对自动化测试产生影响。有两种选择可以减少影响：! ( 1 ) 自动化测试功能成熟且界面为稳定的程序或模块，这样g u l 改变就不会很大 ( 2 ) 在设计时需要将和g u i 相关的操作单独隔离到测试框架的某层，这样就会使得 g u i 改变时测试的维护量最小。在设计良好的测试框架中，g u i 组件更改频率的大小不 会对测试案例产生较大的影响。 2 3 自动化测试的工具 自动化的工具一般有使用自己开发的工具和商业测试工具两种。 由于商用测试工具价格不菲，商用测试工具复杂软件项目的处理能力不够，对许多 第三方的组件识别支持不够，部分测试人员选择开源测试框架或工具甚至自己编写测试 需要的工具。但这对测试人员的编程能力要求较高。 软件测试自动化大多数情况下是借助商用测试工具进行。测试工具能进行部分的测 试设计、实现、执行和比较的工作。通过运用测试工具，能达到提高测试效率的目的。 通常是先进行人工设计测试用例，然后使用工具进行用例的执行和比较，必要的时候还 需要根据测试的要求对测试工具的脚本修改。 9 湖北大学硕士学位论文 比较成功的商用测试软件主要有i b m 的r a t i o n a l 测试套件和m i 的测试套件。 m mr a t i o n a l 的软件自动化测试解决方案追求测试工具和测试成功经验、测试过程 的统一，其最大的特点就是通过一套完整的软件测试工具在实现测试管理流程的基础 上，同时覆盖功能测试、性能测试和可靠性测试的自动化测试需求，通过工具间的集成 完成测试资源的整合在i b mr a t i o n a ls o l u t i o n s 中主要的测试工具有【1 0 】： ( 1 ) 测试管理平台r a t i o n a lt e s t m a n a g e r r a t i o n a lt e s t m a n a g e r 是在r u p 测试方法论的基础上定义的一套测试自动化测试管 理平台。它支持5 个主要的测试活动：测试的计划、设计、实施、执行及评估。通过和 c a e a r q u c s t 的完美结合，实现对整个项目测试生命周期的管理，帮助项目组成员快速建 立完善的软件测试及测试管理平台。 ( 2 ) 缺陷管理平台r a t i o n a lc l e a r q u e s t 一种对缺陷和记录的变化进行跟踪管理的工具。它体现了一个b u g 的完整的生命 周期，从提交到关闭，记录了b u g 所有的改变历史，同时它提供了各种查询功能，及 时反映了b u g 的处理情况。它实现了测试人员和开发人员交流的平台，还可帮助团队 测试分析人员量化的对测试进度和工作量进行量化分析。 ( 3 ) 自动化测试工具r a t i o n a lr o b o t r a t i o n a lr o b o t 是一个用于代替人工，进行高速自动测试的工具，它主要围绕 w i n d o w s 图形界面、字符终端和b r o w s e r 界面进行功能测试。客户端可以是v c 、v b 、 p b 、d e l p h i 等编制的软件、各种字符终端或者运行i e 浏览器，通过自动录制形成测试 脚本，然后进行回放操作，能实现自动化的功能回归测试。 除了以上的产品外，还有针对j a v a 、w e b 和基于v s n e t w i n f o r m 的应用程序进 行高级自动化功能测试的r a t i o n a lf u n c t i o n a lt a s t e r , 针对使用新测试设计技术来改进人 t a g 试设计和执行工作的r a t i o n a lm a n u a lt a s t e r ，检查可变多用户负载下可接受的应用 程序响应时问和可伸缩性的r a t i o n a lp e r f o r m a n c et a s t e r ，内存泄漏和内存损坏检测的 r a t i o n a lp u r i f y 等等。 m e r c u r yi n t e r a c t i v e 公司的测试套间也是应用较为广泛的】。 ( 1 ) 自动化测试工具w m r u n n e r w i n r u n n e r 是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的 功能及正常运行。通过自动录制、检测和回放用户的应用操作，w i n r o n n e r 能够有效地 1 0 第二章自动化测试相关理论 帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和 质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。 w m r u n n e r 将w i n d o w s 应用程序中的按钮、窗口、菜单等元素通称为g u i 对象 在软件操作中点击g u i 对象时，w i n r u n n e r 通过识别这些g u i 对象的属性，如c l a s s ，l a b e l ， w i d t h 等特征来识别g u i 对象，同时将测试动作也记录下来，以一种类似于c 语言的测 试脚本语言t s l ( t e s ts c r i p tl a n g u a g e ) 产生测试脚本。 ( 2 ) 性能测试工具l o a d r u n n e r l o a d r u n n c r 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实 施并发负载及实时性能监测的方式来确认和查找问题，l o a d r u n n c r 能够对整个企业架构 进行测试。通过使用l o a d r u n n e r ，企业能最大限度地缩短测试时间，优化性能和加速应 用系统的发稚周期。 2 4 自动化测试的人员组织 测试工具虽然能快速定位各版本的功能和性能缺陷，但不会创造性的发现测试脚本 里面有无设计的缺陷。测试脚本也不可能对各种分支路径进行验证，即便出错，测试工 具也不可能发觉。对测试小组进行测试流程、缺陷管理、人员安捧、测试工具使用也需 要投入。由开发产品公司实施自动化测试要比开发项目的公司要优越些，因为产品开发 周期长。需求相对稳定，测试人员能有比较充裕的时间去设计测试方案和开发测试脚本； 而项目需求难以一次统一，变更频繁，给测试带来不利影响【1 9 】。 从测试人员个人素质和脚色分配来说，需要一个具有良好自动化测试背景和丰富自 动化测试经验的测试主管，在技术和测试管理位置上起着领导的作用，还需要有开发经 验良好的测试人员或开发工程师，负责编写测试脚本、开发测试框架；开发工程师不必 对产品业务了解深刻，但要具有将软件业务逻辑转化为可测试逻辑的分析能力，属于自 动化测试者。还需要有测试执行者，测试执行者对产品业务逻辑熟悉，配合测试设计者 完成测试自动化工作 然而l e o n a r dd i m a g g i o 结合测试经验提出了滥用测试框架的带来的结果 2 0 1 ：自动 化测试者把精力倾注在测试框架上，而不是测试本身；基础结构的维护费用不断增长； 测试框架变得如此繁重以至于测试人员避免使用它，所以他对自动化测试人员组织提出 了几条建议： 测试工程师创建的测试框架是用来完成测试产品的。 湖北大学硕士学位论文 维护测试框架是需要成本的 应该使得框架创建者，维护者和框架使用者相互协调，为一个整体。至少一些使 用者参与框架的设计和维护，至少一些框架设计者也参与测试框架的使用。 2 5 测试自动化的级别 可以将测试自动化划分为有5 种级别，如表3 1 所示 表3 - 1 软件测试自动化分级比较1 1 9 1 级别说明 优点缺点 用法 自动化测试脚拥有大量测试当测试的系统 本能够自动的脚本，当需求不会发生变化 一级录制与回放 生成，不需要和应用变化时时，实现小规模 任何编程知识必须重新录制的自动化 录制、编辑和 减少脚本的数需要一定的编回归测试时，用 二级量和维护的工程知识；频繁于被测试的应 回放 作变化难于维护用有小变化 确定了测试脚要求测试人员大规模的测试 本的设计，在具有很好的软套自j 被丌发、执 三级编辑和回放项目早期就可件设计开发技行和维护专业 以丌始自动化能自动化测试 的测试 能够维护和使软件开发技能大规模的测试 用良好且有效是基础，并需套间被丌发、执 四级数据驱动的测的模拟真实生要访问相关的行和维护专业 试活中的测试数测试数据 自动化测试 据 测试用例的设需要具有工具专业的测试自 使用动作词的计被从测试工技能和开发技动化将技能的 五级 测试自动化具中分离了能的测试团队使用最优化的 结合起来 ( 1 ) 录制与回放 对于只运行一次的自动化测试，简单的录制与回放就能满足需要。记录工具记录用 户和应用程序交互时的击键和鼠标的移动，然后记录成为个脚本。但是通过录制生成 的脚本，包括所有的浏览逻辑、w i n d o w s 处理逻辑、验证逻辑和测试数据是以硬编码的 方式编写的。当回放测试脚本时，任何微小的变动时会造成与应用相关的硬编码就改变 了。这样原先录制的脚本就无法顺利运行。想要维护这些直接录制的脚本是不可能的。 在运行时，如果测试脚本由于产品缺陷的原因无法继续，则只有到缺陷修正了，这 些脚本才能运行，造成测试效率低下【引l 。这些直接录制的脚本不可靠，没有基本的异常 第二章自动化测试相关理论 处理，会随着意外发生而无法执行，所以需要重新录制。录制与回放的脚本和测试数据 耦合太紧密，每修改一次测试数据就需要重新录制。仅仅依靠录制回放来完成自动化测 试远远不够，在实际中对需要多次运行的脚本不能靠录制与回放方法获得。这是自动化 测试的最低级别，只用于待测系统不会发生变化时候的小规模自动化。 ( 2 ) 录制、编辑和回放 对录制的脚本中加入逻辑结构从而改造脚本得到修订版本，以处理大部分可能遇到 的情况。录制、编辑和回放这种结构化的脚本包含控制结构和调用结构。控制结构包括 顺序、循环和分支，用来控制脚本执行；调用结构是在一个脚本中调用另外脚本。结构 化脚本的健壮性得到增强，也能通过循环和调用较少工作量，缺点是脚本变得更复杂， 和测试数据的耦合还是太强i 笠洲。在这个级别中，使用自动化的测试工具来捕获所需的 功能。将测试脚本中的测试数据等，从测试代码中剔除，转化为变量。这样做优点是测 试脚本开始变得完善和灵活，能减少部分脚本的数量和维护的工作然而，需要测试人 员有基础的编程知识 ( 3 ) 编辑和回放 使用大规模测试套件，确定了测试脚本的设计，在项目早期就开始自动化的测试。 在某个功能被一段测试脚本实现以后，其他的测试脚本能直接通过调用这个脚本来实现 功能。编辑和回放的脚本同样也具有控制逻辑和调用结构，节省了脚本开发成本，脚本 的易读性更好。一般采用界面共享。即在一个窗口中调用另一个窗口的脚本。但是测试 数据还是记录在测试脚本中。这个级别是面向多个构建版本的有效使用自动化的第一个 级别。需要在实际的投资开始显现之前确保团队和客户对项目的安全感。测试团队对测 试工具中的所有测试功能都必须被很好的理解，并要掌握测试脚本语言的知识。 在确定了测试脚本的设计，指定合适的编码规范是必要的。这将统一测试团队的编 码风格。编辑和回放测试框架对测试人员的软件设计技能，包括设计和开发技能的要求 比较高。 ( 4 ) 数据驱动的测试 数据驱动的测试是一个专业的自动化测试测试级别。拥有这个测试框架之后，能根 据被测系统的变化快速创建一个测试脚本的测试功能库，维护的成本相对是比较低的， 在测试中会用到大量的真实数据。数据驱动的测试的好处是能够维护和使用良好的并且 有效的模拟真实生活中数据的测试数据数据驱动的测试框架对软件开发的基础也比较 高，而且需要访问相关的测试数据。 1 3 湖北大学硕士学位论文 数据驱动的测试框架要求一些效率比较高的测试数据。测试人员必须花费时间来识 别需要采集何种数据和如何采集。使用现实中的数据是最基本的，能在测试中得到较好 的回报。在测试项目使用适当的数据将提供仅仅在项目的后期才会发现的或者是只有客 户才能发现的错误。数据驱动的澳j 试对产品流程的改变敏感。当程序运行流程改变的时 候，需要对测试的核, t s 弓l 擎和大量驱动表进行修改。 ( 5 ) 使用动作词的测试自动化 这是测试自动化的最高级别。主要的思想是将测试用例从测试工具中分离出来。这 个级别要求具有高技能测试人员的团队：能够将测试工具非常深层次的知识和具备的较 深的编程能力结合起来。该团队负责在测试工具中生成并维护测试的功能性，能够使测 试工具从外部的数据，比如e x c e l 表或者数据库中读取数据来驱动执行测试用例。 和一般的数据驱动相比，使用动作词的测试自动化将动作也作为数据放入驱动表而 不是仅仅放入测试数据。 衡量自动化脚本的指标有： 脚本数量：采用编辑或回放测试框架的自动化测试有大量的脚本需要维护。每测试 一个功能都需要一个独立的脚本。而采用数据驱动测试框架的核心脚本就只有一个循 环，在脚本中由数据或者动作词来决定测试的停止或者运行，因而脚本数量比较少 脚本大小：对采用录制回放的脚本和录制编辑回放的脚本要长于编辑回放的脚本， 因为录制回放的脚本和录制编辑回放的脚本直接使用了基于g u i 的硬编码。一般编辑回 放的脚本长度是可控的，否则就失去了可维护性。适当将很长的测试内容拆分为多个测 试脚本能提高单个脚本成功的概率。 功能：测试脚本是用来测试被测程序在指定操作和指定的输入数据下会按照预期出 错或成功的。对于g u i 的测试脚本，就是指在g u i 界面上用测试工具来模拟鼠标或键 盘对g u i 上的元素操作，然后按照预期的结果来判断被测程序是否正常工作。对预期的 结果的判断可以是g u i 上的出现提示，也可以是数据库里面增删记录，还可以是文件夹 里面生成新文件等等。按照测试的要求，脚本应该在测试框架的支持下提供对被测程序 基本功能的验证。 文档：测试的文档应该尽可能详细，这对测试自动化也是有帮助的。至少让测试脚 本编写者知道如何导航产品和如何验证产品的功能。对文档不全的自动化测试组织，测 试脚本编写者会遗漏测试点甚至对产品使用误解，从而造成测试脚本质量的低下。 易读性：是指在测试组中大部分测试人员对脚本是否容易理解的程度。在直接录制 1 4 第二章自动化测试相关理论 或录制编辑的脚本中，都含有硬编码。测试人员需要结合测试程序的图形界面来对照理 解，脚本的可读性差。在编辑回放的脚本中，测试人员按照最容易理解的命名方式来编 写脚本，因而易读性最好。而在数据驱动和关键词驱动中，测试执行人员只需要编写测 j 试数据表，没有必要去直接读测试脚本。 复用性：在录制与回放这个级别的测试中，脚本的复用是不可能的。在编辑、录制 回放和编辑和回放这两个级别的测试中，脚本的复用成为可能。复用脚本能减少实际测 试脚本的总长度。 结构化：在测试的后4 个级别中，测试脚本都是按照特定的框架来组织的。一般来 说，都是将g u i 元素单独封装一层，然后在测试案例中来调用这层，从而将g u i 的变 化和具体的测试脚本相隔离，避免g u i 的变化造成具体测试脚本的频繁变化。 可维护性：采用录制回放的脚本不可维护，录制回放的脚本中包含所有的浏览逻辑、 w m d o w s 处理逻辑、验证逻辑和测试数据，当应用程序g u i 变动时或者其他逻辑变动 的时候，与应用相关的硬编码就改变了，原先录制的脚本就无法顺利运行，想要维护这 些直接录制的脚本是不可能的。而后面的几种脚本技术是可以维护的。对于采用编辑录 制和回放的脚本，维护仅仅限于在g u i 改变较小的情况。对编辑回放的脚本，由于单独 隔离了g u i 层，只需要修改测试框架中g u i 元素有关的部分就可以保证大部分实际测 试脚本不受影响。而对于数据驱动和使用动作词的测试自动化，当被测程序的实际流程 发生变化时，需要修改核心引擎和g u i 相关文件。 i 异常处理：采用直接录制和回放的测试脚本，没有异常处理，在测试案例执行中的 一点微小改变都会导致脚本运行失败。而后面几种脚本技术都提供了基本的异常处理， 能处理测试人员可预计到的部分错误。 日志记录：在自动化测试运行完毕，需要提供日志文件来帮助测试人员了解测试执 行情况。测试自动化工具都提供了日志记录功能。 脚本与数据关系：在录制回放、录制编辑回放和编辑回放这三种脚本技术中，数据 和脚本的耦合性较强。在数据驱动脚本技术中，数据和测试数据的关系是：数据被包含 在输入测试数据文件中，并且数据控制自动化测试脚本的历程和动作。而使用动作词的 测试自动化就是将动作词也作为一种数据放在测试数据文件中 对测试人员的要求：对录制回放的脚本技术，不需要任何编程，只需要按照要求操 作软件即可。对录制编辑和回放，只需要简单的编程技术，对录制的脚本进行结构化处 理，编写部分异常处理和变量替换测试数据即可。对编辑回放技术，需要设计良好的测 1 5 湖北大学硕士学位论文 试框架，这个级别是面向多个构建版本的有效使用自动化的第一个级别。对于数据驱动 和关键词驱动需要开发技术的能力又有提高。同时所有这些脚本技术都需要测试自动化 人员了解产品的操作和数据的流程。 1 6 第三章软件自动化测试框架 第三章软件自动化测试框架 3 1 自动化测试框架技术 测试框架就是将测试脚本以及通用测试函数等按照某种逻辑分为若干层次和部分 以便更灵活高效地控制测试的一种组织结构。 k i t 定义了自动化软件测试的三个发展阶段圆： 第一个阶段是基本的g u i 测试。使用捕获，回放工具开发自动化测试脚本的用法局 限在记录在g u i 级别上的用户操作、编辑得到的测试脚本以及重放编辑过的测试脚本。 得到的测试脚本上非结构化的、无存档的，而且是不可维护的。 在第二个阶段中，脚本测试者发展了“建立结构良好、有存档的、健壮的、可维护 测试”的能力在这个级别上，测试项目成了工作项目；测试脚本包括错误捕获和恢复 逻辑，其关键特征是测试项目组件的可重用性 k i t 所说的测试自动化的第三个阶段是控制了测试资源。在这个级别上，测试设计 和测试自动化被看成是互相分开的行为。 数据驱动测试框架是k i t 所说的第三个阶段中的自动化测试级别中的一种框架。 数据驱动测试的定义是：数据驱动测试就是一种数据被包含在输入测试数据文件 中，并且数据控制自动化测试脚本的历程和动作的测试。 输入测试数据记录是从外部文件或电子数据表读入的而且是独立于测试脚本程序 开发的。数据驱动测试使用存档的测试数据来驱动自动化测试过程，它可以被扩