GUI自动化测试原理剖析

开发 测试 自动化
一般是指软件测试的自动化,软件测试就是在预设条件下运行系统或应用程序,评估运行结果,预先条件应包括正常条件和异常条件。本文主要介绍就是JAVA篇自动化测试,来看本文。

 

序言:接触过自动化测试工具的测试人员,例如,Rational fuction teste,QTP等,一定对“录制—回放”这种机制不陌生吧,但是又有多少人能够了解其内部大概的运行机制呢?更又有多少人能从代码级别及其框架去分析其运作原理呢?

我一直觉得,你不理解它,你就无法用好它,更别说去拓展它成一个框架或者平台了。

它,在录制时,是怎么获取对象的?可以不通过录制的方式获得对象吗?

它,在回放时,是采用调用什么方式进行回放的?可以通过API或者自己编写代码使其录制的脚本进行回放吗?

自己如何去编写一个简单的“录制—回放”工具呢?

那么,今天就大概根据自己的简单介绍一下这种机制,希望能够帮助大家一起真正走入一个自动化测试的“大门”。

一、工具如何实现录制和回放

首先大概介绍一下自动化测试工具实现录制和回放的两种方法,其重点是对象的识别。

1、静态映射:当录制时,通过ObjectMap,将需要识别的JAVA应用程序的组件对象映射进对象库,然后,回放时,RFT首先根据正在运行的JAVA程序到对象库去查找相应的对象,若匹配到对应属性阈值适合的对象,则调用其脚本中的方法对对象执行操作。

一般的工具在工具与AUT之间都有一个代理,这个代理就是包裹着实际要测试的界面的控件,而ObjectMap是脚本层面的东西,它们之间存在一个映射关系。RFT通过代理与AUT进行交互。

需要明白的是,由于swing组件的树形结构关系,因此,ObjectMap中的映射出来的对象也是采用这种形式,虽然RFT中可以通过自己设置识别阈值的方式,但是对界面更改的适应能力还是不高。

2、动态搜索:应用动态搜索就可以不需要采用录制的方式了,而且也不需要对象库的方式,它是直接通过调用工作库中的API来定制相应的组件属性进行查找即可;回放时,自动化测试工具会获取正在运行的JAVA程序的各个组件属性,然后进行属性匹配,若是能够匹配到相应符合的属性,则会进行脚本规定的方法操作;

所以,应用动态搜索的方式,虽然在识别效率上降低了,但是其识别能力大大提高,界面如何变化,只要属性值不变,就没有太大问题,这也是为什么需要开发在开发JAVA程序的时候,尽量在属性值里添加一个唯一的识别属性ID了,这样做的目的可以使自动化测试更好的开展,这也可以作为以后各位的一个DFT需求了。

二、录制和回放的原理

经过了第一环节的介绍,大家对自动化测试工作实现录制和回放的两种方式大概有所了解,但是深层次是怎么样的呢?

借用关于JAVA的事件生命周期的一幅图片来说明:

JAVA的事件生命周期

测试人员通过对界面的操作会生成一系列的事件,这些事件在工具的代码中会由事件生成后放在系统事件队列内部。现在事件处于事件分发线程的控制下。事件在队列中等待处理,然后事件从事件队列中选出,送到dispatchEvent()方法,dispatchEvent()方法调用processEvent()方法并将事件的一个引用传递给processEvent()方法。此刻,系统会查看是否有送出事件的位置,如果没有这种事件类型相应的已经注册的监听器,或者如果没有任何组件受到激活来接收事件类型,事件就被抛弃。

录制时,采用了监听器模式,和平常swing编程不同的是,这里的监听器不是针对某个组件的,而是针对某种事件的。也就是说,任何组件发出的同一类型的事件,比如鼠标或者键盘事件,都会被其相应的监听器捕获到,然后进行处理。然后将捕获到的JAVA事件,可以以某种格式保存在脚本文件中,这里就需要一个转换机制了。

回放时,则从脚本文件读取并还原事件,这里会用到java.awt.Robot类(JDK1.3之后引入的一个类,能模拟鼠标和键盘操作),这个类通常用来在自动化测试或程序演示中模拟系统事件,这个类主要的目的就是为方便的实现java的GUI自动化测试平台。在事件回放时,我们同样需要该类来模拟生成系统的事件,完成记录的操作的回放

三、Gui自动化测试的简单框架架构

GUI

1、类加载器或者应用程序加载器,则是去加载相应的应用程序或者主类,这样可以指定需要测试的应用程序。

2、事件监听器,则是对应用程序所产生的各种事件的一个监听机制,可以通过拓展不同的事件监听来获得不同的事件。

3、脚本解析器,包括脚本记录器与脚本读取器两个模块,一个可以从监听器中获得事件的有效信息并记录,可以指定记录到生成相应脚本。一个可以从本地脚本文件或文本域中读取脚本信息,并解释成相应事件。

4、Robot类再封装,即是一个模拟回放器,将从脚本解析器解析过来的代码通过调用Rboot类进行模拟鼠标和键盘的一系列操作。

一个GUI自动化测试框架的基本架构大概就是这样,如果有兴趣的朋友可以深入研究,因为商业化的自动化测试工作实现的架构比这个要复杂一些,但原理基本还是一样的。

WEB与WIN32等界面自动化测试的原理架构大致也是如此,不过实现方式还是很不一样的,关键是调用的库方式不一样,具体在以后可以一起讨论。

四、选择一种合适的自动化测试方案

所以根据以上架构和原理,在自动化测试项目开展过程中

1、有资源和人力的情况下,可以考虑自己去开发一个简单的自动化测试工具,这样的好处是灵活,能够很好的与自身的产品结合起来,缺点就是耗费资源太大,而且开发自动化测试工具不一定能好用。

2、可以结合相应的开源自动化测试工具(例如:测试swing的可以用abbot),这种方式优点就是免费而且实现也有一定的基础,缺点就是其功能不一定满足其需求。

3、采用商业性的自动化测试工作(例如:RFT),这种方式的优点是成熟度高,而且能很快的应用到项目中,但是注意的是需要自己去搭建一个框架,个人建议,应用RFT的话最好直接应用其API去拓展一个自己的库,通过自己的库去搭建一个适应自己需求的框架,这个在后期会介绍。

总之:各种方案的实行方式还是得具体根据项目的需求来,需求才是导向,而且个人根据经验:不要为了做自动化而自动化,不要去为了做自动化而迷恋入技术而不可自拔,一定要在适当的时候采用适当的方式,步步为进。真心希望大家都能做好自动化测试。

版权声明:本文出自 散步的SUN 的51Testing软件测试博客:http://www.51testing.com/?382641

【编辑推荐】

  1. 整体思考自动化测试发展和价值回报
  2. 谈自动化测试框架思想与构建
  3. 软件自动化测试在功能测试中的应用
  4. 自动化测试面面观
  5. 如何评估自动化测试工作量
责任编辑:于铁 来源: 51Testing软件测试博客
相关推荐

2012-03-29 10:57:12

Web自动化测试

2022-02-17 10:37:16

自动化开发团队预测

2021-09-03 09:56:18

鸿蒙HarmonyOS应用

2012-02-27 17:34:12

Facebook自动化

2014-04-16 14:15:01

QCon2014

2013-05-16 10:58:44

Android开发自动化测试

2011-12-23 17:09:57

自动化测试

2021-06-30 19:48:21

前端自动化测试Vue 应用

2012-12-24 22:54:31

2014-11-20 13:49:15

2023-03-27 15:37:43

自动化测试开发

2011-01-20 10:17:25

ibmdwWeb

2011-05-30 17:31:26

自动化测试

2022-06-08 14:22:55

自动化测试测试

2022-05-10 11:18:42

自动化测试软件测试

2009-08-19 09:00:48

单元测试框架自动化测试

2021-06-25 10:57:30

前端自动化测试开发

2021-06-26 07:40:21

前端自动化测试Jest

2022-02-16 09:01:13

iOSS开发XCode

2023-05-18 14:01:00

前端自动化测试
点赞
收藏

51CTO技术栈公众号