档对象模型
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的时候咱们的写法要更为谨严
发表回复