App 自动化之 dom 结构和元素定位方式(包含滑动列表定位)
来看几个名词和解释:
dom: Document Object Model 文档对象模型
dom 应用: 最早应用于 html 和 js 的交互。界面的结构化描述, 常见的格式为 html、xml。核心元素为节点和属性
xpath: xml 路径语言,用于 xml 中的节点定位,XPath 可在 xml 文档中对元素和属性进行遍历
如下我们再来看一个 App 的 dom:
控件的基础知识和 selenium 一样,appium 为移动端抽象出了一个控件模型,称为 dom 结构;会把所有的控件都理解为 xml 文件,在 xml 文件里,每个控件都有自己的类型和属性;
既然有了类型和属性,自然就可以根据这些来定位元素,又因为整个模型是 xml,也就同样可以通过 xpath 的方法来定位各个控件的信息了,是不是似曾相识?在 Web 端自动化时候也介绍过相关元素定位方式,具体可在文章末尾往期回顾第一条点击查看。
定位
交互
断言
通过 uiautomatorviewer 对雪球 App 首页的解析得到如下图结果:
通过解析结果我们可以看到元素的属性和类型有:
node
attribute
clickable
content-desc
resource-id
text
bounds
IOS 和 Android 在控件属性和上稍微有些不同(这里先说个概括,后续单独出 IOS 的文章加以说明,欢迎关注):
dom 属性和节点结构类似
名字和属性的命名不同
Appium 支持 WebDriver 定位策略的子集:
2.21 通过 “class” 查找 (例如, UI 组件的类型)-一般不推荐
在实际工作中,这种定位方式几乎不用,因为一个页面中可能会有很多的 TextView、ImageView 等;
如上所述,xpath 是不仅可以在移动端进行元素定位,并且是我们最常用的定位方式之一,在 web 端自动化我们会首推 CSS 定位,而在移动端定位我们会首推 xpath 定位,良好的 xpath 定位语法会给我们定位带来准确度和便利度,对速度的影响也完全会在我们的接受范围以内
如下 dom 结构中,一个界面上有多同类型控件,这些控件有相同的 id 或属性,不具备唯一性,所以无法直接进行指定控件的定位操作,这个时候就该 xpath 大显身手了
如我们要定位"画好一个封闭的圆"后面跟着的第二个 RelativeLayout,具体写法如下:
很多控件都是有 text 属性的,但是 appium 是不支持直接对 text 进行定位的,而在实际工作中,我们经常会拿 text 进行定位,这就要归功于 xpath 了,通过对 xpath 语法的封装,我们就可以自定义一个根据 text 定位元素的方法来:
另外,需要定位 Toast 弹框时,有且仅有通过 xpath 的方式来实现:有时候我们进行某个操作后会弹出消息提示,例如点击某个按钮或下拉刷新后可能会出现类似"刷新成功"的提示语,然后几秒后消失;
弹出的消息很可能是 Android 系统自带的 Toast,Toast 在弹出的时候会在当前界面出现节点 android.widget.Toast,随着消息的消失而消失;这个时候我们如果需要定位这个弹出消息,对其进行测试的话,就可以使用定位 xpath 方式了。
结果:
更多 xpath 介绍可参考博客:推开 Web 自动化的大门到达“犯罪现象”-侦破 selenium 架构、环境安装及常用元素定位方法或 W3C:https://www.w3school.com.cn/xpath/xpath_syntax.asp
学过 web 自动化的同学知道,在 HTML 中元素是有自己的 id 的,在移动端,元素依然有自己的 id 值,只不过名字叫做 resource-id,如下:
注: 我们看到 id 的值很长,其实实际使用只需要取斜杠/后面的部分就可以了,如下:
在移动端自动化中有个特殊的定位方式就是根据 accessibilityId 定位,在 dom 中表现就是属性 content-desc 的值,如果 Android 中的 content-desc 中写入了值,便可以通过其进行定位:
这里比较尴尬。。。由于研发经常偷懒不写,找了半天也没能找到例子,大家知道用法就好~另外要注意的是如果要写成"By.xxx"的形式,需要使用 MobileBy
有时候我们需要对界面进行一定的操作方式后才能找到我们想要的元素,比如滑动列表进行查找等,这个时候就可以借助于 android uiautomator 了这里利用模拟器中的 API Demo 做演示,进入 APIDemo 中 Views,然后滑屏寻找“Popup Menu”进行点击操作
可以利用 Android 的 UIAutomator 进行滑屏操作,这时候需要使用 AndroidDriver,另外定位元素可以使用 UiScrollable:
在官网的 uiautomator UiSelector 中有用 ruby 写的实例,不过定位方式是一致的,可以直接借鉴至 java 代码中
在实际运行中,AndroidUIAutomator 偶尔有定位失败的情况,可能在定位元素是位置会产生一点偏差,这里稍加改造避免这种偶发性失败;
// click(departmentName); 原来直接操作滑动查找的元素结果 click(ByText(departName));//现在利用 xpath 重新定位确认后再操作,成功率大大提升
运行效果演示:
在之前的一篇文章中我们介绍过 appium 底层的使用了各种引擎,可在文章末尾往期回顾第一条点击查看。先简单看如下图:
我们现在用的最新的版本优先支持的就是 uiautomator2,如果你使用的是相对较前的版本,可能支持的是 uiautomator,那么这两个引擎对于以上介绍的定位有什么影响呢?来看源码:
我们现在用的最新的版本优先支持的就是 uiautomator2,如果你使用的是相对较前的版本,可能支持的是 uiautomator,那么这两个引擎对于以上介绍的定位有什么影响呢?来看源码:
Uiautomator 源码
以 id 定位为例,在 Uiautomator 的源码可见其对 id 定位要更为宽泛,当我们使用 By.id 的时候,会同时去匹配 resourceId、accessibility id、id
Uiautomator2 源码
在 Uiautomator2 中,将 id 的定位进行了细分,对应不同的 id 进行判断后再操作,因此在使用 Uiautomator2 的时候我们的写法要更为严谨
免费领取:性能测试+接口测试+自动化测试+测试开发+测试用例+简历模板+测试文档
http://qrcode.testing-studio.com/f?from=infoQ&url=https://ceshiren.com/t/topic/16565
评论