不能回避的历史
Windows界面自动化技术的演进和Windows界面技术以及Windows操作系统的发展是密不可分的。2002年在学校第一次接触C语言编程，只能用C写教科书里很枯燥范围的排序算法和诸如printf的命令行输出，那时还不流行搜索，那时XP系统已经成为最一代的图形界面操作系统，那时学校的机房大多还装着2000或者98，那时QQ的用户正在成指数级增加，新用户申请的QQ号码已经排到9位数了，那时的大多数工科学生无法提起对C编程的兴趣，因为实在不知道除了排序还能用来做啥。后来偶然间知道用来用C能够调用Windows的API创建带菜单的图形界面窗口，后来又听说当时早期的QQ版本是用一种叫做Delphi的程序写的，而开发Delphi的那就公司就是曾经一度传奇的Borland，后来在非典的时候软磨硬泡老爸老妈终于磨来了人生第一个也是最贵的一个笔记本电脑，那时那款笔记本是我们班为数不多的笔记本，还记得它的型号是康柏商务系列EVO600，即使是水货价格还1万2千多，真是不菲（想想做父母真是不容易，再次感谢！），买了笔记本之后的第一件事就是考察怎么写类似的QQ的图形界面程序，于是VB6.0成了我学的第二门计算机语言，后来便是接触到了同时代微软的另一界面开发技术MFC，相比较VB的即拖即用式的便捷的开发模式，MFC在提供更高运行时性能的同时也更复杂和庞大,而到了2005-2006年做毕业设计的时候微软的新一代编程框架.NET已经成了各大IT论坛讨论的热点，后来发现.NET framework2.0提供的Winform界面（以及同时涵盖其中的Web开发技术ASP.NET）开发模型更强大，C#的面向对象编程用起来更得心应手，在开发大型系统应用时扩展性更好，效率更高，便逐渐成为更多Windows开发人员的首选， 后来便是Vista和.NET3.0的推出，Vsita虽然被证明是失败的产品，但是.NET3.0推出的最新一代界面开发技术WPF却被保留被发扬光大，WPF（Windows Foundation Presentation）通过类xml和html的格式化语言xaml来描述界面，在绘制界面直接通过DirectX进行渲染，不再使用Winform时期的GDI和GDI+技术，这种方式使得绘制出来的界面更绚烂多彩，渲染界面的效率因为直接调用硬件的接口效率也更高，为了推广WPF技术，微软最新的开发环境Visual Studio的界面号称就是基于WPF的杰作。而WPF这种通过xaml格式的语言来描绘文件的模式使得界面开发和后台业务处理逻辑的分开成为更容易的事情，由此界面的设计可以全权交给UI设计师完成，然后程序员把设计好的xaml拿来进行后台业务逻辑的开发。在最新一代的微软操作系统Win8中，其全新设计的Metro UI就是基于WPF的，这说明了什么，说明WPF已经深入新一代操作系统的灵魂深处（与此同时，同样基于xaml的Siverlight技术也深入了Windows Phone7的灵魂…）。
可以看出，界面开发技术越来越强大，越来越支持更多自定义控件的出现，支持更多控件属性和接口，这使得以前针对标准窗口和控件的自动化技术亟需改进。那么Windows自动化技术的前世今生大概是什么样的呢？
我们知道Windows就是基于消息机制的操作系统（不知道本书后面还会讲撒），操作系统将来自键盘鼠标之类外设的事件经过处理转化成Windows识别的消息传递给窗口和控件，然后由窗口和控件进行事件处理，如判断是单击还是双击，是左键还是右键等等。所以最早的Windows自动化技术是通过调用系统的API如FindWindow/FindWindowEx/EnumWindows等获取控件或者窗口的句柄，通过SendMessage，PinkMessage等函数向这些句柄发送消息实现模拟鼠标键盘操作，甚至借助钩子函数来进行进自动化，但是这种开发方式效率太低，封装的成本太高，涉及到太多系统底层的API调用，需要非常熟悉操作系统才能进行（本书后面会有章节剖析AutoIt等自动化工具的源码，会看到这些或多或少用到了该技术）。
之后微软推出的自动化技术便是MSAA（Microsoft Active Accessibility），MSAA是基于COM的通信方式，通过为控件和窗口（窗口也是控件的一种）实现IAccessible接口暴露控件的属性和信息（如文本框的文字，窗口的标题），自动化测试程序访问该接口获取控件的属性并进行操作。MSAA相对Windows API的方式更容易使用，不再需要周转于那些低级繁琐复杂的API，使得控件的树层次不一定非要对应于控件句柄的层次了，比如对于像Excel单元格这样的自绘制控件，可以为每个单元格实现IAccessible接口从来使得操作单个单元格成为可能，只使用Windows API则无法实现这样的功能（因为单元格并不是一个标准独立的控件）。MSAA技术使得大规模的介面自动化成为可行性选择，由此基于该技术也诞生了一批著名的商业自动化测试工具如QTP,SilkTest等等。
但是MSAA的缺点也随着Winform的出现而越来越明显。Winform的出现使得控件拥有更多的属性和接口，Winform也支持自定义更复杂的控件，而MSAA通过IAccessible接口暴漏出来的信息和操作接口是有限的，不能满足日益复杂的控件自动化需求，MSAA这一技术最早的定位其实并不是自动化，而是微软为了方便更多残障人士（色弱，盲人，聋哑人士等）使用其操作系统和程序而设计的，其最早的应用是放大镜，通过放大镜当鼠标移到按钮或者文本框上，放大镜会自动将鼠标定位的空间文本信息放大显示。
而WPF的出现使得MSAA的局限性更加突出，UIA便应用而生，从.NET3.0开始便包含了UIA类库，UIA从一开始的设计就是要从原生上支持WPF自动化以及完美支持Winform，当然从兼容性的角度考虑，UIA也通过代理的方式对那些老的实现了IAccessible接口的控件调用MSAA进行自动化，可以看出UIA基本上覆盖了所有的Windows界面结束的自动化需求，UIA通过provider和Control pattern的方式为控件实现自动化接口，通过这样的方式，对于用户自定义控件也很容易实现自己的自动化接口。UIA是基于.NET的技术，而C#这样的面向对象编程语言又为使用UIA进行自动化开发提供了更好的编程体验。
现在最新的Windows自动化开发技术统称为Windows Automation API3.0，是随着Win7的出现而出现，这个3.0说白了就是整合了MSAA和UIAutomation两种技术打了一个开发包，将二者放在一起从更高的级别来描述微软Windows未来界面自动化的愿景，而很明显UIAutomation终将成为无法抵挡的趋势。
当然，微软的界面开发技术也不仅仅只有MFC/VB6/Winform/WPF, 事实上有太多的工具和编程语言开发厂商都有自己的一套微软界面设计技术和框架，如Delphi，基于Java的SWT,Swing等等，那么继续这些技术的界面是否也能被MSAA或者UIA支持呢？这里我不会去做深入的研究，原因很简单，我们只需要关注MSAA和UIA的实现原理就可以判断其他的界面技术是否支持自动化了，比如要看SWT是否支持MSAA，只需要调研一下SWT的控件是否实现了IAcessible接口，而答案是Yes，这便意味着基于SWT技术实现的界面也支持MSAA和UIA进行自动化。当然多说一句，SWT控件更支持IBM的另一个自动化接口IAccessible2，这是一个跨平台的自动化接口（SWT本身就是跨平台的），所以在做SWT的自动化的时候可以考察一下看看有没有IBM的自动化工具包支持（IAccessible2不被MSAA支持）。