2011-03-18 16:46:23

标签：技术 客户端 自动化 休闲 漫谈

原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://baidutech.blog.51cto.com/4114344/743864

一、 概述
1.1 开篇语
谈到客户端自动化，大家无疑都会想到让人又爱又恨的UI系统级自动化测试，曾经和微软的同学也聊过，即使在微软从UI进行自动化能够发现的bug也是非常有限的，并且开发和维护的代价都是需要投入大量人力才能够开展的。当然，自动化测试其实不是以发现bug为目的的，对于系统级别的自动化来说，用例的自动化回归验证显然对于自动化测试来说会更加有意义，特别在持续集成模式出来后，自动化测试的实际应用效果得到了真正的发挥。 
开篇谈了这么多“闲话”，其实希望大家能够正确对待客户端UI系统级自动化相关的技术，把握真正自动化的目的和意义，不要过分痴迷和追求技术层面的实现，而更应该结合特定的应用场景，发挥客户端UI自动化的效果。
本文结合之前的工作经验，从客户端UI自动化的基本原理、实现技术、框架方法简介以及具体的应用实例出发，为大家开启进行客户端UI自动化的工作的大门，希望可以为大家在开展类似工作时提供一些参考和借鉴价值。 
1.2 客户端自动化模型 
从之前的工作经历来看，客户端自动化的开展经历了从“UI识别和操作”，“case组织格式”、“case开发模式”、“测试框架”到最终的“持续集成”的一个过程。整个过程也体验了在自动化工作中从技术逐渐转向应用的一个进阶，尽管对于持续集成来说，单纯的UI自动化测试相比单测或者模块测试来说所占的比重较小，但是整体上来看，我们还是希望类似的系统级自动化测试或者专项的自动化执行可以和项目的实施模式相结合，在项目中真正发挥其作用，提高测试的效率。 
其中区别于其他类别的自动化测试来说，客户端UI的识别和操作可能是客户端自动化测试中最具有特点和辨识度的一项技术内容，这个也是后面要详细介绍的客户端自动化技术和方法；在此基础之上，case组织格式、case开发模式两项内容相结合决定了如何应用UI核心自动化技术实现客户端产品业务逻辑方面的具体实施方案；至于更高层面上的内容，如测试框架和持续集成等内容和其他类别的自动化测试是通用的，在本文中不作为重点介绍，上述几个方面及其关系可以参考图一所示的内容。

‍

‍

图一. UI自动化模型

上述模型反应了系统级自动化测试工作所要考虑的几个方面的主要问题，对于客户端来说区别于其他产品的自动化工作的最大特点就是UI的识别和操作，对于更高层次的内容，层次越高可复用性就越大，因此从case开发模式开始，对于服务器端程序的自动化测试工作开展就同样具备一定的参考意义。
本文从客户端最核心的自动化技术开始，按照自动化工作的开展思路（即图一中箭头所示的方向）将自动化的方方面面内容逐渐展开，不仅包括适用于客户端产品的特定UI自动化技术，同样包括适用于其他类别产品的case组织和开发模式相关的内容，希望以此思路来指导产品自动化工作可以顺利开展。
二、客户端自动化技术和方法
2.1 基本原理
这里面所说的客户端自动化技术和方法指的就是图一中的“UI的识别的操作”环节，更加详细的描述，这部分包括的技术目标有三个方面： 
 ·UI控件的识别 
 ·UI控件的自动化操作 
 ·UI控件状态的校验 
谈到解决UI识别和操作的最基本原理，其实就是进程间通讯（ipc），无论是哪种类型的技术或者方法，本质上都可以归结为这一模型。需要进行进程通讯的两端就是测试程序和被测程序（SUT)，而自动化的过程就是实现端到端的进程间通讯，整个客户端UI自动化模型可以归结为图二所示。

‍

图二. UI自动化测试模型
围绕这三个方面，在业界有过一些尝试，大部分内容严格地说只能作为方法，因为解决的都是部分问题或针对某类问题提供一些方法层面的东西，真正能够作为一项自动化技术的是ms从.net 3.0开始发布的UIAutomation（UIA），它提供了一整套解决UI自动化的技术方案，其中就包括解决困扰UI自动化难点的控件状态监控问题。 
方法一：win32 handle
 ·基本原理
这其中首当其冲的自然要数win32 sdk提供的一系列api函数，基本上来说就是基于窗口句柄（window handle）和消息的模式。概括来说，其基本原理就是通过系统标准控件消息实现在测试程序和被测程序之间的信息传递的目的。通过这种方法，对于标准控件，例如通过mfc、win32 api编写的标准windows桌面程序就可以非常轻松的实现包括控件自动操作以及状态获取的需求。 
在具体实现方面，可以通过类似findwindow、findwindowex等函数找到window handle，因为findwindow api对于控件的识别是基于(窗口类名、窗口名)、（控件类别、控件名）的元组形式，因此，可以说基于window handle的自动化方法是通过窗口类名、窗口名、控件类名、控件名来识别和标识UI控件的，在window handle的基础之上，可以通过标准的windows消息，例如BM_CLICK、BM_DBCLICK等消息来实现诸如控制和获取等基本自动化需求，基本原理如图三所示。

‍

图三. 基于win32 handle的自动化方法

 ·辅助工具
对于基于win32 handle的自动化方法来说，不得不说的一款辅助工具就是spy++，通过spy++就可以捕获到桌面应用程序的各类标准控件，从而可以得到包括其窗口类名、窗口名、控件类名、控件名等信息。大家可以通过点击此链接来获取spy++程序，开始尝试了解最基本的“标准UI世界”。此外，由于spy++在捕获诸如标准windows菜单或者浮动式窗口方面的存在不足，特意开发了一个工具（其实真是目的是为后面要讲的虚拟对象服务的）供此类标准控件信息的捕获。 
· 优缺点分析
优点一：适用于windows标准控件的UI识别和操作 
优点二：有很多现成的windows标准自动化库（qtp、pywinauto）都是基于该原理的 
优点三：通过介绍hook技术，就可以很方便的通过录制回放的模式实现脚本开发 
优点四：无需借助RD支持，就可以实现自动化 
缺点一：对于非标准控件（自绘控件）无可奈何 
缺点二：对于UI状态等待需要单独支持 
方法二：MSAA & UIA
如果我们不恰当的把win32 handle方式比喻为原始社会的话，那么MSAA和UIA对应的则是封建社会和资本主义社会。这两项技术都是微软本身做自动化所采用的方法，特别是对于UIA来说，更是一个融合了包括UI自动化所需的模式、接口以及事件通知机制，从而可以保证稳定的自动化执行过程和简单的用例开发过程。下面就分别就MSAA和UIA两项自动化方法和技术进行详细介绍。 
【MSAA介绍和分析 】
 ·基本原理
MSAA是Microsoft Active Accesibility的缩写，早在1997年的win95系统上就已经将MSAA包含进来。从本质上来说，MSAA技术类似dcom技术，从最初的设计来看，MSAA并不是专门为自动化测试而生的，它的出现是为了解决残疾人使用windows程序的问题，比如对于盲人来说，通过读屏器程序访问程序暴露出来的IAccessible接口，就可以获得程序的信息并转化为盲人可读的盲文或者其他信息，从而帮助盲人使用windows桌面程序。 
对应到自动化方面，读屏器等同于自动化测试程序，被盲人使用的程序就等同于被测程序（SUT），测试程序和被测程序之间的信息交互就是通过IAccessbile接口来实现的，因此对于MSAA来说，本质上就是需要被测程序按照IAccessible接口定义将UI信息暴露出来，从而为测试程序提供访问其信息的通道（图四所示）。IAccessible接口在win32的所有标准控件上都已经实现 ，所以通过MSAA方法也可以对win32标准控件进行自动化相关的操作和状态的获取（通过辅助工具可以查看MSAA相关信息），从这个层面上来看，MSAA可以认为会覆盖到win32 handle的自动化功能。

‍

图四 MSAA架构
更具体的，尽管IAccessible是基于com技术，并通过进程间com服务器实现ipc，但其接口并不是标准的com接口，其获取方法不是通过传统的QueryInterface方法来获得的，具体的获取方法可以参考MSDN中关于WM_GETOBJECT的说明。概括来说，就是通过发送WM_GETOBJECT消息（具体使用可以通过调用AccessibleObjectFromWindow系统api获取）来获得IAccessible接口，从而获取或者操作UI界面控件。 
通过IAccessible接口产品可以将独立于HWND的控件信息暴露给测试程序，从而辅助win32 handle模式获取一些自定义控件的信息，这个是win32 handle所不具备的能力，但是由于IAccessible接口仅提供了诸如访问关系、位置、名称等少量访问属性以及一些简单的操作，所以对于更加复杂的自动化需求来说，MSAA并不能很好的进行支持，更详细的IAccessible接口定义可以参考:
http://msdn.microsoft.com/en-us/library/ms696165(v=vs.85).aspx

 ·辅助工具 
和win32 handle模式的辅助工具一样，支持MSAA的辅助工具也很众多，其中最为流行的应该就是AccExplorer，通过AccExplorer不仅可以获得各种标准控件的属性信息，同时也可以获得诸如MSN一样自绘控件的属性信息，而MSN就可以看作是对于IAccesible接口进行了支持的一款典型客户端产品，AccExplorer就是一个基于MSAA模式的“测试程序”，更具体的信息大家可以参考：
‍http://msdn.microsoft.com/en-us/library/ms696165(v=vs.85).aspx

 ·优点和缺点
优点一：在win32 handle基础上，提供了对于自定义控件的支持 
优点二：现有很多自动化工具和实现是基于MSAA模式的 
缺点一：IAccessible接口功能非常有限，不能满足复杂UI自动化需求 
缺点二：自定义控件实现需要开发的支持 
【UIA介绍和分析 】
 ·基本原理 
UIA是UI Automation的缩写，单从字面意义上来看，UIA貌似就和UI自动化测试就有着不可分割的关系，而事实也正是如此。相对于win32 handle、MSAA来说，UIA是专门为了自动化而生的产物。在这里，对于UIA来说确确实实可以将其称为一项自动化技术了，因为不仅UIA在UI属性、UI操作方面都提供了良好的支持，而且对于UI自动化测试中至关重要的控件状态等待和同步机制也提供了很好的支持。更详细的信息可以参考：
‍http://msdn.microsoft.com/en-us/library/ms753107.aspx
http://en.wikipedia.org/wiki/Microsoft_UI_Automation#Version_history
UIA是在MSAA的基础之上进行优化并专门为了自动化而生的技术，在.net 3.0的时候正式对外发布。通过win32 ctrl/MSAA Proxies，UIA集成了MSAA和win32 handle的功能。win7系统更是直接集成了UIA API 3.0，其中包括托管api和非托管api，可以在xp、vista、server等系统上应用。从架构上来看，UIA主要分为UIA Core、provider api、client api以及对于win32标准控件的provider实现，其中UIA core提供了整个UIA模式的核心支持（例如ipc的通讯），provider api定义了被测程序提供属性和操作方法的接口，client api提供了操作和访问基于UIA程序的控件信息的接口定义和实现（如图五所示）。从UIA的架构和实现来看，无论是多么复杂的自动化测试技术，其本质上也是通过ipc来实现的，具体到UIA上就是通过命名管道的方式实现进程之间的通讯。

‍
图五. UIA架构:
对于UIA来说，更为突出的一点进步就是对于事件通知机制的支持，这项技术的出现解决了长久以来困扰UI自动化稳定性的一个难题，即对于控件状态的同步和等待机制，对于最原始的做法是通过在测试代码中添加sleep硬编码实现，更为高级一些则是通过轮询机制监控控件状态，在UIA中通过事件机制来解决UI状态反馈的问题，当然在实际应用中，事件回调机制的引入会增加测试代码编码复杂度，但是类似的问题可以通过进一步封装UIA来解决。 
 ·辅助工具
和win32 handle、MSAA模式一样，对于UIA来说，也有相关的辅助工具来进行自动化用例的开发，这里面给大家介绍一款最为常用的工具UI Spy。通过UI Spy就可以获得UIA进行自动化所需的信息，更具体的信息可以参考：
‍‍‍‍http://msdn.microsoft.com/en-us/library/ms727247.aspx‍
 ·优点和缺点
优点一：支持更加丰富的客户端程序，如Win32、WinForm、WPF、Silverlight 
优点二：提供了从控件操作、属性访问到事件机制的全面支持，解决复杂的自动化问题 
优点三：通过proxy实现对MSAA和win32 control的全面支持，更好的兼容性 
优点四：相对于MSAA更加丰富的UI属性访问能力 
缺点一：对于自定义控件的支持，需要开发实现相应的provider 
缺点二：xp、vista系统中native api的使用过于复杂，需要.net的支持 
缺点三：UIA直接编写测试代码复杂，效率低，需要更好的封装提高测试打开开发效率 
方法三：虚拟对象（坐标） 
 ·基本原理
相对于MSAA、UIA等自动化技术来说，虚拟对象更准确的说是一项仅解决了非标准控件自动化操作和“部分识别”的方法。其基本原理就是在控件坐标的基础上加上了控件停靠和布局的理念。在QTP中，解决非标准控件（自绘控件）的一种方法就是“虚拟对象”（virtual object），但这种方法仅基于控件的相对坐标，对于控件所在窗口的状态发生变化的情况下，这种方法在“识别”控件时就会发生失效。除此之外，对于诸如autoit、按键精灵等自动化小工具来说，其基本原理也是基于坐标的方法，同样会存在“识别”失效的情况。对于本文所提到的虚拟对象方法来说，是一种在坐标基础上添加了控件停靠和布局的概念，它在布局的基础上，大大解决了由于控件窗口发生变化所引起的“识别”失败的情况。 
概括来说，虚拟对象的方法分为三个阶段：
1. 通过辅助工具捕捉虚拟对象并构造虚拟对象库 
2. 执行阶段，根据虚拟对象信息，动态计算虚拟对象的坐标 
3. 根据坐标对虚拟对象进行操作或者“识别”
‍‍

  

‍
图六：虚拟对象实例
· 辅助工具 
在基本原理中提到的虚拟对象识别工具HiUISpider，其基本实现原理类似于spy++，除了spy++中捕获具有win32 handle的窗口或者控件外，还可以通过鼠标来圈定虚拟对象所在的区域，并设置虚拟对象的停靠以及尺寸类型，从而根据上述基本原理完成虚拟对象库的建设。在基于坐标方法的自动化执行中，还可以借助autoit、按键精灵来实现部分特殊需求的自动化执行工作。 
 ·优点和缺点 
优点一：对于自定义控件的通用解决方法，无需开发支持 
优点二：相对于MSAA/UIA等技术，更加灵巧快捷 
缺点一：额外的虚拟对象库建设 
缺点二：在UI发生变化时，虚拟对象库有可能需要更新，维护代价大 
缺点三：仅具备点击、图像识别、屏幕取词等基本操作和获取能力 
方法四：Api Hook
 ·基本原理 
Api Hook技术在自动化测试中也扮演了很重要的角色，其解决的主要问题是用hook的方法来获取程序中的信息，而最常见的情况就是通过api hook来获取屏幕输出的文字，即在字典软件中提到的屏幕取词技术。对于api hook来说，顾名思义就是来截获系统api的调用，通过api调用的截获就可以获得程序中隐藏的信息。以屏幕取词的实现为例，就是通过api hook来截获对于textout、drawtext、drawstring等文字输出方法的调用，从而就可以知道程序在“何时”、“何地”输出了“什么文字”，进而可以达到抓取ui上文字的效果。 
Api Hook在具体实现上分为动态hook和静态hook两种，对于自动化测试来说用到的主要是动态hook的方法，核心的思想就是在进程启动后，通过修改目标函数的二进制镜像来实现的，常见的包括IAT Hook、Detour Hook，其中IAT（Import Adress Table）Hook的实现是通过修改导入函数表来达到截获对于某些系统api的调用，对于Detour Hook来说，则是通过直接修改目标函数地址空间的头几条指令实现跳转到Detour Function（截获后的执行入口）上的，基本原理和实现如图七所示，关于Detour Hook更详细的信息可以参考：
http://research.microsoft.com/en-us/projects/detours/

 

图七. Detour Hook基本原理
 ·辅助工具
Api Hook可以通过微软的Detour Lib库来实现，具体可以参考这里，对于特定的屏幕取词需求就可以在DetourLib的基础上通过截取TextOut、DrawText、DrawString等系统api的调用来实现，也还可以直接使用商业的GetWord屏幕取词库来使用（当然会涉及到License问题，但较之自己编写的库要强大很多）。 
· 优点和缺点
优点一：可以实现对于非标准控件UI文字校验 
优点二：借助Api Hook，可以实现部分性能测试的需求（响应时间） 
缺点一：需要额外的开发代价，专项专用 
缺点二：也仅是一项自动化方法，解决特定问题 
方法五：基于图像
 ·基本原理 
在自动化测试中，经常会遇到图像相关的验证工作；同时对于自绘控件来说，在没有开发支持的情况下，类似于MSAA/UIA等技术完全发挥不了作用，而对于虚拟控件的方法来说，还需要一个预处理过程。其中针对图像部分的校验，就是传统的一些图像处理领域的技术，多少有些大材小用的感觉。在本文中，基于图像的方法着重介绍的就是通过图像识别技术而进行的自绘控件的自动化操作实现，即在百度质量部中已经有所应用的sikuli。 
概括来说，Sikuli就是在可视化技术的基础上，使用图像方法实现对于自动化测试中的执行步骤的过程，对于自绘控件的识别就是通过图像识别来进行的，同时通过提供可视化的IDE环境，实现了快速的自动化用例开发过程，大大提高了自绘控件自动化能力，且自动化的实现是不依赖于开发的支持，这样对于类似第三方软件的评测来说，也提供了一个不凑的自动化实现方案。 关于Sikuli的更详细信息可以参考如下内容：
‍http://sikuli.org/‍
 ·辅助工具 
对于sikuli来说，可以使用其自带的可视化IDE环境进行开发，对于大部分客户端软件的自动化执行的编写过程来说，都可以在IDE环境中通过图像截取的方法来实现，如图八所示：

‍
图八. sikuli集成开发环境
 ·优点和缺点 
优点一：自动化用例的编写过程可视化，入门门槛较低 
缺点一：图像识别的效率必然影响到自动化用例的执行效率 
缺点二：基于图像识别的自动化方法的稳定性较差，容易受到UI变化的影响 
缺点三：也仅是一项自动化方法，解决特定问题 
方法六：后门（自定义消息&共享内存） 
 ·基本原理
尽管MSAA/UIA提供了一套完整的客户端UI自动化解决方案，但是在开发对于自动化的支持程度不高的产品实施起来还是困难重重的，因此还有一种简化的UIA自动化解决方案，即传说中的“后门”，这里传统的“后门”是指开发在程序中专门为了某些目的开设的访问通道，通过这些隐秘不为人知的数据访问通道，可以实现特殊的产品功能。对于自动化来说，我们可以通过后门的方式来将程序的一些界面信息暴露，当然也不局限于UI的信息，我们也可以将任意测试程序需要的信息通过后门的方式暴露给我们自己的测试程序即可以实现自动化相关的需求。 
这里要和大家分享和总结的就是在之前工作中积累的一些开设后门的方法，概括来说包括两个方面：自定义消息和共享内存。其中消息在访问控制上的便捷是优于共享内存的方式，但是在数据量的传输方面，共享内存具备消息所不具备的大数据量信息。在将两者结合后，我们可以实现被测程序和测试程序之间的通讯。 
概括来说，消息就是测试程序通知被测程序的一种方式，可以用来驱动被测程序的执行，或者通知被测程序将特定的UI信息更新到共享内存中。而双方之间所需要协商的就是用来通讯的协议格式，在具体实践中包含两类比较常用的方式：：结构体以及xml格式。对于结构体来说，可以非常方便的进行数据的访问，对于xml来说，则具备更加灵活的特点，可以根据产品需要暴露信息的特点来选择采用和中通讯方式以及协议格式。 
· 优点和缺点
优点一：简化版的UIA实现方案，能够更高程度地在用例稳定性和开发介入间取得平衡 
优点二：和UIA一样，在自定义控件的自动化测试和获取方面具备稳定的优势 
缺点一：对于每种产品的方案以及数据交互协议需要单独设计 
缺点二：还是需要开发同学在一定程度上给予支持 
更多。。。
除了上面提到的一些自动化方法或者技术外，还有一些在平时客户端自动化工作中经常会遇到的小技巧在这里也分享和总结一下： 
· 进程外com服务器
进程外com服务器本身就是在windows系统上的一种ipc通讯方法，对于类似MSAA/UIA等技术实现来说本质上也是基于这种方法的。本文提出进程外com服务器主要还是针对客户端产品的集成IE控件的自动化操作需求。对于现在的客户端产品来说，越来越多的会融入各种IE控件来展现诸如特定的网页信息，这个从产品的角度来看，也是互联网时代的客户端产品的特点，对于这类控件来说，使用上述所有的技术或者方法都无法搞定具体的需求，这时候就需要使用到com接口访问特定的IE控件对象来实现。 
在具体实现上，就是通过com技术，访问到被测程序的IHtmlDocument2接口，从而操作IE控件的各种元素并获得相应的属性。现有的一些web自动化类工具要不采用的插件形式，要不就是绑定到具体的浏览器插入特定的js代码，对于类似的IE类控件就需要在com服务器的基础上实现相应的自动化操作，并提供类似于传统web自动化框架的录制回放工具，更详细的信息可以参考这里。 
 ·剪贴板
剪贴板其实上也可以归类为一类windows系统上进程间通讯的方法。在自动化用例的开发过程中，对于某些特殊编辑控件的操作或者状态获取则可以使用剪贴板来实现，借助于系统的快捷键以及相应的系统api调用就可以很方便的实现这一类特殊方法来“山寨的实现”。 
 ·其他
除了文中列出的一些方法外，还有很多自动化的方法以及特定的需求，诸如网络抓包，本地数据库操作等，在此不再详细介绍。 
三、用例格式 & 开发模式 & 测试框架 & 持续集成 
除了上述客户端自动化所需的技术外，和其他的自动化测试工作一样，客户端的自动化测试同样需要在用例格式、开发模式以及测试框架方面需要进行考量，其中测试框架、持续集成和其他模块自动化测试、web自动化测试基本上具备相同的工作开展思路，因此不在本文中详细介绍。

3.1 用例格式
客户端自动化用例的组织格式对于自动化用例的开发以及稳定性运行也就具有非常重要的作用，因此除了关注客户端自动化技术层面的内容外，用例组织格式也是自动化工作中需要重点考虑的内容，根据之前的整理，介绍几种比较常见的用例格式为大家提供一定的参考价值。 
3.1.1 基于脚本/代码的格式
 ·概述 
最常见的自动化用例就是直接通过编写程序代码来实现的，在各种客户端自动化技术的基础上，通过直接调用相应的自动化技术来驱动被测程序的执行以及校验相应的用例执行结果是否符合预期。对于基于程序代码的自动化用例格式来说，更多选择的程序语言一般都是脚本语言，例如python、ruby、shell等，这类脚本语言在用例的开发上具备更加简单的接口以及可以扩展的机制，因此常常被选择来作为自动化用例的开发语言，并且对于类似的脚本语言一般都具备非常成熟的基础库，可以很方便的在自动化用例中进行引用。 
除了程序语言的选择外，还需要考虑基于代码的自动化用例如何进行组织，一般可以通过类似的xUnit系列的测试框架来组织各种测试用例，从而保证用例之间的组织能够规范的按照特定的格式来进行，并且通过类似的xUnit测试框架还可以对于环境的构建、清理等工作进行合适的处理。

‍
图九. python自动化用例
 ·优缺点
优点一：自动化用例格式简单、直接 
优点二：自动化用例编写过程更加灵活（各种实用库、用例逻辑组织） 
缺点一：自动化用例开发需要具备一定的技术背景 
缺点二：在某些场景下，开发效率稍显低下 
3.1.2 基于表格的格式
 ·概述
在基于代码的用例格式中，曾经提到在某些场景中用例开发效率低的问题。这其中一个比较典型的场景就是针对于偏向数据处理类型的产品的自动化用例开发。对于这类产品的自动化来说，直接使用脚本开发的成本会相对较高，在这种情景下，基于表格形式的自动化用例组织是一种更合适的组织格式。基于表格形式的自动化用例的开发过程，特别是对于这一类数据驱动模式的自动化用例开发来说，实际上就是在整理和收集各种测试数据到表格形式的自动化用例中。 
除了数据驱动模式的自动化用例开发可以采用表格形式来组织自动化用例外，对于关键字驱动的自动化用例开发过程来说，也可以通过表格形式来组织。表格中的用例内容实际上就是各种关键字（action)的列表或者集合，相对于直接基于脚本/代码的自动化用例来说，使用表格形式来组织关键字驱动的自动化用例适用于那种业务流程比较简单，没有太多分支循环结构的自动化业务流程。这其中一个比较有代表性的测试框架是google的robot框架，更详细的信息可以参考：
http://code.google.com/p/robotframework/

图十. Robot自动化用例格式

 ·优缺点
优点一：适用于数据驱动、简单逻辑的产品自动化用例开发 
优点二：专项专用，自动化用例开发效率比较高 
优点三：用例的测试数据或者流程清晰明了 
缺点一：需要额外的解释器对“表格数据”进行解析 
缺点二：对于业务逻辑复杂的产品自动化不适用 
3.1.3 基于自定义的格式
 ·概述 
在有很多情况下，经常会有按照自定义的格式进行自动化用例开发的需求。在介绍这部分自动化用例格式之前，个人会认为尽量不要为了自动化而单独进行类似用例语言解释器的开发工作。在各种脚本语言、各种文件格式已经很丰富的背景下，相信总会有一款合适的格式适合于当前产品自动化用例格式的需求。对于这部分想以具体的实例来介绍自定义的自动化测试用例，这里面比较常用的就是xml这种在现在的软件开发中应用非常广泛的标记语言。其中较为典型的应用就是STAF(Software Test Automation Framework)中的STAX服务中的自动化用例（任务）定义格式,对于xml格式的自动化用例格式来说可读性会比较差，所以一般都会有对应的xml解析工具来辅助自动化用例的编写以及开发工作。更详细的信息可以参考：
http://staf.sourceforge.net/

 ·优缺点
基于表格形式的自动化用例可以看作一种特殊的自定义用例格式，因此表格形式的自动化用例格式的优缺点也适用于自定义格式的自动化用例格式。 
· 实例
STAF自动化测试框架中的STAX服务及其任务配置；
3.1.4 其他 格式
除了上述几种自动化用例组织格式外，还有很多商业自动化用例解决方案，往往它们自己都会提供非常丰富的IDE环境，可视化自动化用例的信息。同时结合IDE的良好的用户操作接口，可以方便整个自动化用例的开发过程，但是这一类自动化用例来说，本质上也离不开上述几种自动化用例格式。例如QTP(Quick Test Professional)中展现的自动化用例，实际上在IDE后面隐藏的就是VBS直接编写的自动化脚本，在此不再详细介绍。 
3.2 开发模式 
自动化的开发模式往往和自动化用例的格式相关，两者之间有着密不可分的联系。对于特定的开发模式来说也会有对应的自动化用例组织格式与之对应，同样，对于特定的自动化用例组织格式又往往和某些自动化用例的开发模式相关，本文主要介绍三个方面的开发模式，也是在客户端自动化中经常会用到的方法。 
3.2.1 关键字驱动 (Keyword Driven)
对于客户端产品来说，很多都是偏向业务型的产品，例如IM类、安全管理类，复杂的业务逻辑决定了在进行自动化用例开发的时候需要将一些经常会用到的执行序列封装起来进行重复性的自动化用例开发工作。而这个封装常用执行序列的过程实际上就是关键字驱动的核心。关键字驱动从一定意义上来说，和软件开发中的封装有一定相似之处。更加直白的解释关键字驱动中的关键字就是一些常用的操作执行序列的封装函数，通过这些封装，我们就可以大大提高自动化用例的开发效率。 
在业界，例如QTP、Robot等工具或者框架的核心思想都是基于关键字驱动的框架，对于类似模式的自动化用例开发来说，核心就在于关键字的梳理、分类和开发工作上。关键字的划分往往需要对业务很熟悉的测试工程师来进行主导，并且对于关键字的数量需要进行严格控制，更多的关键字对于自动化用例开发来说未必是一件好事。 
对于关键字驱动模式的自动化用例开发来说，与其对应的自动化组织格式可以采用直接通过脚本编写的方式来进行，除此之外，也可以采用类似的表格形式来进行关键字驱动的开发，但是对于类似采用表格形式进行关键字驱动的开发来说，业务逻辑的复杂性需要是一个重点考核的对象。因此对于表格形式的自动化用例格式来说，顺序执行是一种期待的业务流程，如果整个业务流程会涉及到复杂的分支以及循环，表格形式就很难满足类似的需求。下图显示了QTP中基于关键字驱动的界面开发UI。

图十一. QTP(Quick Test Professional)关键字驱动
3.2.2 数据驱动

‍ 相对于业务逻辑比较复杂的产品来说，客户端软件也存在很大部分偏向数据处理类别的软件，例如输入法、浏览器类。对于这类产品的自动化来说，业务流程比较简单，但测试数据非常复杂，在这样一种情形下，经常会采用数据驱动的模式来进行。这样不仅可以保证用例开发的效率，同时可以将影响测试覆盖度的核心要素——测试数据真实的反应到自动化用例中从而得到很好的展现和组织。 
与数据驱动的开发模式相关的用例组织格式一般都是表格形式，通过某些特定的解释工具以及精简的执行引擎结合就可以实现基于数据驱动模式的自动化用例开发。对于客户端产品来说，数据驱动往往会在特定场景中进行应用，比如浏览器的基础功能测试，输入法的词库测试，对于这些场景来说，其基本操作都可以归为一类，主要需要测试的就是在不同的测试数据前提下是否可以测试通过。因此采用这种数据驱动的方法比较适合进行类似性质的功能测试。除此之外，对于数据驱动模式的来说，还经常会在安全性测试中应用，例如通过数据驱动的方法，可以实现fuzzy test相关的测试，当然这部分的核心思想主要就是针对测试数据的自动生成而展开的。 
3.3 录制回放模式
在win32桌面程序或者web系统自动化测试中，经常还会用到的一种开发模式就是录制回放的模式。相对于关键字驱动、数据驱动的开发模式来说，录制回放的模式更加简单，入门门槛比较低，开发的效率也会大大提高。在技术实现上，录制回放的模式往往会通过hook的方式将与自动化操作相关的部分截取下来，从而可以将自动化执行部分的开发效率降低到手工执行的同时。对于基于录制、回放的开发模式来说，单纯的录制、回放并不能完全反映整个用例开发的过程，录制、回放完成后，往往还要经过手工修改录制后的自动化脚本，加入自动化校验部分才算完成整个自动化用例的开发流程。 
在真实的应用中，录制回放模式常常作为关键字驱动、数据驱动两种模式的辅助模式出现，提高测试用例的开发效率。例如在QTP中，录制回放后的自动化脚本经过适当的抽取后，封装为常用的关键字库，从而实现快速的自动化用例开发过程。同样的，对于数据驱动来说，也可以通过录制回放的方式执行引擎部分的开发效率。 
还有一种广义的录制回放模式，在客户端自动化中可以进行应用，即日志回放模式。其基本原理就是在程序中通过将用户的行为进行日志输出，并标识为特定类型的日志与产品的其他日志进行区分。在测试人员进行操作的同时，实际上就已经记录了之前进行的一系列操作，只要进行简单的日志解析，并对应到具体的自动化实现上，就可以很方便的对自动化执行序列进行录制的工作，从而进一步提高自动化用例的开发效率。和传统的录制回放模式相比较，基于日志的回放模式，无需其他程序的参与就可以很方便底进行自动化用例的录制工作，但是需要开发同学在产品层面进行支持。 
通过日志回放模式，就可以实现低成本的测试用例转化工作，测试人员输出的日志实际上就是一个测试用例的执行部分，通过将这些日志统一存储和管理，就可以很方便的实现基于日志回放模式的稳定性自动化测试系统，可以解决各种复杂场景的构造问题，进一步，在产品发布阶段，通过日志回放模式也就可以收集到各家复杂的测试场景，直接应用到稳定性自动化测试过程中，这种模式无论是对于客户端产品，还是其他类别的产品来说，从基本模式上都是可以相互借鉴的。
四、后记
对于从UI进行系统级功能测试需要重点关注UI自动化的可测性分析，往往对于业务逻辑复杂的客户端类产品，特别涉及到复杂用户场景相关的情况下，从UI构造各种复杂的测试场景代价会远远高于自动化带来的收益；另外，如果客户端产品涉及到多源的输入（例如网络交互），我们需要首先保证所有的输入数据源都是可控的，例如对于浏览器测试中的网页数据、IM类软件的用户数据等都需要事先构造完成，否则也会导致自动化用例执行的不稳定性。 
本文中介绍的各种自动化技术或者模式，除了实现系统级的功能自动化外，可以重点考虑在特定场景下的应用，有可能投入的成本对比收效来说会远远超出预期。例如可以考虑自动化执行部分在性能测试中的应用，或者通过日志驱动模式构建action lib，从而实现对于稳定性测试的fuzzy action等技术难点，进而搭建整个客户端的稳定性自动化测试系统。