概述

UIA框架提供了一种统一的对象模型，使得我们不管使用哪种UI框架编写出复杂功能的界面，都很容易访问控件和做界面自动化。

UIA是作为Microsoft Active Accessibility的继承者开发的。MAA是一个现有的框架，旨在提供一种使得控制和应用程序易访问的通用解决方案。MAA并非是为了做自动化而生，即使最后由于各种原因它发展成为了一种自动化方案。而UIA除了提供更完善的可访问性解决方案外，还专门为自动化测试提供强大的功能。 例如，MAA中，对外暴露UI信息和收集AT products使用同一个接口，而UIA将这两者分离为两种模型。

UIA能成为如此有用的自动化测试工具，其中的provider和client都是比不可少的角色。UIA provides可以理解为被测试的应用程序（如EXCEL,WORD以及其他的第三方应用或者基于WINDOWS系统开发的控件）。UIA clients可以理解为我们用去测试应用程序的自动化脚本或者基于provider开发的辅助程序（如读屏软件）。

UIA之provider

为了使得UI能够被自动化，应用程序或者控件的开发者需要考虑终端用户使用鼠标键盘等标准输入能够对控件进行的操作。

一旦这些关键的动作被定义了，就应该在这个控件上实现对应的UIA控件模型（就是说控件模型映射了UI元素的功能和行为）。UIA的控件模型（control patterns）抽象出了常用控件的行为，对用户隐藏了不同控件的差异性。

如前面提到的，如果没有UIA提供的统一的模型，开发者或者测试工具需要了解每一种框架的细节，以达到准确的对外暴露出该框架下控件的属性和行为（不同框架下实现的同一类控件对外暴露的属性可能是不一样的）。因为在windows操作系统上，任何时候都是各种UI框架共存（如win32/winform/wpf），所以在没有UIA模型之前，测试几种看起来由类似控件实现的应用程序是一项非常艰巨的任务（因为他们使用的框架可能不同，测试代码无法复用，需要各自独立维护）。下面示例说明：

UIA provider就是负责将各种不同框架的属性映射为对应的UIA的属性。对用户来说屏蔽了这种差异性。

UIA之client

录制回放方式的劣势

在做UI自动化测试时，我们的一个理想目标是测试工具或者测试场景能够连贯（稳定）、可重复执行。我们可以通过对控件操作进行录制回放来实现。

UI自动化测试的一个难点就是静态的测试脚本如何能够同步操作动态变化的控件。例如，列表框控件（例如Windows任务管理器中包含的控件），其显示当前运行的应用程序的列表。因为任务管理器列表里面的每一项都是一直动态变化的，所以通过来对某一个特定区域来进行录制回放实现脚本的重复性是不可行的。

UIA的优势

UIA以程序化访问的方式来连接自动化脚本和被测试应用程序，它能够让我们通过代码来模拟鼠标和键盘等外设的操作，来与被测试程序进行交互。UIA通过抽象出下面5部分，为我们提供程序化访问。

1、UIA Tree

2、UIA Control Types

3、UIA Properties

4、UIA Control Pattern

5、UIA Events

使用UIA编写自动化测试程序的步骤（C#）

C#编写自动化脚本的步骤