微软UI自动化测试的技术演变.docx
- 文档编号:29506545
- 上传时间:2023-07-24
- 格式:DOCX
- 页数:16
- 大小:346.41KB
微软UI自动化测试的技术演变.docx
《微软UI自动化测试的技术演变.docx》由会员分享,可在线阅读,更多相关《微软UI自动化测试的技术演变.docx(16页珍藏版)》请在冰豆网上搜索。
微软UI自动化测试的技术演变
微软UI自动化测试的技术演变
公布时刻:
2020-1-2816:
07 作者:
熊力 来源:
cnblogs/stbchina
字体:
小 中 大 |上一篇下一篇|打印 |我要投稿 |每周一问,答贴有奖
Windows平台的桌面开发技术,从最原始的Win32SDK,进展到.NETWinForm,一直到今天的WPF和Silverlight,发生了翻天覆地的变化,相对应的UI自动化测试技术,也随之演变。
微软UI自动化技术揭秘将分两个部分介绍Windows平台桌面程序的自动化技术。
上篇将介绍从Win32SDK至今的UI自动化技术演变,下篇将着重介绍最新的UIAutomation(UIA)的内部实现和使用技巧。
自动测试是指用一个程序自动地操纵另外一个程序,模拟用户的操作进行测试。
通常自动化测试涉及到下面三个步骤:
测试源侦测
测试源侦测是定位测试目标元素的过程。
比如要测试Windows附件中的运算器,第一要把运算器窗口和其他程序比如写字板区分开。
进一步测试运算器窗口菜单的时候,需要第一定位菜单条的位置,猎取第二层子菜单等等。
简单地说,自动化测试第一要能够猎取从桌面开始的整个UI树结构,定位到特定测试目标。
用户行为模拟
用户行为模拟指模拟用户的输入,比如鼠标、键盘和触摸笔的操作,中间可能会涉及IME输入法、组合键、特定用户适应,比如输入速度的模拟等。
测试目标检查
指猎取测试元素的属性,比如读取窗口标题,Listbox的子元素,Checkbox的状态等等,以便进行测试检查。
Win32SDK和WindowsMessage
在.NET问世往常,Windows平台上的UI程序无外乎两种技术:
Win32WindowsSDK或者DirectX。
由于DirectX多用于专业领域如游戏和CAD,本文并不讨论。
不管是MFC,VCL依旧VB6,Win32SDK差不多上其全然,最终打交道的事实上差不多上HWND和WindowsMessage。
实现上述自动化的三个步骤无外乎三件法宝,Win32API,WindowsMessage和WindowsHook。
测试程序第一通过FindWindowEx和EnumWindow遍历窗口和子窗口,找到测试元素比如某个按钮,然后能够通过WindowsMessage或者API检查测试目标。
比如通过WM_GETTEXT或者GetWindowText读取窗口标题,通过GetWindowRect读取按钮坐标位置等等。
关于用户行为模拟,能够直截了当通过SendKeyAPI来完成,因此也能够发送WM_CHAR或者WM_KEYDOWN通知等等。
除此以外,WindowsHook更加丰富了技术的选取。
通过WindowsHook,测试人员还能够直截了当监控、截取、模拟目标程序的Windows消息,实现更灵活的模拟,检查甚至录制的功能。
WindowsSpy++〔图一〕尽管不是测试工具,也确实是使用这套技术的典型例子。
通过WindowsSpy++能够定位任意窗口,读取窗口属性,监视窗口消息等等。
图一:
MicrosoftSpy++
采纳Win32SDK和WindowsMessage的优点是直截了当,灵活。
由于直截了当使用Win32API,没有额外的学习曲线,遇上问题能够直截了当参考Win32SDK解决。
使用MessageHook使得测试程序能够灵活实现,直截了当对WindowMessage的操作不仅能够把专门多情形化繁为简,还方便testhook的实现。
〔所谓testhook,是指产品中为了方便测试而专门设计的隐藏功能,该功能对一般用户不可见,只是为了方便测试。
〕
缺点包括以下三个方面:
使用复杂,实现成本高。
Win32AP的使用上有专门多需要专门注意的细节,比如有的Win32API不能跨进程工作,有的WindowsMessage只能发给当前线程所创建的窗口,稍有不慎,就导致测试程序不稳固。
过于底层,不便使用。
为了方便测试用例调用,需要对API进行封装,增加了实现成本。
同时Win32API的也使得专门多VB程序员不便调用。
再者,不同的开发工具,比如MFC,VCL,以及后来的.NETFramework,在内部实现上对Win32API有专门多细节的处理,要实现出针对各种情形都通用的测试框架,并非易事。
比如,.NET中的WinFormControl对Win32HWND的爱护是动态的,同一个WinFormControl的HWND在程序的生命周期内是可能发生改变的,这一点关于依靠HWND作为唯独标识的Win32API确实是一个致命伤。
无法操作自绘窗口。
比如打开Excel的工作表,会发觉表格中的每一个Cell并没有对应到HWND上。
Excel的cell差不多上通过代码绘制,而不是依靠于现成的Win32Control。
这就使得Win32API关于自绘窗口没有用武之地。
MSAA
MSAA的全称是MicrosoftActiveAccessibility。
这是类似DCOM技术。
技术模型是如此的,UI程序能够暴露出一个Interface,方便另一个程序对其进行操纵。
MSAA技术的初衷是为了方便残疾人使用Windows程序。
比如盲人看不到窗口,然而盲人能够通过一个USB读屏器连接到电脑上,读屏器通过UI程序暴露出来的那个Interface,就能够猎取程序信息,通过盲文或者其它形式传递给盲人。
MSAA提供了如此方便的功能,UI自动化测试自然能够借用这项技术。
MSAA暴露出来的Interface叫做IAccessible。
测试程序和目标UI程序互操作流程如下:
1.测试程序调用WindowsAPI:
AccessibleObjectFromWindow,传入目标UI程序HWND。
2.AccessibleObjectFromWindow函数向UI程序发送WM_GETOBJECT消息。
3.UI程序创建实现了IAccessible的内部类,然后通过LresultFromObjectAPI把IAccessible接口返回给测试程序。
4.测试程序拿到IAccessible接口,开始调用IAccessible接口函数操作测试目标。
IAccessible接口里面的几个关键函数是:
*IAccessible:
:
get_accChild/IAccessible:
:
get_accParent通过这两个函数,调用者能够扫瞄目标程序的窗口关系树,定位到UI元素。
*IAccessible:
:
accLocation/IAccessible:
:
accHitTest读取和辨论目标元素的屏幕位置。
*IAccessible:
:
accName/IAccessible:
:
accSelect读取元素的名字,对UI元素进行指定的操作,比如选取Listbox里面的某一项等等。
*IAccessible:
:
accValue开发人员能够自定义value属性的实现。
比如针对折线图控件,开发人员能够在accValue中返回折线的坐标数列。
MSAA的理念类似于testhook。
通过主动让UI程序暴露一个接口来让调用者操纵。
在具体使用中,测试人员往往是结合MSAA和Win32API操作,取长补短。
一方面关于UI元素丰富的属性,比如style,钩选状态,是否最大化和模拟用户输入等,连续采纳Win32API。
另一方面用MSAA的优势来补偿Win32API的一些不足,比如:
由于MSAA有自己的get_accChild方法,使其控件树关系并不一定要和Win32HWNDd关系对应一致。
关于自绘窗口,尽管说只有一个HWND,然而开发人员能够通过实现IAccessible接口来实现逻辑上的层次关系。
比如Excel中就能够通过IAccessible把多个cell的子IAccessible接口暴露给调用者。
IAccessible的实现是由开发者提供,开发者能够灵活地依照实际情形决定方法的实现。
比如前面提到了折线图控件能够返回坐标数列。
关于.NETWinForm,微软在Framework中就提供了IAccessible的默认实现,如此在具体实现中,就能够处理.NET动态爱护HWND的细节等等
针对MSAA的工具也有专门多,比如AccExplorer〔图二〕能够像Spy++一样对指定程序进行控件的树形扫瞄,检查MSAA属性等。
图二:
AccExplorer
假如您是开发人员,关于unmanagedUI程序的MSAA实现,参考MSDN中关于WM_GETOBJECT的说明返回IAccessibleinterface就能够了。
关于managed程序,实现方法更简单,现成的例子能够参考:
* Control..:
:
.ControlAccessibleObjectClass
* HowtocreateaccessiblecontrolsbyusingVisualBasic.NETorVisualBasic2005
关于测试程序如何直截了当猎取并使用IAccessible接口,并非本系列重点,因此并不提供更多介绍。
在后面的文章中,会介绍如何隐含使用IAccessible和MSAA。
MSAA也有自身的缺点:
1.尽管说MSAA基于COM技术,但IAccessible并不是一个COM标准接口。
比如使用者不需要调用CoInitialize即可使用,也无法通过QueryInterface进一步猎取更多的自定义接口。
这局限了MSAA所能提供的功能。
2.IAccessible接口的定义有缺陷。
里面许多方法是可有可无的,然而又缺少一些支持UI自动化的关键方法。
比如它提供了accSelect支持控件的选取,然而却没有类似accExpand如此的方法支持树状控件的展开等。
关于MSAA和UI自动化的更多渊源,MSAA设计理念,现状和缺陷,能够参考微软早期的一篇名为WhatisUIAutomation的文章。
UIAutomation和WPF
UIAutomation是微软从WindowsVista开始推出的一套全新UI自动化测试技术,简称UIA。
在最新的WindowsSDK中,UIA和MSAA等其它支持UI自动化技术的组件放在一起公布,叫做WindowsAutomationAPI。
和前面的介绍相比,我倾向于认为UIA是一项自动化测试〝技术〞,而MSAA和Win32API只是实现自动化测试的两种〝方法〞。
那个地点区分〝技术〞和〝方法〞的缘故是,一项〝技术〞往往有独立的模型,体贴的开发接口,用来专门解决某一类的问题,同时承诺不同的实现细节。
UIA能够被看作〝技术〞,是因为:
UIA定义了全新的、针对UI自动化的接口和模式。
分别是支持对UI元素进行遍历和条件化查询的TreeWalker/FindAll。
定义了读写UI元素属性的UIAProperty,包括Name、ID、Type、ClassName、Location、Visibility等等。
定义了UI元素行为的UIAPattern,比如Select、Expand、Resize、Check、Value等等。
还引入了UIAEvent接口,能够让测试程序在某些事件发生后得到通知,比如新窗口打开事件等。
以往的Win32和MSAA设计动身点并不是为解决UI自动化。
Win32旨在提供的通用开发接口,MSAA旨在提供程序的多种访问方式。
相反,UIA的设计目的,以及新引入的模式和接口都完全是针对UI自动化测试的。
在后面的文章中我们会详细分析UIA的内部实现。
能够看到,UIA这一套接口和模式,能够在不同平台,不同开发工具中实现和使用。
其内部实现方式也因地制宜,前后的兼容性都照管得专门好。
同时,UIA提供了托管的和非托管两种API,这些差不多上Win32和MSAA无法比拟的。
下面一段简单的C#代码演示了如何使用UIA测试Windows自带运算器完成运算3+5-2的操作〔下述代码可能需要修改以适应不同Windows版本的calc.exe程序。
本代码使用VisualStudio2020针对Windows2020ServerR2English编写〕。
UIAutomation和WPF
UIAutomation是微软从WindowsVista开始推出的一套全新UI自动化测试技术,简称UIA。
在最新的WindowsSDK中,UIA和MSAA等其它支持UI自动化技术的组件放在一起公布,叫做WindowsAutomationAPI。
和前面的介绍相比,我倾向于认为UIA是一项自动化测试〝技术〞,而MSAA和Win32API只是实现自动化测试的两种〝方法〞。
那个地点区分〝技术〞和〝方法〞的缘故是,一项〝技术〞往往有独立的模型,体贴的开发接口,用来专门解决某一类的问题,同时承诺不同的实现细节。
UIA能够被看作〝技术〞,是因为:
UIA定义了全新的、针对UI自动化的接口和模式。
分别是支持对UI元素进行遍历和条件化查询的TreeWalker/FindAll。
定义了读写UI元素属性的UIAProperty,包括Name、ID、Type、ClassName、Location、Visibility等等。
定义了UI元素行为的UIAPattern,比如Select、Expand、Resize、Check、Value等等。
还引入了UIAEvent接口,能够让测试程序在某些事件发生后得到通知,比如新窗口打开事件等。
以往的Win32和MSAA设计动身点并不是为解决UI自动化。
Win32旨在提供的通用开发接口,MSAA旨在提供程序的多种访问方式。
相反,UIA的设计目的,以及新引入的模式和接口都完全是针对UI自动化测试的。
在后面的文章中我们会详细分析UIA的内部实现。
能够看到,UIA这一套接口和模式,能够在不同平台,不同开发工具中实现和使用。
其内部实现方式也因地制宜,前后的兼容性都照管得专门好。
同时,UIA提供了托管的和非托管两种API,这些差不多上Win32和MSAA无法比拟的。
下面一段简单的C#代码演示了如何使用UIA测试Windows自带运算器完成运算3+5-2的操作〔下述代码可能需要修改以适应不同Windows版本的calc.exe程序。
本代码使用VisualStudio2020针对Windows2020ServerR2English编写〕。
UIA的优势
UIA的优势专门明显,要紧包括以下几点:
1.适应不同类型的UI程序,包括Win32、WinForm、WPF和Silverlight。
由于WPF和Silverlight中的子窗口和控件并不是传统的HWND,因此Win32API和MSAA无能为力。
而UIA能够直截了当支持这两种程序。
2.兼容传统的Win32和MSAA模式。
前面提到过,UIA技术的内部实现能够多样化。
这一点在下一篇文章中会详细讨论。
UIA通过一项叫做UIA<->MSAA的桥技术,针对传统程序,能够在内部实现中借用MSAA的接口和直截了当调用Win32API。
如此不需要对控件或者程序的既有实现做任何改动,就能够直截了当适用于UIA的新模式。
3.新引入的TreeWalker、UIAEvent、Pattern、Property模式易于使用,贴合自动化测试。
这些模式高度抽象了各种UI自动化测试的需求,同时又不和传统模式相冲突。
比如执行点击按钮操作,传统方法要么模拟鼠标键盘操作,要么发送WindowsMessage,而Message还分为WM_COMMAND或者WM_BUTTONDOWN。
而通过UIAPattern,统一归类于Invoke接口,那个接口关于测试者来说就统一了。
不管是Win32、WPF依旧Silverlight按钮,都能够通过统一接口执行,从而把具体实现隔离开。
同时,调用者假设期望连续沿用键盘鼠标模拟,仍旧能够通过SendKey加上UIA猎取坐标的方法实现。
而UIAEvent和对UI元素支持条件化区域化搜索,更是极大简化了测试人员的工作。
4.提供托管的和非托管接口,方便各种工具的开发人员。
同时提供了简洁方便的方式支持UI程序和控件开发人员扩展,自定义UIA的实现。
比如通过AutomationPeer来扩展基于WPF的控件,通过实现简单的IRawElementProviderSimple来扩展基于WinForm的控件等。
具体细节在下一篇文章中会详细介绍。
5.针对WPF程序,除了支持差不多的端对端〔EndtoEnd〕UI自动化以外,还支持基于AutomationPeer的单元测试。
具体例子能够参考UIAutomationinSilverlight-SimulatingUserInteractions
6.提供了完善的工具、文档、开发包、例子程序等。
比如通过UISpy〔图三〕猎取任意窗口或者元素的UIA信息。
图三:
UISpy
自动化技术和自动化框架
前面提到了UIA作为全新UI自动化测试技术的优势,但这并不能解决所有的UI自动化问题。
自动化框架正是为了自动化技术没有完全解决的问题。
比如:
1.自动化中的同步和等待。
关于稍复杂的UI程序,测试程序往往需要依照测试目标的状态决定下一步的操作。
比如测试文件另存为功能的时候,假设储存路径是网络路径,可能会因为网络延迟导致整个UI停顿比较长的时刻。
那个时候测试,程序假如不顾当前状态而简单地执行下一步操作,比如新建文件,专门可能会因为UI延迟而失败。
正确的做法是,测试程序应该等待文件储存成功返回后,再进行下一步操作。
这确实是自动化中同步和等待的一个例子。
实现同步和等待有多种方法,最简单粗暴的做法是硬编码一个长时刻的Sleep在测试代码中。
略微好一点的做法能够采取小时刻片的轮询状态检查,或者反复重试。
借助UIA的EventPattern,能够尝试捕捉另存为窗口的关闭WindowClosedEvent。
假如要做得完善一点,能够把多种方法结合,另外再额外检查目标程序的CPU使用情形,消息循环是否有回应,设定超时时刻等等。
2.冗繁的编码过程。
关于一个UI窗口,里面可能有几十个子控件或者子窗口。
在编写测试代码的时候,假如对这些子元素的猎取,操作不能简化,势必导致代码冗繁,难以爱护。
借助自动代码生成和ORM(ObjectRoleModeling)等技术,能够解决那个问题。
比如能够用工具把窗口及其子元素的关系和搜索条件都序列化到XML文件中,然后采纳ORM技术即可在代码中轻松猎取子元素。
3.多语言和本地化测试。
多语言和本地化的测试对UI来说显得尤为重要。
UI程序往往通过资源文件来定义所显示的内容,这就要求自动化测试要能够方便读取和定位程序的资源文件,来支持多语言和本地化测试。
4.支持工具和辅助函数的匮乏。
关于大的项目研发,通过好的工具来减小开发成本是专门必要的。
就UI自动化来说,假如自动化测试用例能够通过一次录制,多次播放来做的话,成本会减少专门多。
在VS2020中就提供了如此的录制-播放功能。
详细视频能够参考HowtocreaterecordandplaybackTestCasesinVisualStudioBeta2。
5.区分功能性测试和用户真实行为模拟。
前面提到,就点击按钮功能来说,能够通过SendKey来模拟鼠标操作,或者通过WindowsMessage来直截了当触发点击事件。
这两种不同方法各有优劣。
比如当按钮被其它元素遮挡,通过SendKey进行模拟就会导致失败,而直截了当发送WindowsMessage依旧会成功。
孰优孰劣取决于要达到的目的。
假如单纯为了测试按钮点击后导致的结果,通过WindowsMessage来模拟就省去了专门多苦恼。
相反,假如是界面测试,通过SendKey来模拟就能够让按钮被遮挡的bug暴露出来,而WindowsMessage那么不能发觉如此的问题。
因此,单纯的某个自动化技术或者方法也无法满足需求。
为了解决上述问题,各种自动化测试框架逐步涌现和进展。
微软内部有多个不同的自动化框架,设计理念和侧重点各有不同。
VisualStudio2020将加入对自动化测试的支持。
在CodePlex上面,也能够找到多种框架,比如White和UIAutomationVerify。
小结
本篇要紧介绍和比较了Windows平台UI自动化技术的演变。
UIA技术势必成为UI自动化的主流。
下个月,我们会着重介绍UIA技术的内部机制、原理、实现以及如何在程序和控件中扩展UIA的功能。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 微软 UI 自动化 测试 技术 演变