Windows自动化UIA
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。
