系统相关
首页 > 系统相关> > Windows GUI自动化测试技术的比较和展望

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

作者:互联网

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

标签:UIA,控件,展望,Windows,GUI,MSAA,API,自动化
来源: https://www.cnblogs.com/dhcn/p/11128243.html