客户端GUI测试技术和自动化测试架构设计方案简谈.docVIP

客户端GUI测试技术和自动化测试架构设计简谈 客户端GUI测试技术和自动化测试架构设计简谈 客户端自动化特点 客户端的自动化，通常做过的人都不是很愿意深入讨论。因为除了功能和逻辑之外，不得不面对各种界面变化，各种和环境交互，各种兼容问题以及想不到灰色地带，就算这样，也找不到太多有效的bug。然而即便如此，客户端的自动化必须去做，尤其是GUI的。它的自动化特点是： 复杂 成本高 不容易发现问题 技术要求高 架构很难通用 下面，从一些基本的东西开始一点点的讨论客户端GUI测试的一些问题和处理办法，以及自动化架构设计的一些思路。事实上就像上面说的，GUI的测试并不是为了发现bug，而是回归的一种方式，作为保证而已——它过了不能说明质量多么好，但是不过，质量肯定不达标。即使在微软内部，客户端的GUI一样不是个受欢迎的家伙，通常用来做BVT的测试（或一些重要性回归，冒烟等）。 客户端自动化简述 这里并不花过多的笔墨介绍什么是客户端，或者如何分类的种种——这些东西教材和网上的东西一坨一坨很多很多，这里可能“漫谈”的，是实际工作中，客户端和GUI自动化中可能遇到的一些底层技术，基本上原理，架构设计方法以及一些项目存在困惑，这些方面的一些处理的方法。 最早的自动化 我个人认为所谓的计算机行业的自动化，是一直跟着这个行业的发展在走，比如下面的这些： 老式计算机——CPU计算： 最早自动解决手工分配穿孔的卡片问题 内存分配任务调度：操作系统的核心就是内存和任务的自动管理 系统配置Loader：操作系统启动的引导 自启动程序注册表：windows系统中自启动程序的配置 什么是自动化测试 我个人认为自动化测试，就是用技术和自动化去服务测试，保证质量，提高产品生产率（不是测试生产力）。无论如何这个行业需求是关键，脱离需求和具体环境，一切都是玩笑。 传统客户端 客户端的特点是基于操作系统之上，它的GUI一般寄生于操作系统的接口。传统客户端一般采用系统提供的默认GUI来完成主要逻辑功能。特点是技术相对简单，系统兼容性好，但是相对没有那么炫。对于自动化来说，尽管完成起来“冗余”，但是不存在技术的难点。也就是通道都已经铺平了，大部分流行的GUI工具都是服务于这样的客户端。 互联网常用客户端 互联网常用的客户端，由于为了提供用户体验度，大都采用directUI，无论哪种自绘方法，都不是系统直接提供的。另外，由于互联网客户端的功能很杂，对注册表的各种注入，操作系统的各种更改等，都会导致一些兼容性和安全性问题出现。这是互联网客户端的特点。 特殊客户端（浏览器） 浏览器作为特殊的客户端出现是因为它是b/s和c/s的一个界限，它本身是一个客户端，但是却是web的依赖着，PC上Web的主要入口。对于其他客户端，它的特点如下： 寄生js Cookies等安全 各种插件 W3c标准 其他 不同浏览器页面GUI识别不同 客户端自动化特点/htm/test/newweb.htm 一开始已经提到过客户端GUI自动化测试的特点，由于这些特点，导致很多没有预算和积累的公司，会放弃客户端GUI的自动化测试。 客户端自动化通用模型 一般来说，客户端GUI的自动化测试，大体可以分为5个部分，底层GUI技术，用例组织和开发，调度和执行，日志以及用户操作接口。事实上，除了底层GUI实现是客户端GUI的专属，其他的部分都属于一般的自动化测试架构部分，不过对客户端测试，这些部分可以适当调整。所以这里的重点，是GUI测试的底层。 底层实现/limi/index.htm 底层实现中包括GUI控件识别操作，信息hook，进程检测，文件管理等各种底层，其中GUI控件识别是难点，其他的都可以比较轻松的完成，任何工具和编程语言都有相关部分。关于控件识别部分，包含以下内容： 基本原理 控件识别是GUI的测试最核心部分，它是客户端GUI可测与否的关键——底层如果走不通，其他的都是噱头。 IPC 基本上操作系统标准控件默认使用的都是IPC的方式，实际上这个也是大多数GUI的底层技术，即进程间通信。被测程序和测试程序之间采取这种方式，达到GUI的识别和操作。 内存共享 内存共享是IPC的一种方法，这里提到只是说出了操作系统提供的IPC方法，一些项目和产品也可以自己采用内存共享的方法进行GUI的数据共享，比如测试输入法的时候，共享的数据可以使用windows接口hook到，但是中文输入的分音符”’”，是私有数据，不可能搞到。通常的做法就是在测试程序中给一个带有私有数据定义和传出的.h文件。 通信 这里的通信不只是IPC中的管道通信，而是真正的通信，它的特点是安全性高，但是效率低一些。某些情况下，底层处理好，易用性很高。比如web测试中流行的webdriver，其中chrome浏览器对应