【这里的自动化测试专指GUI自动化（不包含Web）】
以前写过一篇跟UI自动化测试有关的技术，谈到了一个自动化测试工具必备的几个功能，而且也提到了Windows平台自动化测试工具所基于的一些技术。下边就说一下这些技术的比较和展望，同时也包含了一些纠结……
- Windows API
识别窗口：需要通过FindWindow和EnumWindows来查找到窗口句柄，然后再调用其它API(GetWindowText，GetWindowRect, GetWindowLong…)来获取窗口属性，以此来找到想要的控件（窗口）
操作窗口和获取属性：通过SetWindowText和GetWindowText来操作控件上显示的文字，通过SetForegroundWindow设置顶层窗口,GetForegroundWindow获取当前的顶层窗口，类似的还有GetActiveWindow和SetActiveWindow。其它操作就不一一列举了……从理论上来说，通过Windows API和Windows Message可以完成对大部分窗口（控件也是窗口，一起都是窗口）的操作，也可以获取部分控件的部分属性。但是缺点和优点也比较明显：
优点：就是看起来很高深很强大很底层，对标准Windows的控件支持还不错
缺点：底层意味着复杂，意味着需要多层的封装，意味着开发效率低下，也意味着对Windows API的完全依赖。如果碰到一个非标准（自定义控件），用这种方式实现的自动化工具基本上完全束手无策，即使有开发团队的支持也很难完成自动化。当然了，算坐标，甚至用全局坐标来做也可以做，但这是野蛮做法，自动化测试的代码非常不稳定，维护和分析结果的成本也很高。
总而言之，言而总之，没有哪个自动化测试工具完全用Windows API来实现……当然了，也不是说Windows API就没有用了，基本上所有的自动化工具都会或多或少，或直接或间接的调到Windows API，也没人敢说他不调一个Windows API就能做自动化测试工具的，最起码鼠标键盘消息的模拟他就没法弄…… - MSAA - Microsoft Active Accessibility
MSAA在1997年在Windows 95中就已经包含的技术，也许你没有听说过，但是在所有的标准控件中，都实现了MSAA的接口，在微软所有的操作系统中都集成了MSAA的组件，在这里，我就不讨论MSAA的历史和相关技术了，就啰嗦一点点感慨：MSAA天生就不是设计给自动化测试的，它存在的意义在于提供一套接口，让开发人员可以方便的给残疾人开发可以使用的软件，比如读屏程序（鼠标移动到按钮的时候，可以发出声音，辅助视力障碍的人操作电脑），从而实现微软将电脑普及到每一个家庭的梦想。
下面进入正题，虽然MSAA不是设计给自动化测试的，但是现有的所有自动化测试工具都是基于或者部分基于MSAA来实现的。MSAA很多时候直接把它叫做IAccessible，它本身是一个COM组件，最主要是实现了IAccessible的接口，它提供了一些方法，通过这些方法，可以获取控件更详细的信息，也可以通过一些方法对控件进行简单的操作（DoDefaultAction）。有兴趣的，可以参考Microsoft Active Accessibility
优点：比起Windows API来说，用户只需要跟IAccessible打交道，通过这个接口能获得的控件信息相对丰富很多，基本操作也不需要通过Windows Message的方式来实现。另外一个比较大的优点就是，自定义控件的支持，当然了，并不是说开发写一个自定义控件，这个控件就可以通过MSAA来识别，而是说当开发人员在实现自定义控件的时候，可以实现IAccessible的接口，并且通过这个接口，把一些的属性和操作暴露出来，测试人员就可以将这个控件当作标准控件，并通天优势了，但也需要开发人员的支持，或者有能力的测试人员也可以自己实现，这就是UIA中的两种Provider，一种内建，一种外置，只要实现了Provider，自定义控件就可以完美的支持UIA。当然了，对标准控件来说，UIAutomation发布在Win32控件和WinForm的控件之后，所以微软就帮我们实现好了对应这些控件的Client Provider，所以UIA对于以前的Win32和Winform控件也是完美支持的，对WPF的标准控件就更不用说了，天生就是带有Provider支持的。具体的我就不展开了，大家有兴趣可以看这个：UI Automation Providers Overview - Windows Automation API 3.0
这个并不是新的自动化测试的技术，而是对UIAutomation（UIA）以及MSAA的升级，更准确的说，是UIA SP1，但名字直接跳到3.0，不知道1.0和2.0是不是指的MSAA的版本，所以大家看到这个名字以后不要晕…… 顺便唠叨一下微软的东西，貌似某个人说过，微软的东西都是在没有做完的时候就发布出去，然后过一段儿时间马上发布Service Pack，所以微软的产品一定要等到SP1以后才能用，这个相当准确:) 更详细的介绍大家可以看这个Blog：Microsoft Windows UI Automation Blog
我在这里就大概说一下，Windows Automation API 3.0是伴随着Windows 7发布的，也就是说Windows 7本身就集成了Windows Automation API 3.0所以的组件和功能，再换一句话说就是Windows 7就自动化测试的支持将会更好。最主要的更新如下（与上边UIA的几个纠结对应）：
a. 更新以后，以前Tree断掉的问题基本上修复了，我在Windows 7上测试的结果来看，没发现问题
b. 新增了Unmanned API和COM API，这样直接用Native的C++也可以来开发基于UIA的自动化工具
c. 有了COM API以后，看起来In-Process也不是问题了
d. …
Windows Automation API 3.0看起来很美，基本上都解决了我上边说的UIA的问题，让人感觉到这个版本的UIA才是真正可以替代MSAA的东西。但是这个Windows Automation API也让我纠结了好一阵子，差一点就想放弃UIA，重新把Code转移到MSAA上，最主要的原因是，Windows Automation API 3.0只支持Windows 7，不能安装在XP/Vista上，后来经过和他们的斗争，有了下边的Update： http://social.msdn.microsoft.com/Forums/en-AU/windowsaccessibilityandautomation/thread/46e83c55-47b8-4874-9222-7ce2fa58751d
所以，对Windows Automation API 3.0的当前情况就是：
如果你仅仅在Windows 7 上做自动化测试，那么恭喜你，你可以使用Windows Automation API 3.0的所有功能，既可以用Managed code来做，也可以用Unmanaged code来做
如果你想在Vista上用，装了那个更新以后，应该就可以了，我没试过……
如果你想在XP/Server2003上使用，你需要等到今年年底的某个时候（快到了:)）
总之，在Windows 7上，怎么做都行（Managed/Unmanned），在XP/Vista/Server2003上，只能用.Net，而且还会碰到有些控件不在控件树上。所以，大家跟我一起期待年底的更新吧……
Note:
1. 多谢xiongli，推荐大家去看这篇文章，确实写的很精彩 http://eparg.spaces.live.com/blog/cns!59BFC22C0E7E1A76!4008.entry
2. 任何帮助都不如Spec写的明白，啥也不说了 UI Automation Community Promise Specification
转播
