前言

ATX 的 QQ 群里的新人经常会提一些问题,像 “Appium 是这样用的,ATX 该怎么实现呢?”。为了省去每次新人入群都要回答一遍的麻烦,所以写了这么一篇文章。

为什么不用 Appium,要用 ATX 了?

群里面的人这样说的

  1. 运行速度快,比 Appium 运行速度快了好多。(用户表示不知道 ATX 为什么快,PS(作者): 我其实也不知道 appium 为什么这么慢)
  2. 部署和使用比较简单(当初就是朝着这个方向开发的)

    最开始笔者在部署 appium 的时候,花了一整天的时间,最终还是部署好了。但后来还是放弃了,因为想到要部署这么多台机器,还不如自己开发一个测试框架来的方便(当时的需求也比较简单)

ATX 发展史

一开始的 atx 只是一个简单的 python 库,功能简单,还有不少的 bug,用户也不多。然而就是有这么一批死党,经常性的提 Issue,提 PR,还有社区的鼓励和宣传。让这个项目不断的向前。bug 也来越少,功能也越来越多。从原有的只支持 Android,后来又支持了 iOS。从原有的需要借助 uiautomatorviewer 来查看视图,后来又有了自己的 weditor 视图分析工具。从原有的需要借助 USB 才能连接手机,到现在可以支持无线连接手机。从原有的只能单机操作,到现在的支持远程控制,集群处理。
atx 的功能的越来越强,也终于让我们有底气出了这么一篇文章。

使用限制

Appium 基本上什么安卓版本都支持,各种语言的客户端。
ATX 只支持 Android 4.4+,仅 Python 语言。

Appium 支持的语言多,既是优势但同时也是包袱。每一个功能的新增或修改都可能要涉及到修改所有的客户端代码,维护成本实在是高。
ATX 选择 Python 最大的原因还是因为写起来方便,因为只维护一个语言版本,更新起来非常方便。

安装区别

提到安装首先需要先理解下 Appium 的架构

Appium, 其中的 Appium Server 是运行在 PC 端的

ATX,其中的 ATX-Agent 则是运行在手机端的。

appium的安装通常为以下几步

之后把手机接到电脑上,appium 会自动把各种程序安装到手机上(PS: 每次自动化的时候安装,感觉好奇怪)。

atx的将安装步骤精简了不少

手机接到电脑上之后,需要先运行一下命令 python -m uiautomator2 init将需要的程序部署到手机上,以便后续的自动化(PS:每个手机初始化一次就够了)。

参考:https://github.com/openatx/uiautomator2#installation

appium desktop 与 atx weditor

Appium Desktop 是一个单独的安装包,自带了一个 NodeJS 写的客户端作为 Inspector,可以方便的看到当前 UI 的布局信息,用来方便的写自动化代码。

ATX Weditor 是一个 python 库,命令行安装 pip install --pre weditor , 命令行启动(PS: windows 可以双击 weditor 快捷方式),会自动打开一个网页,用网页作为其 Inspector
如图所示

连接设备

appium 需要构造一个 desiredCapabilities,其中的 udid 字段通常对应设备的序列号。
以一个常见的配置文件为例

{
  "platformName": "Android",
  "deviceName": "vivo",
  "udid": "cff37bce3",
  "appPackage": "com.netease.cloudmusic",
  "appActivity": ".activity.LoadingActivity",
  "noReset": false,
  "unicodeKeyboard": true,
  "resetKeyboard": true
}

atx 没有这类配置文件,必需的字段只有一个就是设备的序列号。其他的都是可选的。对于是否启动应用给用户提供了的选择权。
将其翻译为完整的 atx 代码为。

import uiautomator2 as u2

d = u2.connect("cff37bce3")
d.set_fastinput_ime(True)
s = d.session("com.netease.cloudmusic")

这里省略了 appActivity,因为 atx 会自动解析出来相应的 appActivity。fastinput_ime是专门为自动化定制的输入法,支持中文的输入,和一些特殊的指令如搜索,清空。
d.session 函数对应于 appium 的 session 机制,每次运行相关代码的时候都会先检测一下应用是否存活。

注:atx 连接的时候可以填手机的序列号或者 ip 地址。因为测试代码最终是与手机上的一个服务的 atx-agent 通信,所以也支持填写 IP,但是需要运行代码的电脑跟手机在同一个网段。

控件的选择与操作

appium 常用定位元素的方法为find_element_by_xpath, find_element_by_id, find_element_by_text
一种常见的写法为

driver.implicitly_wait(10) # 设置元素的查找时间10s
element = driver.find_element_by_text("Settings")
if element:
    element.click()

转化成 atx 代码为

d(text="Settings").click(timeout=10)

atx 通常来说不推荐用 xpath,因为要 dump 所有的 hierarchy,速度比较慢。推荐用的时候各种查询条件混合一起使用。
典型的用法为

d(className="android.widget.Button", textContains="登录").click()
# using xpath
d.xpath('//android.widget.Button[contains(@text, "登录")]').click()

参考: https://github.com/openatx/uiautomator2#selector

弹框的处理

现在高版本的手机基本都会有一些权限确认窗口或者安装确认框。如果处理不好会非常影响自动化。

看到一个帖子说是可以配置一下就可以解决弹框了(PS:应该是只针对 iOS 的)https://testerhome.com/topics/14513

driver.switch_to.alert.accept()

atx 的方法更自由一点,你可以自由选择处理什么内容的弹窗,以及怎么处理。一个常见的自动点击安装按钮的方法

d.watcher("INSTALL").when(text="安装").click()
d.watcher("NEXT").when(text="下一步").click()
d.watchers.watched = True

Toast 的支持

appium 获取 toast 内容的代码我暂时没有搜索到,验证是否存在的倒是有

WebDriverWait wait = new WebDriverWait(androidDriver, 3);
WebElement toastView = wait.until(ExpectedConditions.presenceOfElementLocated(
          By.xpath(".//*[contains(@text,'" + toast + "')]")));

atx 是通过 accessibility 捕获到的 toast 内容,然后通过接口直接获取 toast 内容,至于怎么验证,交给脚本编写者来弄。
代码

# show toast action
message = d.toast.get_message()
assert "Success" in message

除了捕获 toast,还可以显示 toast d.toast.show("Hello world")

后续阅读

上面说的很多内容都被我一笔带过,说的不是很详细。其实这篇文章就只是想让你初步的了解一下 appium 与 atx 之间使用的区别。
想真的的用起来,我还是推荐你把 atx 中 uiautomator2 首页的文档通读一遍(如果你天资够好,10 分钟应该就够了)https://github.com/openatx/uiautomator2

贡献代码

atx 是一个全开源的项目,发展的现在已经接收了很多人的贡献。有的人喜欢提 Issue,有的人提 PR(Pull Request)比如 xpath 的支持,常见的 bug 修复。联想手机的支持,等等。
贡献代码其实很简单,Fork 一下项目,把觉得有问题的地方修复,或者想新增一些功能,git push 上去,然后 github 界面上点击下 pull request 就可以了。


↙↙↙阅读原文可查看相关链接,并与作者交流