Windows UI自动化 WIn32API以及MSAA
Windows平台的桌面开发技术， 从最原始的Win32 SDK，发展到.NET WinForm，一直到今天的WPF和Silverlight， 发生了翻天覆地的变化，相对应的UI自动化测试技术，也随之演变。
微软UI自动化技术揭秘将分两个部分介绍Windows平台桌面程序的自动化技术。上篇将介绍从Win32 SDK至今的UI自动化技术演变，下篇将着重介绍最新的UI Automation(UIA)的内部实现和使用技巧。
自动测试是指用一个程序自动地控制另外一个程序，模拟用户的操作进行测试。通常自动化测试涉及到下面三个步骤：
测试源侦测
测试源侦测是定位测试目标元素的过程。比如要测试Windows附件中的计算器，首先要把计算器窗口和其他程序比如写字板区分开。进一步测试计算器窗口菜单的时候，需要首先定位菜单条的位置，获取第二层子菜单等等。简单地说，自动化测试首先要能够获取从桌面开始的整个UI树结构，定位到特定测试目标。
用户行为模拟
用户行为模拟指模拟用户的输入，比如鼠标、键盘和触摸笔的操作，中间可能会涉及IME输入法、组合键、特定用户习惯，比如输入速度的模拟等。
测试目标检查
指获取测试元素的属性，比如读取窗口标题， Listbox的子元素， Checkbox的状态等等，以便进行测试检查。
Win32 SDK和Windows Message
在.NET问世以前，Windows平台上的UI程序无外乎两种技术：Win32 Windows SDK 或者DirectX。由于DirectX多用于专业领域如游戏和CAD，本文并不讨论。
无论是MFC，VCL还是VB6，Win32 SDK都是其根本，最终打交道的其实都是HWND和Windows Message。实现上述自动化的三个步骤 无外乎三件法宝，Win32 API，Windows Message和Windows Hook。
测试程序首先通过 FindWindowEx和EnumWindow遍历窗口和子窗口， 找到测试元素比如某个按钮，然后可以通过Windows Message或者API检查测试目标。比如通过WM_GETTEXT或者GetWindowText读取窗口标题，通过GetWindowRect读取按钮坐标位置等等。对于用户行为模拟，可以直接通过SendKey API来完成，当然也可以发送WM_CHAR或者WM_KEYDOWN通知等等。
除此以外，Windows Hook更加丰富了技术的选取。通过Windows Hook，测试人员还可以直接监控、 截取、模拟目标程序的Windows消息，实现更灵活的模拟，检查甚至录制的功能。
Windows Spy++（图一）虽然不是测试工具，也算是使用这套技术的典型例子。通过Windows Spy++可以定位任意窗口， 读取窗口属性，监视窗口消息等等。
图一： Microsoft Spy++
采用Win32 SDK和Windows Message的优点是直接，灵活。由于直接使用Win32 API，没有额外的学习曲线，遇上问题可以直接参考Win32 SDK解决。使用Message Hook使得测试程序可以灵活实现，直接对Window Message的操作不仅可以把很多情况化繁为简，还方便test hook的实现。（所谓test hook，是指产品中为了方便测试而专门设计的隐藏功能，该功能对普通用户不可见，只是为了方便测试。）
缺点包括以下三个方面：
使用复杂，实现成本高。Win32 AP的使用上有很多需要特别注意的细节， 比如有的Win32 API不能跨进程工作，有的Windows Message只能发给当前线程所创建的窗口，稍有不慎，就导致测试程序不稳定。
过于底层，不便使用。为了方便测试用例调用，需要对API进行封装，增加了实现成本。同时 Win32 API的也使得很多VB程序员不便调用。再者， 不同的开发工具，比如MFC， VCL，以及后来的.NET Framework，在内部实现上对Win32 API有很多细节的处理， 要实现出针对各种情况都通用的测试框架，并非易事。比如， .NET 中的WinForm Control对Win32 HWND的维护是动态的，同一个WinForm Control的HWND在程序的生命周期内是可能发生改变的，这一点对于依赖HWND作为唯一标识的Win32 API就是一个致命伤。
无法操作自绘窗口。比如打开Excel的工作表，会发现表格中的每一个Cell并没有对应到HWND上。Excel的cell都是通过代码绘制，而不是依赖于现成的Win32 Control。这就使得Win32 API对于自绘窗口没有用武之地。
MSAA
MSAA的全称是Microsoft Active Accessibility。这是类似DCOM技术。技术模型是这样的，UI程序可以暴露出一个Interface，方便另一个程序对其进行控制。MSAA技术的初衷是为了方便残疾人使用Windows 程序。比如盲人看不到窗口，但是盲人可以通过一个USB读屏器连接到电脑上， 读屏器通过UI程序暴露出来的这个Interface，就可以获取程序信息，通过盲文或者其它形式传递给盲人。
MSAA提供了如此方便的功能， UI自动化测试自然可以借用这项技术。MSAA暴露出来的Interface叫做IAccessible。测试程序和目标UI程序互操作流程如下：
1. 测试程序调用Windows API： AccessibleObjectFromWindow，传入目标UI程序HWND。
2. AccessibleObjectFromWindow函数向UI程序发送WM_GETOBJECT消息。
3. UI程序创建实现了IAccessible的内部类，然后通过LresultFromObject API把IAccessible 接口返回给测试程序。
4. 测试程序拿到IAccessible接口，开始调用IAccessible接口函数操作测试目标。
IAccessible接口里面的几个关键函数是：
- IAccessible::get_accChild/ IAccessible::get_accParent通过这两个函数，调用者可以浏览目标程序的窗口关系树，定位到UI元素。
- IAccessible::accLocation/I Accessible::accHitTest读取和分辨目标元素的屏幕位置。
- IAccessible::accName/ I Accessible:: accSelect读取元素的名字，对UI元素进行指定的操作，比如选取Listbox里面的某一项等等。
- IAccessible::accValue 开发人员可以自定义value属性的实现。比如针对折线图控件，开发人员可以在accValue中返回折线的坐标数列。
MSAA的理念类似于test hook。 通过主动让UI程序暴露一个接口来让调用者控制。在具体使用中，测试人员往往是结合MSAA和Win32 API操作，取长补短。一方面对于UI元素丰富的属性，比如style，钩选状态，是否最大化和模拟用户输入等，继续采用Win32 API。另一方面用MSAA的优势来弥补Win32 API的一些不足，比如：
由于MSAA有自己的get_accChild方法，使其控件树关系并不一定要和Win32 HWNDd关系对应一致。对于自绘窗口，虽然说只有一个HWND，但是开发人员可以通过实现IAccessible接口来实现逻辑上的层次关系。比如Excel中就可以通过IAccessible把多个cell的子IAccessible接口暴露给调用者。
IAccessible的实现是由开发者提供，开发者可以灵活地根据实际情况决定方法的实现。比如前面提到了折线图控件可以返回坐标数列。对于.NET WinForm， 微软在Framework中就提供了IAccessible的默认实现，这样在具体实现中，就可以处理.NET动态维护HWND的细节等等。
针对MSAA的工具也有很多，比如AccExplorer（图二）可以像Spy++一样对指定程序进行控件的树形浏览，检查MSAA属性等。
图二： AccExplorer
如果您是开发人员， 对于unmanaged UI程序的MSAA实现，参考MSDN中关于WM_GETOBJECT的说明返回IAccessible interface就可以了。对于managed程序， 实现方法更简单， 现成的例子可以参考：
- Control..::.ControlAccessibleObject Class
- How to create accessible controls by using Visual Basic .NET or Visual Basic 2005
对于测试程序如何直接获取并使用IAccessible接口，并非本系列重点，所以并不提供更多介绍。在后面的文章中， 会介绍如何隐含使用IAccessible和MSAA。
MSAA也有自身的缺点：
1. 虽然说MSAA基于COM技术， 但IAccessible并不是一个COM标准接口。 比如使用者不需要调用CoInitialize即可使用，也无法通过QueryInterface进一步获取更多的自定义接口。这局限了MSAA所能提供的功能。
2. IAccessible接口的定义有缺陷。里面不少方法是可有可无的，但是又缺少一些支持UI自动化的关键方法。 比如它提供了accSelect支持控件的选取，但是却没有类似accExpand这样的方法支持树状控件的展开等。