Appium iOS滚动查找元素实践

Appium 介绍

Appium是一个开源、跨平台的测试框架，可以用来测试原生及混合的移动端应用。Appium支持iOS、Android及FirefoxOS平台。Appium使用WebDriver的json wire协议，来驱动Apple系统的UIAutomation库（现在是XCUITest框架）、Android系统的UIAutomator框架。Appium对IOS系统的支持得益于Dan Cuellar’s对于IOS自动化的研究。Appium也集成了Selendroid，来支持老android版本。

Appium支持Selenium WebDriver支持的所有语言，如java、Object-C、JavaScript、Php、Python、Ruby、C#、Clojure，或者Perl语言，更可以使用Selenium WebDriver的Api。Appium支持任何一种测试框架。如果只使用Apple的UIAutomation，我们只能用javascript来编写测试用例，而且只能用Instruction来运行测试用例。同样，如果只使用Google的UIAutomation，我们就只能用java来编写测试用例。Appium实现了真正的跨平台自动化测试。

appium选择了client-server的设计模式。只要client能够发送http请求给server，所以client用什么语言来实现都是可以的，这就是appium及webdriver如何做到支持多语言的。在实际的项目开发中，我们使用的是JAVA客户端作为自动化测试的脚本语言。

Appium元素查找方式

在Appium中我们可以通过driver.findElement() API来查找页面中的元素。该API有扩展的方法使得我们可以通过元素的不同属性来查找。相关API如下：

WX20181228-102212@2x.png

虽然系统提供了这么多的API来帮助我们查找页面中的元素，但是在实际开发及使用过程中，我们是需要尽量优化查找效率，减少查找时间。

元素查找性能排行

各元素性能查找排行高低如下：

Class Name

Accessibility Id

Link Text

Predicate

Class Chain

XPath

注意事项

PS:

（1）我们几乎无法100%的将使用XPath轴的定位串转换成Predicate或者Class Chain（但变通的方法通常都有）。

（2）避免直接调用page source。

（3）当页面包含非常多的页面元素时，XPath查找的性能也会相应降低。而获取 Page source的性能会降低到无法忍受的程度（甚至有可能造成异常）。

缩小搜索的范围 table = driver.findElement(By.accessibilityId('table')); text = table.findElement(By.predicate('type == "XCUIElementTypeTextField" AND visible == 1')) 如果在搜索范围内的UI元素越多，那么搜索花费的时间就会越多，而默认情况下搜索范围是整个页面。通过缩小特定元素的查询范围能够一定程度上优化查找元素的性能，特别是当多个元素的查找都将在同一个根元素下执行的时候。这种策略可以帮助我们提高查询效率。
如果你只想要一个元素，那就不要查询多个元素 table = driver.findElement(By.className('XCUIElementTypeTable')) 通常情况下findElements方法会比findElement花费更多的时间，因为findElement不会遍历这个页面去找出所以匹配查询的页面元素，而是仅仅返回第一个匹配查询的元素。
避免太过通用的匹配方法 By.xpath('//[@="1"]/parent::*')

太过通用的匹配方法就像上面使用的//和@="1"，这需要扫描每个UI元素的所有attributes，无疑这是极度低效的。

如果修改成By.xpath('//XCUIElementTypeCell[@name="1"]/parent::XCUIElementTypeTable')，那查找性能就会提高许多。但是我们永远也不要忘记第一条: 尽量避免使用XPath, 我们转换成如下的classChain将会更好:

By.classChain('**/XCUIElementTypeTable[]')

iOS滚动查找元素实践

在实际开发测试样例的过程中，遇到了iOS和Android滚动查找元素的差异。Android在JAVA中有系统级的API可以直接使用，系统在底层已经为我们处理好了相关实现。如图所示：

WX20181228-104359@2x.png

Android通过uiSelector语法和AndroidUIAutomator API可以快速方便的定位到指定文本的list cell中。但是由于iOS XCUITest框架及Appium 封装的原因，iOS并没有现成可用的API。所以我们必须要自己封装或者找到与Android类似效果的API。

实践过程

首先我们想到的Appium是否提供了相似的API。查阅官方的文档，我们发现有类似的API如下：

WX20181228-105743@2x.png

WX20181228-105752@2x.png

WX20181228-105802@2x.png

WX20181228-105812@2x.png

满怀欣喜的我们一一尝试，然而实际结果却不尽如人意。所有方法虽然可以滚动但是却无法精确的定位到我们所指定的文本中，也或多或少的存在其他问题。再三尝试并失败后，我们选择了放弃系统直接调用的方法，转向自己实现。

以下所有的方案的实现原理都是查找页面元素，判断当前显示的元素中是否包含我们想要查找的元素，如果有则返回该元素，进行后续的操作。如果没有我们则滑动屏幕，继续查找直到找到我们需要的元素为止。

基于以上原理先后出了两套方案：

方案一

WX20181228-110932@2x.png

方案一主要是通过两个for循环先找到最外层的tableView所包含的所有cell元素，然后再遍历所有cell，查找每个cell中元素是否匹配要查找的元素，如果匹配则滑动到对应位置，返回该元素，不匹配则不进行任何操作。

方案二

WX20181228-111616@2x.png

方案二基本就是查找当前页面所有元素是否含有匹配的元素，没有则滑动，有则返回。

通过对以上两套方案的实践与对比，发现方案一在实现效率上比较差，而且相比与第二套方案，第一套存在无法查找第二页的元素等弊端。所以在综合查找效率和优缺点后，我们选择了第二套方案顺利的解决了iOS滚动查找元素问题。

由实践过程得到的知识点

1、Appium在iOS端查找元素的时候，可以得到页面上所有的元素，即使是未在屏幕上显示出来。
2、在父元素中，无法使用find.element()去查找该父元素的子元素。iOS 和android 都有同样的问题。这个感觉应该是bug。

总结

通过该项目的实践，得到的收获就是在遇到问题时要积极思考，在现有方案无法满足需求的情况下要寻求其他解决方案的路径。并且在有多个方案的情况下做好方案的比较，选取最优的方案。