共计 3623 个字符,预计需要花费 10 分钟才能阅读完成。
档对象模型
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 等
编辑
在理论工作中,这种定位形式简直不必,因为一个页面中可能会有很多的 TextView、ImageView 等;
appiumdriver.findElementByClassName(“android.widget.TextView”);
如上所述,xpath 是不仅能够在挪动端进行元素定位,并且是咱们最罕用的定位形式之一,在 web 端自动化咱们会首推 CSS 定位,而在挪动端定位咱们会首推 xpath 定位,良好的 xpath 定位语法会给咱们定位带来准确度和便当度,对速度的影响也齐全会在咱们的承受范畴以内
如下 dom 构造中,一个界面上有多同类型控件, 这些控件有雷同的 id 或属性, 不具备唯一性, 所以无奈间接进行指定控件的定位操作,这个时候就该 xpath 大显神通了
如咱们要定位 ” 画好一个关闭的圆 ” 前面跟着的第二个 RelativeLayout, 具体写法如下:
// 上面两种写法均可实现 By.xpath(“((//[@text=’ 画好一个关闭的圆 ’])[2]/following-sibling::android.widget.RelativeLayout)[2]”) By.xpath(“((//[@text=’ 画好一个关闭的圆 ’])[2]/following-sibling::*[@class=’android.widget.RelativeLayout’])[2]”)
很多控件都是有 text 属性的,然而 appium 是不反对间接对 text 进行定位的,而在理论工作中,咱们常常会拿 text 进行定位,这就要归功于 xpath 了,通过对 xpath 语法的封装,咱们就能够自定义一个依据 text 定位元素的办法来:
public By ByText(String text){return By.xpath(“//*[@text='”+ text + “‘]”); } appiumdriver.findElement(ByText(“ 关注 ”));
另外,须要定位 Toast 弹框时,有且仅有通过 xpath 的形式来实现:有时候咱们进行某个操作后会弹出音讯提醒,例如点击某个按钮或下拉刷新后可能会呈现相似 ” 刷新胜利 ” 的提醒语,而后几秒后隐没;
编辑
弹出的音讯很可能是 Android 零碎自带的 Toast,Toast 在弹出的时候会在以后界面呈现节点 android.widget.Toast,随着音讯的隐没而隐没;这个时候咱们如果须要定位这个弹出音讯,对其进行测试的话,就能够应用定位 xpath 形式了。
System.out.println(appiumdriver.findElementByXPath(“//*[@class=’android.widget.Toast’]”).getText());
后果:
编辑
更多 xpath 介绍可参考博客:推开 Web 自动化的大门达到“立功景象”- 侦破 selenium 架构、环境装置及罕用元素定位办法或 W3C:https://www.w3school.com.cn/x…
学过 web 自动化的同学晓得,在 HTML 中元素是有本人的 id 的,在挪动端,元素仍然有本人的 id 值,只不过名字叫做 resource-id,如下:
注:咱们看到 id 的值很长,其实理论应用只须要取斜杠 / 前面的局部就能够了,如下:
By.id(“statusTitle”)
在挪动端自动化中有个非凡的定位形式就是依据 accessibilityId 定位,在 dom 中体现就是属性 content-desc 的值,如果 Android 中的 content-desc 中写入了值,便能够通过其进行定位:
编辑
这里比拟难堪。。。因为研发常常偷懒不写,找了半天也没能找到例子,大家晓得用法就好~ 另外要留神的是如果要写成 ”By.xxx” 的模式,须要应用 MobileBy
MobileBy.AccessibilityId(“AccessibilityId”); appiumdriver.findElementByAccessibilityId(“AccessibilityId”);
有时候咱们须要对界面进行肯定的操作形式后能力找到咱们想要的元素,比方滑动列表进行查找等,这个时候就能够借助于 android uiautomator 了这里利用模拟器中的 API Demo 做演示,进入 APIDemo 中 Views,而后滑屏寻找“Popup Menu”进行点击操作
编辑
能够利用 Android 的 UIAutomator 进行滑屏操作,这时候须要应用 AndroidDriver,另外定位元素能够应用 UiScrollable:
编辑
在官网的 uiautomator UiSelector 中有用 ruby 写的实例,不过定位形式是统一的,能够间接借鉴至 java 代码中
driver.findElementByXPath(“//*[@text=’Views’]”).click(); ((AndroidDriver<MobileElement>)driver). findElementByAndroidUIAutomator (“new UiScrollable(new UiSelector().scrollable(true).instance(0)).scrollIntoView(new UiSelector().text(\”Popup Menu\”).instance(0))”) .click();
在理论运行中,AndroidUIAutomator 偶然有定位失败的状况, 可能在定位元素是地位会产生一点偏差, 这里稍加革新防止这种偶发性失败;
By departmentName = MobileBy.AndroidUIAutomator(“new UiScrollable(new UiSelector().scrollable(true).instance(0)).” + “scrollIntoView(new UiSelector().text(\””+ departName +”\”).instance(0))”); find(departmentName);
// 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 的时候咱们的写法要更为谨严