Windows GUI自动化测试技术的比较和展望 (转)

关注

转载最新推荐文章于 2026-11-09 13:55:23 发布 894 阅读 AI 写同款· GEO 优化 ›

Sikuli X 1.0rc3 GUI自动化测试实战工具 Sikuli X 是一个创新的自动化测试工具，通过图像识别技术，它能够让开发者或测试人员非常容易地实现图形用户界面（GUI）的自动化测试。Sikuli X 在幕后使用OpenCV技术，能够在无需编写复杂代码的情况下，根据屏幕上的图像进行自动化操作。Sikuli X的Python类库提供了丰富的API来支持GUI自动化测试。例如：Screen()：代表当前的屏幕，可以用来截图和识别图像。：代表屏幕上的一个矩形区域，可以用坐标和尺寸定义。find()：在指定的区域中查找图像。阅读详情

【这里的自动化测试专指GUI自动化（不包含Web）】

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