以前写过一篇跟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，而且还会碰到有些控件不在控件树 上。所以，大家跟我一起期待年底的更新吧……

windows平台UI自动化测试