基于WPF的UI自动化测试

转自 http://developer.51cto.com/art/200710/58469.htm

WPF强化了用户界面的自动化测试，使测试人员可以从繁琐的UI测试中解脱出来，将更多的精力用于更加底层的测试工作。

从Visual Studio2005开始，微软将测试集成到其开发工具中，从工具上保证了测试工作在软件生命周期中的重要地位。而从NET3.0的WPF开始，微软通过其UI的自动化支持，协助开发人员为界面元素建立自动化测试标识。

WPF的UI自动化技术

WPF为Windows桌面应用程序和WEB应用程序提供了一个智能客户端开发模型，以方便构建丰富统一的UI、媒体、图形图像、动画和文档等。一方面WPF可以促使开发人员更积极地参与到用户界面的开发，另一方面提升用户体验的满意度。

在传统的软件开发中，用户界面开发费工费时，并且跨越了表现层和技术层，使一般的程序员都苦恼不已。WPF则从技术层面上减轻了这种复杂性，提升了开发人员参与用户界面设计开发的积极性。

UI自动化对大多数用户界面元素提供可编程访问，即通过除标准输入输出 (比如键盘鼠标) 方式以外的方法操作UI。UI自动化核心层屏蔽不同框架技术下多种UI元素的差异，确保UI自动化客户应用程序能在多种框架技术下工作。比如，WPF按钮的内容(Content)属性，标准Win32按钮的标题(Caption)属性以及HTML页面上显示图像的替换文字(ALT)属性等都映射为WPF中UI自动化视图中单一的名字(Name)属性。藉此，一些辅助技术产品和自动化测试框架可获得其所需要的获取用户界面信息统一的程序化访问方法，此外，通过自动化的用户界面技术，应用开发商也可以提高其产品的易用性。

UI自动化模型

现有技术下实现UI自动化测试系统开发需要通过不同方法获得和展现UI元素信息，开发人员需要花费大量的时间和精力去搜集这些必需的UI元素信息，而不能集中精力于系统特征和功能的实现上。借助于WPF的UI自动化所提供的统一的控制模式，通过其等价的名字属性 (NameProperty) 就可以轻松实现对不同UI元素的统一控制。UI自动化技术减少了此类应用系统的开发成本，将成为下一代辅助访问技术产品和自动化测试系统主要的界面信息资源提供者。

UI自动化包括两部分。UI自动化服务提供者 (UI Automation Providers) 和UI自动化客户程序 (UI Automation Clients) 。UI自动化服务提供者是提供UI自动化服务的应用程序，比如Word, Excel及其它基于Windows的应用程序 等，为用户通过辅助程序技术对其访问提供支持。UI自动化客户端程序是实现用户界面自动化访问的辅助技术程序，比如Word和Excel中供应用程序访问的对象模型及其宏脚本等。相应的，对开发人员来说，可以通过调用UI自动化提供者应用程序接口(UI Automation Providers API)创建用户界面控制元素，也可以通过调用UI自动化客户端应用程序接口(UI Automation Clients API)创建应用程序，通过UI自动化核心层与UI自动化界面控制元素进行通讯。

UI自动化通过把界面上一个个的UI元素作为自动化元素 (AutomationElement)暴露给客户端应用程序供其调用。所有UI自动化元素组成以桌面(Desktop)为根节点的树型层次结构，树状结构包含所有正在运行的应用程序，每一个正在运行的应用程序都是这个根的子节点，其每一个可能与用户进行互动的界面元素都是一系列层次化的自动化元素(AutomationElement)。树型层次结构通过原始视图(Raw View) 的形式展现给客户端，客户端可以通过过滤自动化元素树的原始视图 (Raw View) ，得到控制项视图 (Control View) 和内容项视图 (Content View) 。 NET3.0提供UI 探测程序UISpy.exe供开发人员调用以察看UI自动化元素视图。

自动化元素 ( AutomationElement)对象包括UI元素在界面上所呈现的两类共有属性。一个是控制类型属性(Control Type)，控制类型属性定义界面元素的基本表现形式和功能，并以此作为单一的识别实体。比如，按钮Button类型或者多选框Check Box类型。一个是控制模式(Control Patterns)，控制模式提供一个统一的方法来构建和表达控制类型所拥有的功能。比如，可以对拥有被调用功能的控制类型比如按钮Button类型使用调用模式，对编辑类控制类型使用文本模式等。控制模式通过公开方法调用使客户端得到界面元素进一步的详细信息并提供输入。微软鉴别出18种控制模式，通过这18种控制模式可以展现出任何类UI元素及其任意组合所能实现的所有事情。

注意，控制类型和控制模式之间并不是一一对应的关系。一个控制模式可以被多种控制类型支持，一个控制类型也可以支持多种控制模式，每一个组合都展现其不同的行为样式。比如，一个下拉框类型(Combo Box)具有至少两种控制模式：一个是呈现其折叠和展开能力的模式(ExpandCollapsePattern)，另一个是呈现其选择项的可选择模式(SelectionItemPattern)。

WPF的UI自动化测试

我们知道，现有技术条件下实现UI自动化测试系统开发需要分别实现不同技术条件下的UI元素的鉴别和控制，实现复杂而且有效性不高。而借助于WPF的UI自动化所提供的统一的控制模式就可以轻松实现。

作为UI自动化服务提供者，在开发一个应用程序的时候，必须注意最终用户通过标准键盘和鼠标操作UI对象进行交互的行为。一旦这些关键行为被确定，则其相应的反映UI元素功能和行为的UI自动化控制模式就需要被应用程序实现。比如，要实现一个组合框对象，就需要确定用户对组合框所进行的操作控制模式，用户通常需要调用组合框的折叠和展开模式去隐藏和显示其可选择项列表，也需要调用其编辑模式通过键盘输入增加一个新的选择项。UI自动化服务提供者实现控制模式的接口位于System.Windows.Automation.Provider 名字空间中，其所有控制模式接口都包含后缀“Provider”，比如调用模式接口 IInvokeProvider，文本模式接口ITextProvider等。所有标准WPF控制项自动支持UI自动化，应用程序自定义的控制项必须提供支持UI自动化的访问类和接口。

作为UI自动化客户端，通过调用UI自动化的控制模式类提供的方法和属性得到UI元素的控制信息和内容信息，达到对UI操作和控制目的。这些控制模式类位于System.Windows.Automation名字空间，其所有控制模式类都包含后缀“Pattern” ，比如调用模式类InvokePattern，文本模式类TextPattern等。

控制模式将一个界面元素对象所支持的结构，方法，属性和事件结合在一起。控制模式对于UI元素的关系相比于接口对于COM对象的关系。对于COM，我们可以通过询问COM对象得到它所支持的接口，然后通过接口调用对应的COM功能。对于UI自动化对象，客户端可以通过询问UI对象得到它所支持的控制模式，然后通过其控制模式调用得到其结构、方法、属性和事件，从而实现和UI的交互。

例如，提供者实现了多行文本编辑控制的滚动模式接口IScrollProvider，当一个客户端程序探测到这个界面元素支持滚动模式，则可以通过调用滚动模式类ScrollPattern得到这个文本编辑框的属性、方法和事件来收集所支持的文本滚动信息，通过程序化的方法实现文本编辑框内容的滚动。

综上所述，WPF的UI自动化技术旨在提供一个统一的UI控制访问方式，由UI自动化服务提供者 (UI Automation Providers) 实现控制模式接口，UI自动化客户程序 (UI Automation Clients) 则通过调用相应的控制模式类来实现UI自动化操作和控制。

链接

软件测试的花费往往很高。自动化是一个节省时间和成本的好办法。但是软件自动化测试的工具和技术，往往缺乏通用的适用性和伸缩性。为了实现测试过程的自动化，我们依据软件需求或规格设计说明书，针对测试对象，自动生成测试用例，使测试能自动执行，自动验证其正确性。

在整个软件测试过程中，由于UI在提升用户体验方面的特殊作用，UI级别的测试不但在于验证系统的正确性和有效性，而且在验证整个系统的易用性、行为一致性和稳定性方面有着非常重要的作用。

但UI自动化测试历来困难。一般来说，一个系统大量的UI人为干预，都需要测试。今天我们还没有一个完全能达到此一目标而颇具规模的系统。UI自动化程度仍停留在自动化测试脚本的水平。