windows平台UI自动化测试

原文地址：http://www.51testing.com/html/16/n-170116.html

之前写过一篇跟UI自动化 测 试 有关的技术，谈到了一个自动化测试 工具必备的几个功能，并且也提到了Windows 平台自动化测试工具所基于的一些技术。下边就说 一下这些技术的比较和展望，同时也包含了一些纠结……

　　Windows API

　　识 别窗口：须要经过FindWindow和EnumWindows来查找到窗口句柄，而后再调用其它 API(GetWindowText，GetWindowRect, GetWindowLong…)来获取窗口属性，以此来找到想要的控件（窗口）

　 　操做窗口和获取属性：经过SetWindowText和GetWindowText来操做控件上显示的文字，经过 SetForegroundWindow设置顶层窗口,GetForegroundWindow获取当前的顶层窗口，相似的还有 GetActiveWindow和SetActiveWindow。其 它 操做就不一一列举了……从理论上来讲，经过Windows API和Windows Message能够完成对大部分窗口（控件也是窗口，一块儿都是窗口）的操做，也能够获取部分控件的部分属性。可是缺点和优势也比较明显：

　 　优势：就是看起来很高深很强大很底层，对标准Windows的控件支持还不错。

　　缺点：底层意味着复杂，意味着须要多层的封装，意味着 开发效率低下，也意味着对Windows API的彻底依赖。若是碰到一个非标准（自定义控件），用这种方式实现的自动化工具基本上彻底一筹莫展，即便有开发团队的支持也很难完成自动化。固然了， 算坐标，甚至用全局坐标来作也能够作，但这是野蛮作法，自动化测试的代码很是不稳定，维护和分析结果的成本也很高。

　　总而言之，言而总 之，没有哪一个自动化测试工具彻底用Windows API来实现……固然了，也不是说Windows API就没有用了，基本上全部的自动化工具都会或多或少，或直接或间接的调到Windows API，也没人敢说他不调一个Windows API就能作自动化测试工具的，最起码鼠标键盘消息的模拟他就无法弄……

　　MSAA - Microsoft Active Accessibility

　　MSAA在1997年在Windows 95中就已经包含的技术，也许你没有据说过，可是在全部的标准控件中，都实现了MSAA的接口，在微 软 全部的操做系统 中都集成了MSAA的组件，在这里，我就不讨论 MSAA的历史和相关技术了，就啰嗦一点点感慨：MSAA天生就不是设计给自动化测试的，它存在的意义在于提供一套接口，让开发人员能够方便的给残疾人开 发可使用的软件，好比读屏程序（鼠标移动到按钮的时候，能够发出声音，辅助视力障碍的人操做电脑），从而实现微软将电脑普及到每个家庭的梦想。

　 　下面进入正题，虽然MSAA不是设计给自动化测试的，可是现有的全部自动化测试工具都是基于或者部分基于MSAA来实现的。MSAA不少时候直接把它叫 作IAccessible，它自己是一个COM组件，最主要是实现了IAccessible的接口，它提供了一些方法，经过这些方法，能够获取控件更详细 的信息，也能够经过一些方法对控件进行简单的操做（DoDefaultAction）。有兴趣的，能够参考Microsoft Active Accessibility

　　优势：比起Windows API来讲，用户只须要跟IAccessible打交道，经过这个接口能得到的控件信息相对丰富不少，基本操做也不须要经过Windows Message的方式来实现。另一个比较大的优势就是，自定义控件的支持，固然了，并非说开发写一个自定义控件，这个控件就能够经过MSAA来识别， 而是说当开发人员在实现自定义控件的时候，能够实现IAccessible的接口，而且经过这个接口，把一些的属性和操做暴露出来，测试人员就能够将这个 控件看成标准控件，并经过MSAA来自动化。看起来麻烦了点，可是最起码对自动化自定义控件提供了可能。

　　缺点：天生不足，MSAA历来 就不是给自动化测试设计的，因此也不会考虑自动化测试的需求，获取到的控件信息比Windows API多，可是相对自动化测试的需求来讲仍是远远不够，并且仅仅支持一个基本操做，其它的操做还必须经过Windows Message。另外就是微软推出WPF之后，MSAA的局限性越加明显（这也是由于WPF的控件属性更加丰富，更具定制性，更自由，用MSAA难以描 述），这也是微软推出UIAutomation的一个的诱因。

UIAutomation

　　伴随着自动化测试的应用愈来愈普遍，以及WPF的发布，微软在MSAA的基础上，对MSAA进行封装，从新设计并实现了 UIAutomation的类库（.Net），微软根据自动化测试的需求，从新实现了一套自动化体系，你们能够看下边的图，这个比较准确。今后自动化测试 人员迎来了更广阔的一片蓝天（虽然还飘着点小小的乌云……），随之也有了一些小小的纠结：

　　a. UIAutomation （后边就简称为UIA） Vs MSAA

　　在UIA发布的时候，基于MSAA的自动化工具已经发展的很是成熟，好比Silktest和WinRunner… 那么你们在开发一个本身的自动化工具的时候，应该用MSAA呢，仍是UIA？ 这篇文章能够给一个二者的大概关系：UI Automation and Microsoft Active Accessibility。 按照微软的想法和设计，UIA是要取代MSAA成为自动化测试的标准类库，而且对WPF来讲，UIA才是一等公民。从架构上来说，UIA在针对标准控件的 时候，经过UI Automation Proxy调用了MSAA Server，基本上覆盖了MSAA的功能：

　　从上边的图来看，从理论上来讲，UIA应该是能够彻底替代MSAA的，可是理想和现实每每是有很大差距的，从现实来看，UIA不能彻底替代 MSAA，由于一个经典的UIA的Exception：

　　Exception

　　Time Stamp : 10/9/2009 4:37 PM

　　Element : Element details not available.

　　Name : TreeValidationException

　　Message : UI Automation tree navigation is broken. The parent of one of the descendants exist but the descendant is not the child of the parent

　　Stack Trace :  at UISpy.Base.Tree.BuildTree(AutomationElement element)

　　at UISpy.Base.Tree.BuildTreeAndRelatedTrees(AutomationElement element)

　　只要用过UI Spy（UIA的一个小工具，能够看到整个UIA的控件树，相似AccExplorer）的基本上都会碰到，当移动鼠标并识别某个控件时，就有可能看到上 边的Exception，意思是说，UIA在构造UI树的时候失败，鼠标所指向的控件不合法。可是若是你用AccExplorer来看，就彻底没有这个问 题，控件树的结构也比较完整。就意味着，你没法经过遍历控件树来找到想要的控件，由于控件根本就没有构造在UIA的控件树上，固然也没法对它进行任何操做 （固然，若是你用屏幕坐标，而后经过AutomationElement.FromPoint来作，仍是能够作的，可是请注意，你使用了屏幕坐标）。在一 些小的程序上，可能不是很明显，若是是大的项目，而且有不少自定义控件的状况下，这个问题就会被放大，这个Exception就像一个黑洞同样会吞掉不少 控件，也意味着你须要在不少地方去写代码来绕过这个问题，同时也带来了维护成本的大幅提升。

　　b. Managed vs Unmanaged

　　UIA的类库是做为.Net3.0的一部分发布，这就意味着UIA只能用.Net的语言来写，而且运行在.Net托管堆中，性能就成为其中一个 问题，虽然我不认为是很大的一个问题，通常来讲自动化测试程序在等待UI反应的时间要远远多于这一点点的性能差别。

　　c. In-Process Vs Out-Process

　　尽管大部分的自动化测试工具和测试代码都是运行在进程外，可是仍是有一些特殊的应用须要在进程内进行，好比在API测试中，须要进行UI交互， 为了保证API测试的自动化，就必须在进行内写自动化脚本。MASS是支持进程内操做的，可是UIA没有宣布支持，在进程内使用时会有很大的性能问题，也 可能致使一些未知的问题。

　　d. 自定义控件的支持

　　这个UIA就有先天优点了，但也须要开发人员的支持，或者有能力的测试人员也能够本身实现，这就是UIA中的两种Provider，一种内建， 一种外置，只要实现了Provider，自定义控件就能够完美的支持UIA。固然了，对标准控件来讲，UIAutomation发布在Win32控件和 WinForm的控件以后，因此微软就帮咱们实现好了对应这些控件的Client Provider，因此UIA对于之前的Win32和Winform控件也是完美支持的，对WPF的标准控件就更不用说了，天生就是带有Provider 支持的。具体的我就不展开了，你们有兴趣能够看这个：UI Automation Providers Overview

Windows Automation API 3.0

　　这个并非新的自动化测试的技术，而是对UIAutomation（UIA）以及MSAA的升级，更准确的说，是UIA SP1，但名字直接跳到3.0，不知道1.0和2.0是否是指的MSAA的版本，因此你们看到这个名字之后不要晕……  顺便唠叨一下微软的东西，貌似某我的说过，微软的东西都是在没有作完的时候就发布出去，而后过一段儿时间立刻发布Service Pack，因此微软的产品必定要等到SP1之后才能用，这个至关准确:）更详细的介绍你们能够看这个Blog：Microsoft Windows UI Automation Blog

　　我在这里就大概说一下，Windows Automation API 3.0是伴随着Windows 7发布的，也就是说Windows 7自己就集成了Windows Automation API 3.0因此的组件和功能，再换一句话说就是Windows 7就自动化测试的支持将会更好。最主要的更新以下（与上边UIA的几个纠结对应）：

　　a. 更新之后，之前Tree断掉的问题基本上修复了，我在Windows 7上测试的结果来看，没发现问题

　　b. 新增了Unmanned API和COM API，这样直接用Native的C++也能够来开发基于UIA的自动化工具

　　c. 有了COM API之后，看起来In-Process也不是问题了

　　d. …

　　Windows Automation API 3.0看起来很美，基本上都解决了我上边说的UIA的问题，让人感受到这个版本的UIA才是真正能够替代MSAA的东西。可是这个Windows Automation API也让我纠结了好一阵子，差一点就想放弃UIA，从新把Code转移到MSAA上，最主要的缘由是，Windows Automation API 3.0只支持Windows 7，不能安装在XP/Vista上，后来通过和他们的斗争，有了下边的Update： http://social.msdn.microsoft.com/Forums/en-AU/windowsaccessibilityandautomation/thread/46e83c55-47b8-4874-9222-7ce2fa58751d

　　因此，对Windows Automation API 3.0的当前状况就是：

　　若是你仅仅在Windows 7 上作自动化测试，那么恭喜你，你可使用Windows Automation API 3.0的全部功能，既能够用Managed code来作，也能够用Unmanaged code来作。

　　若是你想在Vista上用，装了那个更新之后，应该就能够了，我没试过……

　　若是你想在XP/Server2003上使用，你须要等到今年年末的某个时候（快到了:)）

　　总之，在Windows 7上，怎么作都行（Managed/Unmanned），在XP/Vista/Server2003上，只能用.Net，并且还会碰到有些控件不在控件树 上。因此，你们跟我一块儿期待年末的更新吧……