序言：接触过自动化测试工具的测试人员，例如，Rational fuction teste，QTP等，一定对“录制—回放”这种机制不陌生吧，但是又有多少人能够了解其内部大概的运行机制呢？更又有多少人能从代码级别及其框架去分析其运作原理呢？
我一直觉得，你不理解它，你就无法用好它，更别说去拓展它成一个框架或者平台了。
它，在录制时，是怎么获取对象的？可以不通过录制的方式获得对象吗？
它，在回放时，是采用调用什么方式进行回放的？可以通过API或者自己编写代码使其录制的脚本进行回放吗？
自己如何去编写一个简单的“录制—回放”工具呢？
那么，今天就大概根据自己的简单介绍一下这种机制，希望能够帮助大家一起真正走入一个自动化测试的“大门”。
一、工具如何实现录制和回放
首先大概介绍一下自动化测试工具实现录制和回放的两种方法，其重点是对象的识别。
1、静态映射：当录制时，通过ObjectMap，将需要识别的JAVA应用程序的组件对象映射进对象库，然后，回放时，RFT首先根据正在运行的JAVA程序到对象库去查找相应的对象，若匹配到对应属性阈值适合的对象，则调用其脚本中的方法对对象执行操作。
一般的工具在工具与AUT之间都有一个代理，这个代理就是包裹着实际要测试的界面的控件，而ObjectMap是脚本层面的东西，它们之间存在一个映射关系。RFT通过代理与AUT进行交互。
需要明白的是，由于swing组件的树形结构关系，因此，ObjectMap中的映射出来的对象也是采用这种形式，虽然RFT中可以通过自己设置识别阈值的方式，但是对界面更改的适应能力还是不高。
2、动态搜索：应用动态搜索就可以不需要采用录制的方式了，而且也不需要对象库的方式，它是直接通过调用工作库中的API来定制相应的组件属性进行查找即可；回放时，自动化测试工具会获取正在运行的JAVA程序的各个组件属性，然后进行属性匹配，若是能够匹配到相应符合的属性，则会进行脚本规定的方法操作；
所以，应用动态搜索的方式，虽然在识别效率上降低了，但是其识别能力大大提高，界面如何变化，只要属性值不变，就没有太大问题，这也是为什么需要开发在开发JAVA程序的时候，尽量在属性值里添加一个唯一的识别属性ID了，这样做的目的可以使自动化测试更好的开展，这也可以作为以后各位的一个DFT需求了。
二、录制和回放的原理
经过了第一环节的介绍，大家对自动化测试工作实现录制和回放的两种方式大概有所了解，但是深层次是怎么样的呢？
借用关于JAVA的事件生命周期的一幅图片来说明：
测试人员通过对界面的操作会生成一系列的事件，这些事件在工具的代码中会由事件生成后放在系统事件队列内部。现在事件处于事件分发线程的控制下。事件在队列中等待处理，然后事件从事件队列中选出，送到dispatchEvent()方法，dispatchEvent()方法调用processEvent()方法并将事件的一个引用传递给processEvent()方法。此刻，系统会查看是否有送出事件的位置，如果没有这种事件类型相应的已经注册的监听器，或者如果没有任何组件受到激活来接收事件类型，事件就被抛弃。
录制时，采用了监听器模式，和平常swing编程不同的是，这里的监听器不是针对某个组件的，而是针对某种事件的。也就是说，任何组件发出的同一类型的事件，比如鼠标或者键盘事件，都会被其相应的监听器捕获到，然后进行处理。然后将捕获到的JAVA事件，可以以某种格式保存在脚本文件中，这里就需要一个转换机制了。
回放时，则从脚本文件读取并还原事件，这里会用到java.awt.Robot类（JDK1.3之后引入的一个类，能模拟鼠标和键盘操作），这个类通常用来在自动化测试或程序演示中模拟系统事件，这个类主要的目的就是为方便的实现java的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
【编辑推荐】
