摘要：针对目前市场上软件自动化测试的主流工具，不能实现基于非标准Windows控件开发的软件的自动化测试，本文提出了使用Rational Robot外挂辅助自动化测试DLL，通过Windows消息机制，实现对被测试应用程序的控制，从而实现自动化测试的一套可行的实施方案，为广大自动化测试爱好者，提供参考思路。
关键字：外挂DLL；Windows消息机制；非Windows标准控件；自动化测试
一、 前言
随着计算机软件产业的飞速发展，软件产商采用了各种开发模式来提高开发速度，比如说叠代开发，代码重用等技术，使得软件开发的速度大大地提高。同时，给软件质量保证人员带来了非常巨大的挑战。
在一些发达国家，软件测试人员与开发人员的比例会达到1：1，或者1：2，而在我们国内，虽然很多人已经认识到软件质量的重要性，有些大企业成立了专门的测试部门，但是传统的重视开发而轻视测试的思想依然占据主导地位。软件测试人员与开发人员的比例依然非常低。我就职的软件企业是一家著名的跨国软件企业，公司上层已经非常重视软件质量了，可是这个比例也只能达到1：5，甚至只有1：7。对于其他国内一般的软件企业来说，测试人员与开发人员比例之低就不言而喻了。
随之而来有个问题我想问，这么繁重的测试任务单纯地依靠手工测试能行吗？回答是否定的，我们需要采用自动化方式替代一部分的手工测试。
在实现自动化测试的过程中，我们曾遇到过有些控件根本无法被自动化测试工具识别，当然对它的操作更加是无从谈起。那我们公司所开发的软件来说吧，为了使软件界面更加美观，风格更加统一，公司专门成立了一个部门，开发了一种软件界面的设计工具，对Windows标准控件进行二次开发并封装。对于这样的控件,Rational Robot是没有办法控制的。
因为公司测试的需要，我对基于非Windows标准控件开发的软件实现自动化测试进行了比较深入的探索。琢磨出了一套方法想跟大家一起分享。那就是使用Rational Robot工具外挂Dll,结合Windows操作系统中的消息机制的方式，实现对非Windows标准控件的识别和控制。
二、 自动化测试工程的整体架构
这套实现对非Windows标准控件开发的软件自动化测试工程，采用三层架构方式，Rational Robot层，外挂DLL层，被测应用程序层。为了能够清晰地说明它们之间的关系，我想使用一个图来说明。如下图：
Rational Robot层的主要工作是根据测试的需求，控制测试的过程，管理测试的检查点，编写测试代码，执行测试脚本，最后生成测试结果报告。
外挂DLL层，负责Rational Robot与被测试应用程序之间的通信，接收Rational Robot发送的指令信息，再将这些指令信息发送给被测试应用程序端接收该消息的DLL。应用程序端的DLL，根据接收到的消息，完成对被测试应用程序的操作后，将消息发送给外挂在Rational Robot端的DLL。这样一个来回完成Rational Robot与被测试应用程序之间的通信。
被测试应用程序层接收到辅助自动化测试的DLL发送过来的消息，完成测试人员预先设定好的操作步骤，完成对被测试应用程序的测试任务。
三、 系统的通信方式
使用Rational Robot自动化测试工具,把被测试的应用程序运行起来,我们可以通过进程监控工具查看,它们是属于父子进程关系。父子进程，也是两个独立的进程。那么运行在Rational Robot进程中的DLL，是不能够直接操作被测试应用程序的进程的。我们怎么办呢？
如果对Windows操作系统比较深入了解的人会知道，Windows操作系统提供一种消息机制，它可以实现不同进程空间的信息共享。如果能够把这种技术应用于自动化测试过程中，是否能行得通？
基于这样的思路，我们在Rational Robot端放置一个DLL，同时在被测试的应用程序端也放置一个辅助自动化测试的DLL。放置在被测试应用程序端的DLL要它不会对被测试应用程序本身造成任何影响，被测试应用程序不会因为辅助自动化测试的DLL，而改变其控制的流程以及需要实现的具体功能。因此，我们采用当被测试应用程序在启动的时候，就把辅助自动化测试的DLL导入进来。就在这个地方增加几行代码，其他方面，被测试应用程序不再做任何的改动。
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
