【IT168 技术文档】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这样的方法支持树状控件的展开等。

　　关于MSAA和UI自动化的更多渊源，MSAA设计理念，现状和缺陷，可以参考微软早期的一篇名为What is UI Automation的文章。

　　UIAutomation和WPF

　　UIAutomation是微软从Windows Vista开始推出的一套全新UI自动化测试技术， 简称UIA。在最新的Windows SDK中，UIA和MSAA等其它支持UI自动化技术的组件放在一起发布，叫做Windows Automation API。

　　和前面的介绍相比，我倾向于认为UIA是一项自动化测试“技术”，而MSAA和Win32 API只是实现自动化测试的两种“方法”。这里区分“技术”和 “方法”的原因是， 一项“技术”往往有独立的模型，体贴的开发接口，用来专门解决某一类的问题，同时允许不同的实现细节。UIA可以被看作“技术”，是因为：

　　UIA定义了全新的、针对UI自动化的接口和模式。 分别是支持对UI元素进行遍历和条件化查询的TreeWalker/FindAll。定义了读写UI元素属性的UIA Property， 包括Name、 ID、Type、ClassName、Location、 Visibility等等。定义了UI元素行为的UIA Pattern， 比如Select、Expand、Resize、 Check、Value等等。 还引入了UIA Event接口，可以让测试程序在某些事件发生后得到通知，比如新窗口打开事件等。

　　以往的Win32和MSAA 设计出发点并不是为解决UI自动化。Win32旨在提供的通用开发接口， MSAA旨在提供程序的多种访问方式。相反，UIA的设计目的，以及新引入的模式和接口都完全是针对UI自动化测试的。

　　在后面的文章中我们会详细分析UIA的内部实现。可以看到，UIA这一套接口和模式，可以在不同平台，不同开发工具中实现和使用。其内部实现方式也因地制宜， 前后的兼容性都照顾得很好。 同时，UIA提供了托管的和非托管两种API，这些都是Win32和MSAA无法比拟的。

　　下面一段简单的C#代码演示了如何使用UIA测试Windows自带计算器完成计算3+5-2的操作(下述代码可能需要修改以适应不同Windows版本的calc.exe程序。本代码使用Visual Studio 2008针对Windows 2008 Server R2 English 编写)

　　UIA的优势

　　UIA的优势非常明显,主要包括以下几点:

　　1. 适应不同类型的UI程序，包括Win32、WinForm、 WPF和Silverlight。 由于WPF和Silverlight中的子窗口和控件并不是传统的HWND，所以Win32 API和MSAA无能为力。 而UIA可以直接支持这两种程序。

　　2. 兼容传统的Win32和MSAA模式。 前面提到过，UIA技术的内部实现可以多样化。 这一点在下一篇文章中会详细讨论。 UIA通过一项叫做UIA<->MSAA的桥技术， 针对传统程序， 可以在内部实现中借用MSAA的接口和直接调用Win32 API。这样不需要对控件或者程序的既有实现做任何改动， 就可以直接适用于UIA的新模式。

　　3. 新引入的TreeWalker、UIA Event、Pattern、 Property模式易于使用，贴合自动化测试。这些模式高度抽象了各种UI自动化测试的需求，同时又不和传统模式相冲突。比如执行点击按钮操作， 传统方法要么模拟鼠标键盘操作，要么发送Windows Message，而Message还分为WM_COMMAND或者WM_BUTTONDOWN。 而通过UIA Pattern， 统一归类于Invoke接口，这个接口对于测试者来说就统一了。无论是Win32、 WPF还是Silverlight按钮，都可以通过统一接口执行， 从而把具体实现隔离开。同时， 调用者若希望继续沿用键盘鼠标模拟，仍旧可以通过SendKey加上UIA获取坐标的方法实现。而UIA Event和对UI元素支持条件化区域化搜索，更是极大简化了测试人员的工作。

　　4. 提供托管的和非托管接口， 方便各种工具的开发人员。 同时提供了简洁方便的方式支持UI程序和控件开发人员扩展，自定义UIA的实现。比如通过AutomationPeer来扩展 基于WPF的控件， 通过实现简单的IRawElementProviderSimple来扩展基于WinForm的控件等。具体细节在下一篇文章中会详细介绍。

　　5. 针对WPF程序，除了支持基本的端对端(End to End)UI自动化以外，还支持基于AutomationPeer的单元测试。具体例子可以参考UI Automation in Silverlight - Simulating User Interactions

　　6. 提供了完善的工具、文档、开发包、例子程序等。比如通过UI Spy(图三)获取任意窗口或者元素的UIA信息。

　　图三：UI Spy

　　自动化技术和自动化框架

　　前面提到了UIA作为全新UI自动化测试技术的优势，但这并不能解决所有的UI 自动化问题。 自动化框架正是为了自动化技术没有完全解决的问题。比如：

　　1. 自动化中的同步和等待。 对于稍复杂的UI 程序，测试程序往往需要根据测试目标的状态决定 下一步的操作。 比如测试文件另存为功能的时候，若保存路径是网络路径，可能会因为网络延迟导致整个UI停顿比较长的时间。这个时候测试，程序如果不顾当前状态而简单地执行下一步操作，比如新建文件， 很可能会因为UI延迟而失败。 正确的做法是，测试程序应该等待文件保存成功返回后，再进行下一步操作。 这就是自动化中同步和等待的一个例子。实现同步和等待有多种方法，最简单粗暴的做法是硬编码一个长时间的 Sleep在测试代码中。 稍微好一点的做法可以采取小时间片的轮询状态检查， 或者反复重试。 借助 UIA的Event Pattern，可以尝试捕获另存为窗口的关闭WindowClosedEvent。 如果要做得完善一点， 可以把多种方法结合， 另外再额外检查目标程序的CPU使用情况，消息循环是否有回应，设定超时时间等等。

　　2. 冗繁的编码过程。 对于一个UI窗口，里面可能有几十个子控件或者子窗口。 在编写测试代码的时候， 如果对这些子元素的获取，操作不能简化， 势必导致代码冗繁，难以维护。 借助自动代码生成和ORM (Object Role Modeling)等技术， 可以解决这个问题。 比如可以用工具把窗口及其子元素的关系和搜索条件都序列化到XML文件中， 然后采用ORM技术即可在代码中轻松获取子元素。

　　3. 多语言和本地化测试。多语言和本地化的测试对UI来说显得尤为重要。 UI程序往往通过资源文件来定义所显示的内容， 这就要求自动化测试要可以方便读取和定位程序的资源文件， 来支持多语言和本地化测试。

　　4. 支持工具和辅助函数的匮乏。 对于大的项目研发， 通过好的工具来减小开发成本是非常必要的。 就UI自动化来说， 如果自动化测试用例可以通过一次录制，多次播放来做的话，成本会减少很多。 在VS2010中就提供了这样的录制-播放功能。 详细视频可以参考How to create record and playback Test Cases in Visual Studio Beta2。

　　5. 区分功能性测试和用户真实行为模拟。 前面提到， 就点击按钮功能来说， 可以通过SendKey来模拟鼠标操作， 或者通过Windows Message来直接触发点击事件。 这两种不同方法各有优劣。 比如当按钮被其它元素遮挡， 通过SendKey进行模拟就会导致失败，而直接发送Windows Message还是会成功。 孰优孰劣取决于要达到的目的。 如果单纯为了测试按钮点击后导致的结果，通过Windows Message来模拟就省去了很多麻烦。 相反， 如果是界面测试， 通过SendKey来模拟就可以让按钮被遮挡的bug暴露出来， 而Windows Message则不能发现这样的问题。

　　所以，单纯的某个自动化技术或者方法也无法满足需求。为了解决上述问题，各种自动化测试框架逐渐涌现和发展。微软内部有多个不同的自动化框架，设计理念和侧重点各有不同。 Visual Studio 2010将加入对自动化测试的支持。 在CodePlex上面， 也可以找到多种框架，比如White和UI Automation Verify。