最近一段时间在搞c/s客户端的自动化测试。在中国的大部分企业，自动化测试刚刚起步，大部分人都认为会使用一些商业的或者开源的自动化测试工具，如QTP之类，就算是进行自动化测试了。大谬也！
自动化测试按照基本步骤来说，其实就分为两部分：1> 控件的自动化识别，2> 结果的自动化比较。至于大家熟悉的suite，自动化测试报告等部分，则是以以上两部分为基础封装起来的，属于易用部分，不属于基础部分。要进行自动化测试，就必须解决上面提高的两个基础部分，否则，只是缘木求鱼。
关于控件的自动化识别，对于标准控件，识别不成问题。所谓标准控件就是MFC开发UI界面时提供的那些控件，如文本输入框、列表等。对于标准控件组成的应用程序，进行自动化测试是很容易的，有现成的工具，如qtp，winrunner，test complete等，如果你不想花钱也不想用盗版的话，也可以自己开发一个工具，利用微软提供的windows api很容实现，基本上就是找到一个窗口的句柄然发送一些windows消息。
如果很不幸，你的应用程序所有的界面都是基于自绘的windows区域，在此情况下如果想进行自动化测试的话，只有一个很简单的方法：自动化测试在产品版本规划的时候就已经考虑了，并且已经预留了自动化的接口，这时你只要进行一些自动化接口的调用就可以很轻松的完成自动化测试了。如果开发人员根本知不知道这世界上还有自动化测试这个事情呢？呃，God，help~~这个时候进行自动化测试，你会发现，商业的自动化测试工具，针对你的操作录制的自动化脚本是一片空白，自己开发测试工具，你甚至连目标程序的window handle都找不到，只能找到一个主窗口的句柄。按照常规的自动化测试的方式，根本行不通。这个时候最好的方法就是去找开发人员，让在软件开发的同时加入对自动化测试的支持。但是如果非要在不麻烦产品开发人员的情况下支持自动化测试呢？嗯，那就要准备一把尺子和一个钻头了，准备尺子是要量每个控件相对于主窗口的相对坐标，准备钻头是要钻进程序的内部，看看软件到底是怎么工作的。尺子就是spy++,钻头就是windows api hook技术。简单的原理就是用鼠标键盘的方式来驱动软件的执行，然后hook住软件底层的api调用，根据api的返回值或者输出参数来判断操作是否成功。这需要对软件的源代码非常熟悉。
相关阅读：
