windows平台UI自动化测试

胖虎

Windows API

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

　 　操作窗口和获取属性：通过SetWindowText和GetWindowText来操作控件上显示的文字，通过 Set
ForegroundWindow设置顶层窗口,GetForegroundWindow获取当前的顶层窗口，类似的还有 GetActive
Window和SetActiveWindow。其 它 操作就不一一列举了……从理论上来说，通过Windows API和Wind
ows Message可以完成对大部分窗口（控件也是窗口，一起都是窗口）的操作，也可以获取部分控件的
部分属性。但是缺点和优点也比较明显：

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

　　缺点：底层意味着复杂，意味着需要多层的封装，意味着 开发效率低下，也意味着对Windows AP
I的完全依赖。如果碰到一个非标准（自定义控件），用这种方式实现的自动化工具基本上完全束手无
策，即使有开发团队的支持也很难完成自动化。当然了， 算坐标，甚至用全局坐标来做也可以做，
但这是野蛮做法，自动化测试的代码非常不稳定，维护和分析结果的成本也很高。

　　总而言之，言而总 之，没有哪个自动化测试工具完全用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 Acti
ve 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是要取代M
SAA成为自动化测试的标准类库，并且对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的控件树上，当然也无法对它进行任何操作 （当然，如果你用屏幕坐标，然后通过AutomationE
lement.FromPoint来做，还是可以做的，但是请注意，你使用了屏幕坐标）。在一 些小的程序上，可
能不是很明显，如果是大的项目，并且有很多自定义控件的情况下，这个问题就会被放大，这个Exce
ption就像一个黑洞一样会吞掉很多 控件，也意味着你需要在很多地方去写代码来绕过这个问题，同
时也带来了维护成本的大幅提高。

　　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发布的，也就是说W
indows 7本身就集成了Windows Automation API 3.0所以的组件和功能，再换一句话说就是Window
s 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 A
PI 3.0只支持Windows 7，不能安装在XP/Vista上，后来经过和他们的斗争，有了下边的Update： ht
tp://social.msdn.microsoft.com/Forums/en-AU/windowsaccessibilityandautomation/thread/46e83c5
5-47b8-4874-9222-7ce2fa58751d

　　所以，对Windows Automation API 3.0的当前情况就是：

　　如果你仅仅在Windows 7 上做自动化测试，那么恭喜你，你可以使用Windows Automation AP
I 3.0的所有功能，既可以用Managed code来做，也可以用Unmanaged code来做。

　　如果你想在Vista上用，装了那个更新以后，应该就可以了，我没试过……

　　如果你想在XP/Server2003上使用，你需要等到今年年底的某个时候（快到了）

　　总之，在Windows 7上，怎么做都行（Managed/Unmanned），在XP/Vista/Server2003上，只
能用.Net，而且还会碰到有些控件不在控件树 上。所以，大家跟我一起期待年底的更新吧……