Appium 常用操作API

移动手势的自动化

尽管 Selenium WebDriver 的规范已经支持了一些移动交互,但它的参数并不总是那么容易地 映射到底层设备的自动化框架所提供的方法上（比如 iOS 上的 UIAutomation）。为此，Appium 在最新的规范(https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#multiactions-1) 中实现了新的触摸操作和多重操作 API。

注意，这与早期版本中原始的 JSON Wire 协议里的触摸操作 API 不同。

这些 API 允许你使用多个执行器去建立任意的手势。 请查看对应语言的 Appium 客户端文档来查看使用这些 API 的示例。

触摸操作(TouchAction)/多重操作(MultiAction) API 概述

触摸操作(TouchAction)

TouchAction对象包含一连串的事件。

在所有的 appium 客户端库里，触摸对象被创建并被赋予一连串的事件。

规范里可用的事件有：

短按(press)

释放(release)

移动到(moveTo)

点击(tap)

等待(wait)

长按(longPress)

取消(cancel)

执行(perform)

这是一个使用伪代码创建一个动作的示例：

上述模拟了一个用户按下一个元素，滑动他的手指到另一个位置，然后将他的手指从屏幕上移开。

Appium按顺序执行这些事件。你可以添加事件来控制事件的时长。

的坐标与当前的位置相关。举例来说，从 100,100 拖拽到 200,200 可以这样实现:

Appium 客户端库有不同的实现方式，举例来说:你可以传递坐标或元素给事件。当坐标 和元素一起传递时，该坐标是相对于元素位置的相对坐标，而不是相对于当前位置。

调用事件发送全部的事件序列给 appium，触摸手势就会在你的设备上执行。

Appium客户端也允许通过 driver 对象直接执行触摸操作，而不是在触摸操作对象上调用事件。

在伪代码里，以下两者是相等的：

多点触控(MultiTouch)

MultiTouch对象是触摸操作的集合。

多点触控手势只有两个方法，和。

用于将不同的触摸操作添加到当前的多点触控中。

当执行时，被添加到多点触控里的所有触摸操作会被发送给 appium 并被执行，就像它们 同时发生一样。Appium 会按序一个个执行触摸事件，首先第一个事件，然后第二个，以此类推。

用两只手指点击的伪代码示例：

缺陷与解决方法

不幸的是，在iOS 7.0 - 8.x 的模拟器上存在着一个缺陷，ScrollViews、CollectionViews和TableViews不能识别 UIAutomation（Appium在iOS底层所使用的框架）所创建的手势。为了避免这些，我们已经提供了一个可用的新函数，它在大多数情况下能让你完成你想在这些 view 中的任意一个上去做的事，也就是，滚动它！

滚动

为了允许使用这个特殊的手势，我们重写了 driver 的和方法，并且给命令 加上前缀。 看下面的示例：

为了进行滚动，将你想滚动的方向作为参数传入。

使用方向和元素进行滚动的示例。

Swiping

在 XCUITest 驱动上有一个特别的方法，和 scrolling 类似。(见 https://developer.apple.com/reference/xctest/xcuielement)。

这个方法的名字和Scrolling的 API 一样，只要用 "mobile: swipe" 替换 "mobile: scroll"。

滑块的自动化

iOS

Java

Android

在Android上与滑块交互的最佳方式是使用触摸操作。

uiautomator UiSelector

Appium 使用UiSelectors来进行查找。 同时也支持UiScrollable。

注意，根据索引查找并不可靠，所以更应该使用实例(instance)。后续的示例是使用 Ruby 来测试 api demos apk。

查找第一个 textview。

根据文本查找第一个元素。

查找第一个可滚动(scrollable)的元素，然后根据文本"Tabs"查找第一个 TextView。 "Tabs"元素将被滚动到可见范围。

作为一个特例，scrollIntoView 返回的是被滚动到可见范围的元素。 scrollIntoView 允许滚动到任意的 UiSelector。

多语言支持

编程语言在处理非拉丁字符时候有一个问题，带重音符号的字符有多种编码方式。比如， 字母，有两种编码：一个单字符(Unicode的（带有尖标的小写拉丁字母E）)和字母后跟上音标的组合(（组合尖音标）)。为了解决这个问题，就有了，一种让"相同的字符串有一个唯一的二进制表示"的运算。

幸运的是，对ASCII文本（即不需要再被标准化的文本）进行标准化不会引起任何变化，且执行多次运算也不会有副作用。 因此，这个标准化函数在文本上调用不会有副作用的风险。

因此，当处理测试中的unicode文本时，你最好对预期的文本和从Appium接收到的文本都进行标准化。 进行标准化的方式有很多种，所以要确保对两边的字符串执行相同的运算！

问题的端倪是对编码后的unicode文本的断言失败但从报告上看，却是相同的字符串：

由于问题仅仅是编码，输出看起来一样。 标准化后，他们在程序里应该像看起来一样是相等的。

查找器(Finders)

通过文本查找时也可能需要标准化。举例来说，如果你在一个iOS应用里有一个名叫的按钮， 你需要在查找命令里标准化文本。

否则这个元素会找不到。

文本框(Text Fields)

默认情况下，iOS和Android的自动化工具都不支持通过键盘向可编辑的区域输入non-ASCII字符。

iOS

Appium完全绕过键盘直接向iOS可编辑区域发送non-ASCII字符。虽然这样在测试中允许了文本的输入，但 必须记住的是任何通过键盘输入触发的业务逻辑都没有被测试到。

如上所述，接收到的文本在被断言前需要被标准化。

Android

Android测试通过安装和使用一个特殊键盘来允许Unicode输入，它允许将文本像ASCII一样在Appium和被测应用间传递。

为了使用这个功能，将desired capability设置为。如果键盘需要被还原成初始状态， 将desired capability也设置为。不然设备上的Appium的Unicode键盘将会在测试完成后留用。

之后就可以通过使用向可编辑区域传递Unicode文本。

END