软件测试 / 测试开发 | App 自动化之 dom 结构和元素定位方式（包含滑动列表定位）
获取更多相关知识
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 端自动化时候也介绍过相关元素定位方式，具体可在文章末尾往期回顾第一条点击查看。
控件定位
UI 自动化测试的步骤三要素是：
定位
交互
断言
那么第一步便是要对元素进行定位，下面就来看看移动端如何进行元素定位
2.1 控件属性
通过 uiautomatorviewer 对雪球 App 首页的解析得到如下图结果：
通过解析结果我们可以看到元素的属性和类型有：
node
attribute
clickable
content-desc
resource-id
text
bounds
iOS 和 Android 在控件属性和上稍微有些不同(这里先说个概括，后续单独出 IOS 的文章加以说明，欢迎关注)：
dom 属性和节点结构类似
名字和属性的命名不同
2.2 定位方式
Appium 支持 WebDriver 定位策略的子集：
2.21 通过 “class” 查找 (例如， UI 组件的类型)-一般不推荐
在实际工作中，这种定位方式几乎不用，因为一个页面中可能会有很多的TextView、ImageView等；
2.22 通过 “xpath” 查找 (例如， 一个元素的路径以抽象的方式去表达，具有一定的约束)-重要
如上所述，xpath是不仅可以在移动端进行元素定位，并且是我们最常用的定位方式之一，在 web 端自动化我们会首推CSS定位，而在移动端定位我们会首推 xpath 定位，良好的xpath定位语法会给我们定位带来准确度和便利度，对速度的影响也完全会在我们的接受范围以内
如下 dom 结构中，一个界面上有多同类型控件,这些控件有相同的id或属性,不具备唯一性,所以无法直接进行指定控件的定位操作，这个时候就该 xpath 大显身手了
上图可以看到,所有勾选控件的结构是一样的,相对位置是固定的,而勾选控件相对它们的"哥哥"节点的TextView是不同的，这样就可以先定位至"哥哥"节点,在根据相对位置,定位到指定的控件节点
在 xpath 中提供了多种轴方法,其中
following-sibling可实现此功能
如我们要定位"画好一个封闭的圆"后面跟着的第二个RelativeLayout,具体写法如下:
很多控件都是有text属性的，但是appium是不支持直接对text进行定位的，而在实际工作中，我们经常会拿 text 进行定位，这就要归功于xpath了，通过对xpath语法的封装，我们就可以自定义一个根据text定位元素的方法来：
另外，需要定位Toast弹框时，有且仅有通过xpath的方式来实现：有时候我们进行某个操作后会弹出消息提示，例如点击某个按钮或下拉刷新后可能会出现类似"刷新成功"的提示语，然后几秒后消失;
弹出的消息很可能是Android系统自带的Toast，Toast在弹出的时候会在当前界面出现节点android.widget.Toast，随着消息的消失而消失；这个时候我们如果需要定位这个弹出消息，对其进行测试的话，就可以使用定位xpath方式了。
结果：
更多 xpath 介绍可参考博客：推开 Web 自动化的大门到达“犯罪现象”-侦破 selenium 架构、环境安装及常用元素定位方法或 W3C：www.w3school.com.cn/xpath/xpath…
2.23 通过 id 定位(每个元素原则上都有自己的唯一 id 值)-重要
学过 web 自动化的同学知道，在 HTML 中元素是有自己的id的，在移动端，元素依然有自己的id值，只不过名字叫做resource-id，如下：
注： 我们看到id的值很长，其实实际使用只需要取斜杠/后面的部分就可以了，如下：
2.24 通过 accessibilityId 定位(实则就是 android 的 content-desc)-偶尔用到
在移动端自动化中有个特殊的定位方式就是根据accessibilityId定位，在 dom 中表现就是属性content-desc的值，如果Android中的content-desc中写入了值，便可以通过其进行定位：
这里比较尴尬。。。由于研发经常偷懒不写，找了半天也没能找到例子，大家知道用法就好~另外要注意的是如果要写成"By.xxx"的形式，需要使用MobileBy
2.25 通过 android uiautomator 定位(相当于使用 UiAutomator Api 去递归地搜索元素（Android 专属）)-高级用法
有时候我们需要对界面进行一定的操作方式后才能找到我们想要的元素，比如滑动列表进行查找等，这个时候就可以借助于android uiautomator了这里利用模拟器中的 API Demo 做演示，进入 APIDemo 中 Views，然后滑屏寻找“Popup Menu”进行点击操作
可以利用 Android 的UIAutomator进行滑屏操作，这时候需要使用AndroidDriver，另外定位元素可以使用UiScrollable：
在官网的uiautomator UiSelector中有用ruby写的实例，不过定位方式是一致的，可以直接借鉴至java代码中
这里大概定位的方法就是，先用 new UiSelector().scrollable(true).instance(0)判断是否可以滑动，找到 ListView，然后用 scrollIntoView(new UiSelector().text("WebView").instance(0)滑动找到对应定位属性的元素。
在实际运行中,AndroidUIAutomator偶尔有定位失败的情况,可能在定位元素是位置会产生一点偏差,这里稍加改造避免这种偶发性失败;
改造方法:滑屏寻找元素时会先滑屏至待查元素的附近,这时元素已处于页面可见范围内,对元素操作可以重新定位操作,例如点击操作可以利用 Xpath 的方法重新定位后再 click().
运行效果演示：
定位逻辑的区别
在之前的一篇文章中我们介绍过 appium 底层的使用了各种引擎，可在文章末尾往期回顾第一条点击查看。
先简单看如下图：
我们现在用的最新的版本优先支持的就是uiautomator2，如果你使用的是相对较前的版本，可能支持的是uiautomator，那么这两个引擎对于以上介绍的定位有什么影响呢？来看源码：
我们现在用的最新的版本优先支持的就是uiautomator2，如果你使用的是相对较前的版本，可能支持的是uiautomator，那么这两个引擎对于以上介绍的定位有什么影响呢？来看源码：
Uiautomator 源码
以 id 定位为例，在Uiautomator的源码可见其对 id 定位要更为宽泛，当我们使用By.id的时候，会同时去匹配resourceId、accessibility id、id
Uiautomator2 源码
在 Uiautomator2 中，将 id 的定位进行了细分，对应不同的 id 进行判断后再操作，因此在使用 Uiautomator2 的时候我们的写法要更为严谨
appium 官方说明文档：http://appium.io/docs/en/writing-running-appium/finding-elements/http://appium.io/docs/en/commands/element/find-elements/
Uiautomator2 源码路径：
版权声明: 本文为 InfoQ 作者【测试人】的原创文章。
原文链接:【http://xie.infoq.cn/article/f5b8ceb2578aeea0384b58524】。文章转载请联系作者。
还未添加个人签名 2022-08-29 加入
还未添加个人简介
评论