标签：style blog java http tar ext
客户端的自动化，通常做过的人都不是很愿意深入讨论。因为除了功能和逻辑之外，不得不面对各种界面变化，各种和环境交互，各种兼容问题以及想不到灰色地带，就算这样，也找不到太多有效的bug。然而即便如此，客户端的自动化必须去做，尤其是GUI的。它的自动化特点是：
下面，从一些基本的东西开始一点点的讨论客户端GUI测试的一些问题和处理办法，以及自动化架构设计的一些思路。事实上就像上面说的，GUI的测试并不是为了发现bug，而是回归的一种方式，作为保证而已——它过了不能说明质量多么好，但是不过，质量肯定不达标。即使在微软内部，客户端的GUI一样不是个受欢迎的家伙，通常用来做BVT的测试（或一些重要性回归，冒烟等）。
这里并不花过多的笔墨介绍什么是客户端，或者如何分类的种种——这些东西教材和网上的东西一坨一坨很多很多，这里可能“漫谈”的，是实际工作中，客户端和GUI自动化中可能遇到的一些底层技术，基本上原理，架构设计方法以及一些项目存在困惑，这些方面的一些处理的方法。
我个人认为所谓的计算机行业的自动化，是一直跟着这个行业的发展在走，比如下面的这些：
我个人认为自动化测试，就是用技术和自动化去服务测试，保证质量，提高产品生产率（不是测试生产力）。无论如何这个行业需求是关键，脱离需求和具体环境，一切都是玩笑。
客户端的特点是基于操作系统之上，它的GUI一般寄生于操作系统的接口。传统客户端一般采用系统提供的默认GUI来完成主要逻辑功能。特点是技术相对简单，系统兼容性好，但是相对没有那么炫。对于自动化来说，尽管完成起来“冗余”，但是不存在技术的难点。也就是通道都已经铺平了，大部分流行的GUI工具都是服务于这样的客户端。
互联网常用的客户端，由于为了提供用户体验度，大都采用directUI，无论哪种自绘方法，都不是系统直接提供的。另外，由于互联网客户端的功能很杂，对注册表的各种注入，操作系统的各种更改等，都会导致一些兼容性和安全性问题出现。这是互联网客户端的特点。
浏览器作为特殊的客户端出现是因为它是b/s和c/s的一个界限，它本身是一个客户端，但是却是web的依赖着，PC上Web的主要入口。对于其他客户端，它的特点如下：
一开始已经提到过客户端GUI自动化测试的特点，由于这些特点，导致很多没有预算和积累的公司，会放弃客户端GUI的自动化测试。
一般来说，客户端GUI的自动化测试，大体可以分为5个部分，底层GUI技术，用例组织和开发，调度和执行，日志以及用户操作接口。事实上，除了底层GUI实现是客户端GUI的专属，其他的部分都属于一般的自动化测试架构部分，不过对客户端测试，这些部分可以适当调整。所以这里的重点，是GUI测试的底层。
底层实现中包括GUI控件识别操作，信息hook，进程检测，文件管理等各种底层，其中GUI控件识别是难点，其他的都可以比较轻松的完成，任何工具和编程语言都有相关部分。关于控件识别部分，包含以下内容：
控件识别是GUI的测试最核心部分，它是客户端GUI可测与否的关键——底层如果走不通，其他的都是噱头。
基本上操作系统标准控件默认使用的都是IPC的方式，实际上这个也是大多数GUI的底层技术，即进程间通信。被测程序和测试程序之间采取这种方式，达到GUI的识别和操作。
内存共享是IPC的一种方法，这里提到只是说出了操作系统提供的IPC方法，一些项目和产品也可以自己采用内存共享的方法进行GUI的数据共享，比如测试输入法的时候，共享的数据可以使用windows接口hook到，但是中文输入的分音符”’”，是私有数据，不可能搞到。通常的做法就是在测试程序中给一个带有私有数据定义和传出的.h文件。
这里的通信不只是IPC中的管道通信，而是真正的通信，它的特点是安全性高，但是效率低一些。某些情况下，底层处理好，易用性很高。比如web测试中流行的webdriver，其中chrome浏览器对应的是chromedriver.exe，这个驱动就是采用代理和通信的方式完成的。Chrome内置一个服务，chormedriver.exe会开启一个socket和chrome连接驱动浏览器执行，selenium使用http和chromedriver通信，达到和其他driver使用封装的一致。
后门的方法，其实上面提到的输入法私有数据就算一种，开发提供.h文件到测试系统中，只给测试程序开后面。
当然还有其他的方法，比如编译出测试版本，进行测试，发布版本关掉这些支持；还可以开发直接提供一些hook工具，开启的时候提供相关支持等。
自绘控件，是GUI测试的最核心问题。这个问题是这样的——即使开发人员帮着写自绘控件的支持，也不会每个控件都写，每个方法都写，如果这样的话，用一些流行的工具，还是会错误百出。
最根本的自绘控件实现，可以参考Chrome的源代码，windows的chrome，在UI上，都实现了这个东东。总的来说，需要三个步骤：
Chrome中原生的界面库采用这种方式实现，这样的事例在chrome中看到很多，比如：
初始化：
注册：
接口实现：
hook的方法前面提到过一些，有些情况并不适合做控件的这些接口支持，还是用前面的输入法为例，及时是操作系统自带输入法，在微软内部也没有实现——最早的微软输入法是有IAccessbie的支持，后来的就没有了。微软内部也是采用hook的方法去进行测试的。一些互联网公司的输入法，同样也是hook去解决。
坐标去判断是一种无奈之举，但是有时候确实有用。之前我做过的一个特殊需求，就是完全的模拟用户乱点浏览器页面的链接，不能用任何接口和通信支持。最终打开页面的时候，用鼠标在整个页面扫一下，记录下鼠标指针变化的位置。
Win32handle是基于句柄和消息的windows sdk中的一个工具，是windows系统中，GUI最基础的支持。通常能获取窗口句柄信息，类名消息等，使用相关windows api操作。当然根本技术还是IPC，被测和测试之间通信完成。如下：
获取采取windows api的方式
这种技术能处理起来比较简单，也是很多流行工具的根本原理。但是使用的范围极其有限。
Msaa是在windows api的基础上，专门应对IAccessible接口而设计的，msdn上有各种相关的资料。它还是基于IPC技术的，原理如下：
Msaa的核心和ole，com这些是一样的，因为msaa的实现依赖于oleacc。事实上这些技术的核心，就是边界值检测和引用计数，但是由于不是这里的重点，所以这里不详细讨论。可以参考各种教程，比如wiki。
Msaa可以获取更多hwnd的隐藏信息和一些自定义控件的信息，如下图所示：
Msaa的信息获取，可以通过oleacc实现。比如在一下的python代码（更多请参考python的msaa封装，在之前的相关博客）：
最终结果如下：
Msaa的方式能够满足大多数需要，但是还有其局限性。
UIA是在.net framework之上，所以针对msaa，提供了更多有效的功能。然后由于结构的复杂，需要更强的编程能力。UIA的原理如下：
类似的，UIA可以获取到如下信息：
由于UIA的部分需要.net framework的支持，暂时没有示例。但是毕竟是在framework之上的东西，网上相关的教程也是一把一把的。
UIA的特点是提供了更为丰富的实现和功能，IPC结构更加完善，使用便利，支持vista以上系统和WPF的测试。。缺点是太过于繁琐，开发复杂。微软内部的GUI测试架构Mita，也是完全重新封装UIA的架构，不进行二次封装，很难快速的使用。比如msaa整个的封装可能几K而已，但是UIA相比之下，就是巨无霸级别了。当然各种基于UIA的工具，性能可想而知——很多情况下我们需要测试XP和一些老式的低配机，这种情况下它并不适合。
严格来讲，我本人并不推荐这种技术，一方面不稳定，另一方面性能消耗较大。
大的方面说，有一些整体都基于图像的如ikuli，可以通过图像去识别驱动一些程序，并且不依赖被测程序开发。但是我个人认为这东西用在自动化测试上，并不实用。
小的方面说，一些用例的检查点，和图像有关，这时候需要做一些基于图像的处理，比如对比图片MD5呀，分析图像色度之类的功能。
所以基于图像的技术，可以用在一些边角的实现上，不太适合作为底层的主角——当然这是我个人的体会。
Web的GUI之所以放到最后，是因为它的特殊性——常用的浏览器中，原理是不同的。在IE上，由于有com的支持，页面的GUI和控件是一样的，selenium中IE的driver部分也是这样的原理，甚至一些基于IE内核的浏览器，只要内嵌IE_frame结构，都是一样的，如下：
对于Chrome的页面GUI，之前已经提到过chromedriver.exe了，它是采取了通信的手段实现，而不是com或Ole这种基于IPC的方式。
辅助工具，指一些辅助开发使用的GUI查看工具，这些工具比较多，包括上面使用过的spy++，inspect，当然还包括各种UIASpy等等。当然也可以自己开发，或者使用网上其他的工具，这部分工具还是很多的。
Web页面的自动化工具，如果单独的IE情况下，可以像上面那样按照客户端GUI的方式完成，但是如果使用selenium这样的架构，最好还是像chrome一样使用自带的开发者工具完成web结构定位等。好在IE也有相应的开发者工具，而且相比真正客户端的层级关系，web的更加规范，也稳定。
Unittest是两个聪明的家伙创作的（名字忘了），最早在smalltalk的单元测试中，后来到JUnit和pyunit。
用Pyunit举例，大概包含如下部分：
TestResult：用例结果实例，架构自动调用
TestCase：测试用例基类
TestSuite：测试套件实例，用来管理测试用例
TestLoader：加载测试用例，返回一个测试套件
TextTestRunner：执行实例
TestProgram：执行核心
对于这个优秀的小测试架构，当然不能浪费了。有些测试用例的执行和管理，直接使用这个架构。
另外，很多大型的测试驱动架构，和这个小架构核心非常类似，比如微软的MTM，用例管理的套件，思路上很像。
直接使用这个框架，大部分是三种情况：
第一种在uniitest框架上编写用例，和一般的单元测试相似；
第二种动态将测试用例在执行时转化为uniitest结构，并且执行；
第三种借用测试套件管理测试用例；
基于unittest的用例组织和管理直接，灵活，但是对于场景复杂并且测试人员 编程功底不够的情况，是不适合的。
更多内容可以参考：http://pyunit.sourceforge.net/pyunit_cn.html
unittest中提供的，只是一种格式，事实上用例的格式千变万化，没有所谓的最好，只有最适合。
文本类的用例比较适合编写，而且不存在太多复杂的东西，定义好用例结构，可以直接解析。
扩充容易，复用度高——编辑容易出错
比如网上的一个示例：
编写容易——结构不严谨，难扩展
比如IBM的robot中的测试用例结构：
excel格式的自动化用例一般都用在数据驱动的架构中，一般底层封装层次比较多，只留下外部数据接口，这种测试用例适合简单但是数量多的测试情况。如下；
脚本的测试用例一般测试开发人员比较提倡，无缝调用，适用性强，并且重用度高。但是这种用例需要一定编程功底。
类似的用例如下：
Java&C#的测试用例类似于下面的情况：
Python的测试用例使用比较多，chrome和互联网的发展，让Python的地位越来越高，典型的用例如下：
嵌套用例
一些场景类的用例，需要很多重用的逻辑，也就意味着需要有很多公用的用例或者模块，一些最终用例也很可能某一天，会成为公共用例。这样的情况下，需要实现嵌套的结构。
一般来说，这样的情况分为两种方法。一种是脚本或者编程语言写的测试用例，这种用例可以打包为模块或者测试套件实现公用；另一种是文本类用例，这种情况下必须采取文本嵌套的模式进行调用，比如xml的：
将每一个step都统一成一个文件，这样就实现了用例的递归调用。
无论包方式还是文件方式，都是都是以模板和功能为核心进行文件夹的管理。一般会统一到svn或者其他源代码管理工具，因为测试用例也需要维护，某种程度上，这就是代码。
用例驱动方面，我个人并不提议各种驱动什么的，这些是个名词而已，而且大都是针对使用工具的人来介绍而已。对于架构设计和开发人员来说，更关注的是名字后面代表的各种含义和解决方案。
我个人对这些驱动的解释是，他们没有本质性的差别，只是在封装、重用和特殊需求下的粒度不同，有些极端，有些折中。
这种方式是大多数流行的测试工具所提倡的，因为这些测试工具并不是为工具开发者使用，而是商业的，所以这种方式最适合，也有推广性。
这种解决方案适用在业务复杂，重复度一般的情况下。除了底层的封装外，外层封装和测试用例都是和业务逻辑对应的，管理和封装方法也取决于业务逻辑特点。一般来说将业务的最小粒度分层封装，一直到业务顶层。执行的时候只需要判断关键字的结构和分层顺序执行。
这种解决方案完全为由测试开发人员决定，一般来说，底层封装完全，提供了共有的接口之后，业务很乱或者对业务不理解，都会直接保留接口封装而不是业务逻辑，这样的情况下，以后业务梳理完一部分，用方法顺序执行一部分。当然，测试开发负责接口开发，手工测试进行逻辑业务用例编写一般也是这种情况。
所谓数据驱动，是自动化测试的一个极端情况——这种情况业务逻辑相对单一，但是需要反复测试不同的数据。这种情况下，外部接口相对简单，用例更多的是数据的编写和组织。比如之前提到的输入法的测试，比如我新开发一款输入法，需要测试a开头到z开头的100万个字母串输入的首个匹配中文，并且和搜狗的输入法做对比，这就是典型的所谓数据驱动模式。功能逻辑的接口很少，但是需要不断重复执行，去测试不同的数据。
场景驱动，噱头的成分更大一些。纯面向对象的业务开发都没有什么成功的案例，面向业务和服务的开发模式，更是不实际。个人觉得所谓的场景驱动，是建立在一定粒度的关键字驱动封装之上。一些稳定回归的，逻辑固定的场景抽象出来，作为独立的部分，所以纯面向场景的驱动不是没有，而已意义没有宣传的那么大，它更多是结构上的，但是实际工作上很少完全场景化。
录制回放的方式，比场景驱动噱头还要大，尤其在一些控件点击和web元素执行的情况下。录制回放并不能算作一个驱动方式，只是一种辅助的手段，好处是一些技术基础差的测试人员能够参与测试用例的开发中，提高开发速度。不好的地方，是录制后的脚本和用例一样需要修改和调试才能实际工作，而且在自动化架构开发的过程中，需要配套的使用hook和消息机制，做出相关的录制功能。实际工作并不是商业软件开发，需要合理的折中预算和人力投入，所以做不做是要看收益。
但是事实上，录制回放可以和后续的日志部分结合一起——执行步骤，日志和录像都可以通过索引整合到一起，定位到出错部分，并且重现。这是它的另一个好处。
前面所有的东西，包括底层和测试用例管理驱动的部分，能够保证自动化可测，即这两方面都完成的话，放到测试机上，就可以正常执行和测试了。但是如果用例集很大，执行环境复杂，人力执行显然不是好办法。成熟的自动化架构，必须考虑到测试机的执行和调度。
测试机管理中，一般可以分为测试机执行接口和代理——这两个词并不准确，我临时拿来用。
命令发送这个词同样不准确，因为在实体机的服务端和代理端，确实是以命令作为最小单元，但是如果是虚拟机，就不存在命令发送，而是虚拟机接口。
调度虚拟机，需要使用vmware提供的接口，流行语言都已经提供，或者可以自行调用dll完成。接口在WM安装路径的32bit\vix.dll中。官网有相关信息。
实体机的命令发送，是我说的真正的命令发送，无论服务和代理之间采用任何形式通信，执行一条命令是最基本的颗粒。最小颗粒之上，是定义各种需要的命令。
代理是调度驱动的核心，一般情况下，实体机想要驱动，必须保持双向联通。一起单项的命令模式也能驱动，但是这是不完善的，没有回执和状态查询，就不能叫做调度和代理。
虚拟测试机一样需要代理通信——一个服务器资源有限，即便虚拟30多台测试机，有时候同样不够用。这时候可能有很多台服务器提供虚拟机，那么每台服务上必须有自己的代理，服务和服务器通信，并且管理它的所有虚拟机。
通常，代理会选用socket进行通信，服务端管理多个代理，这是通信的最常用技术。
但是一些时候也会选择直接使用http通信，每个client端管理一个web服务，这种情况比较少。
对于有些特殊情况，比如需要重启或者重装系统的情况，需要代理的client端失去联系后反Ping服务端，重新恢复session。
一个比较久远的面相对象的中间件平台，可以借助ICE定义自己的接口，最终完成代理通信和调用。
简单的说，googleprotoBuf是谷歌的一种数据交换格式，更确切的说，是一种可扩展的序列化结构数据格式，可以用来存储，RPC或者等数据通信。对于通信调用，可以借助这种格式进行传输和临时存储。
Mina在这里，是一个重量级的东西。因为上面ICE和googleprotobug的内容它都包含。它的根本是一个通信应用框架，提供了协议的封装，流和管道机制，同步和异步等。和ICE一样也提供了server和client的封装。在考虑写代理的时候，可以优先选择。缺点是只能用java来写。
WTT是微软内部一直使用的一个测试机任务派发调度系统，它是基于命令的，同时采取了反ping技术，所以一些断网和删除驱动的测试，一样可以胜任。这是我觉得任务派发的调度的一个比较好的系统，并且支持定时任务和派发模板的创建，通过配置几乎可以完成任何测试调度的任务。只可惜是个内部的东东，而且太大了，一般的测试团队很难开发和维护。
相对来说，微软的另一个主推的测试生态平台MTM和Auto Lib，并不是很好，很难和流行的QC等系统比较。主要愿意是它勉强和VS的搞到了一起，而且很多设计在根本上没有考虑到扩展和模板的概念。另外，作为一个平台，它寄生在VS的生态环境，使得性能无法提高。
调度分配在执行调度中，是一个可大可小的东西。一般在自动化架构开发初期不怎么去考虑。但是如果自动化架构稳定之后，可能会有一些分配上的需求，包括平均，动态以及一些特殊的需求。通常分配策略使用插合的方式，可以一种策略对应一个对象，也可以所有策略对应工厂类，或者使用纯算法的方式完成。
平均模式一般将M个用例分到N台机器上执行，即使能够监控测试机状态，也没办法对已经分法出去的任务进行异常处理
动态分配是一种相对较优的办法，它通常会轮询测试机，有空闲则分配测试任务。它不会因为某个任务异常或者测试机异常而卡住。但是由于轮询都需要计算，所以分发计算上效率差一些。
无论任何任务队列也好，调度池也好，各种说法等等，在分配策略中，事实上只有任务集合和测试机集合。再没有其他约束条件的情况下，即所有任务级别一样，所以测试机级别一样，它的调度会有一个折中的动态方法，在动态分配的基础上，定义每次分发的最小单元。在动态的同时保证了计算效率。
这里的特殊需求，指的特殊的任务级别和特定测试机环境。这里一些有效的方法就是聚成，重排和过滤。无论是任务和测试机，都可以分成各种集合和子集合，在执行的时候，可以才去节点为参数进行任务的下发，满足特殊需求；如果用例和测试机的命令有约束，也可以采取过滤的方法，制定好过滤规则。另外在任务队列里，会涉及到一些局部排序方法，这些可能要具体 情况具体考虑。
日志是一个测试架构必须的部分，可以几乎任何部分都要涉及到日志。当然除了通常的一般日志，还有一些特定的日志，他们可以用来定位测试用例失败点等等。
调试日志通常放在执行目录下，无论调度服务还是测试用例在测试机上的执行。一般来说，调度服务的日志只需要记录具体关注的问题即可，但是在测试机中执行的测试用例，其日志需要和用例执行步骤一一对应。这部分 建议是，如果用例顺序执行，则顺序记录日志，如果递归执行，则递归格式记录日志。日志的内容可以包括和用例一一对应的信息，以及执行的具体山下文环境，和运行时状态。
通常，测试日志分为两部分，一部分测试结果在运行时存入数据库，这也是最终查看测试执行结果的数据源。当时一些调试信息日志，没必要放在数据库，而且也不便于调试，一般来说这部分日志在用例执行结束后，会按照具体执行ID放入到固定的共享文件夹。测试人员调研和调试测试用例的时候，这些都是重要的东西。另外，放到共享文件夹的调试日志，最好也包含用例执行步骤和结果，因为一些断网的情况下，无法保证数据库的连通，但是却希望得到执行的正常结果。
执行结果一般是以步骤为最小粒度，存放在数据库。当然本地日志中也最好有一份，如上面所提到的。
失败截图是日志的重要组成部分，对于将截图放在日志的共享文件夹目录下，是没有太多异议的，一般来说，这部分的异议是是否应该将失败截图保存到数据库中。个人建议这个看情况，但是一般保存到数据库中也没有什么不好，如果不需要在数据库读取的话，是个备份，如果读取的话，可以整合到一些前台页面中。这里唯一需要注意的是，如果将失败截图存放到数据库，那么，那么千万别使用select * from XXX的这种方式进行读取，不然你的数据库服务器内存再大也承受不住。
录像没有太多争议的放在了文件共享系统中进行保存，毕竟它太大了，也没有太多页面显示的必要，反而不如在文件系统查看方便。
录像这部分需要注意的是，很多时候录像可以和失败日志集成到一起，通过失败日志进行索引的定位，然后点击录像查看。一些流行的测试框架也提供了这类的日志和录像的查看工具。
存储主要是用来查看的，之前也提到了主要分为数据库存储和文件系统存储，他们适合存不同的东西。数据库一般存数据性较强的东西，比如执行结果，任务参数等，结构化并且永远存储；文件系统适合放大容量并且经常读取的日志。
大需求的前提下，这种逻辑很少有人使用nosql来存储数据，毕竟一个整体的自动化架构逻辑和业务很清晰，而且关系型数据库也能够胜任。
一般推荐这种情况下使用关系型数据库，第一是选择比较多，适合存放大量的结构化数据，而且关系型数据库比较容易，真的出现什么问题，很方便的找到解决方案。
非关系型数据库的优点是快，比较适合一些小项目和互联网传输等，而且数据的对象化更加容易。但是非关系型数据库我并不建议——可能会有更多的成本，比如自己去写事务，写同步异步和处理锁等，而且性能如何也都是 问题，nosql的数据库相对来说，对内存的依赖更多一些，这种情况不适合一些测试数据的存储。
文件系统存放日志一般没有太深技术性的东西，只有一些小技巧的东西，比如尽可能使用文件拷贝的方式而不是网络通信的方式传输，也可以做一些盘符映射直接使用远程文件，而不是拷贝。等等这样的小技巧。
这部分主要是用户如何查看，制定和执行相关的自动化测试。之前提到过一些架构环境，可以通过web或者客户端进行任务下发，或者通过定时任务进行。另一方面，具体的结果的数据如何查看等等，也都是提供给使用者的外部接口。
无论client还是web，最终都需要核心的控制服务，它的功能主要是两大部分，一个是任务下发，另一个结果查询，当然还有其他一些数据配置等等的功能。总体来说，就是将之前的这些调度和数据库服务器形成有机的一个环境的过程。
前端无论是从操作还是查看的角度，至少都需要涉及到如下的部分
可以下发测试任务，也可以查看任务历史记录和详细结果；
可以编辑和创建测试用例，查询并且管理用例套件，能产看用例测试历史记录和结果；
能够编写用例过程，能够统计出具体过程的执行状态和数据等等；
报告一般是通过数据库中的数据，整合最终报告逻辑，按照报告的模板生成的具体测试执行结果信息汇总。一般情况下，会以文件形式存在。格式中，采用最多的是html和word，有些是直接生成的，有些是预览后导出的。
消息通知，一般都是报告完成后配合报告将测试结果发送到负责人邮箱的，通常这种时候会带着一些汇总的数据信息作为邮箱的主要内容，将其制成html格式的报表，然后发送邮件，详细的模板可以作为附件使用。
当然，消息通知机制不限于邮件，也不限于执行的结果汇报，决定关键的任何事件都可以触发通知，短信甚至以后的电话提示都是可以的。
客户端GUI测试技术和自动化测试架构设计简谈,布布扣,bubuko.com
标签：style blog java http tar ext
原文地址：http://www.cnblogs.com/wiki-royzhang/p/3785033.html
