如何搭建自己的自动化测试框架

1、如何搭建自己的自动化测试框架这段时间一直在为公司内部开发自动化测试框架，简称GTF5因为这个框架现在还属于开发阶段，很多事都是言之过早。我会持续将我在架构过程中的 想法写下来。供自己和大家一起分享。这些想法，并不属于我一个人，我工作中的同事们给了我很大的帮助。今天这一篇主要说明架构方面的考虑。在现有的提供自动化测试解决方案的产品很多，包括:Robot，TestComplete, WinRunner等等。我只接触过这些，公司里也进行过很大的尝 试，但是结果往往总是不竟如人意。这中间，排除那些人员方面的原因，也总结这些自动化工具，在使用过程中的不方便的地方:1 . 定位控件不方便。标准控件还好，非

2、标准控件就只能靠很多非正常方法去 获取。而且，控件的识别往往和界面布局相关。2 .验证数据不方便。这点更是针对非标准控件（什么?你不用非标准控件?），数据的检测，甚至夸张到使用图片检测。3 .代码维护不方便。由于在编写过程中，大量的和界面相关的代码，导致后 在需求变更的时候，代码的维护，成为软件测试人员的负担。针对这些情况，我们经过讨论，何不自己做一个软件测试框架。当然了，这是基于我们的丰富的知识积累的决策。大家不需要关心这个决策的情况。不 过，可以多关注一些我们在做的过程中的分析结果。通过分析流行的软件测试框架，有多种方式、典型的就是消息驱动，自动化工具通过脚本录制和编写，保存为测试脚本。在

3、回放的过程中，将这些脚本转换成为 Windows 消息，发送给我们应用程序的窗体和各种控件。这种方式的好处在于，自动化工具和应用程序之间能够做到完全的隔离。但是，由于使用了 Windows 消息，它也拥有了一个非常致命的缺点。那就是消息队列的异步性与程序的顺序性之间的矛盾。很多消息发送给了应用程序，但是应用程序的处理可能已经和消息队列错位了。有一些关于代码的时间片等待，就是因为这个问题。另外，就是由于完全的隔离，对于操纵控件数据的能力大大降低。毕竟，拥有大量数据的控件都不是标准控件。第二、嵌入式。TestComplete就是这类工具。它有支持不同语言的版本。大概思路，就是在程序编译的时候，注入

4、自己的控件代理。脚本的回放，直接可以通过代理，操纵到应用程序。可惜的是，这类软件开发的时候，更多的是考虑平台的兼容性。对于特有平台上的支持不是十分完美。特别是对自定义控件（比如Delphi中，除了 VCL的标准控件）支持也没有做到。不过，我这里必须承认，TC 的内部实现机制可能十分强大，我不能窥探所有。如果有人清晰，可以指点一二。针对上面的两种，我们想到的第三种方式:一体式。这种方式中，通过给程序在打包的过程中，添加额外的框架代码，使得程序自动提供控件的访问方式。自动化的模块也会作为软件测试程序的一部分运行。应用程序在执行脚本的时候，自动通过脚本，控制各控件界面的显示和关 闭。它应该是第二种方式的变种。但是由于是自己实现的，所以在对各类自定义控件支持的都非常好。针对一开始提出的几个自动化测试的难题，我们提出了，自动封装窗体上所有控件的概念（这些概念后面会详细介绍），对于软件测试人员，只要关心真正的业务操作流程。而业务流程中涉及到的控件，已经为他们自动提供好。这样，脚本也自然只成了业务流程的脚本。其复杂度也就大大降下来了。按照这个思路，主要的是可以充分发挥 “程序是我们自己的 ” 的优势，对于测试人员