ATX 使用 Yaml 来做自动化测试 (Beta)

codeskyblue · 2018年09月04日 · 最后由 思寒_seveniruby 回复于 2018年09月07日 · 2398 次阅读

背景

测试版本警告,目前功能这个功能刚写出来没多久,并不保证稳定。

ATX中的python-uiautomator2目前来说还是以纯Python为主, 基本上都是过程式的写法,判断逻辑也都比较简单。
前段时间学习了思寒 @seveniruby 大佬的 appcrawler,发现用yaml写测试脚本获取是个很好的方法。

不了解yaml的看这里 YAML教程

实践和使用说明

本地的uiautomator2库先升级到最新。

要实现的功能:打开网易云音乐,搜索周杰伦,播放布拉格广场,验证播放按钮存在

原生Python写法

import uiautomator2 as u2
d = u2.connect()
d.set_fastinput_ime(True)
d = d.session("com.netease.cloudmusic")
if d(text="跳过").exists(timeout=5):
d.click(text="跳过")
d(description="搜索").click()
d.send_keys("周杰伦")
d.press("enter")
d(textContains="布拉格广场").click()
assert d(description="播放暂停").exists(timeout=5)

保存成文件test.py 然后 python test.py 运行测试

Yaml格式写法

---
title: 网易云音乐测试
packageName: com.netease.cloudmusic
steps:
- q: //*[@content-desc="搜索"]
- text: 周杰伦
- q: 布拉格广场
- q: 播放暂停
action: assertExists
watchers:
- q: 跳过

保存成文件test.yml,然后python -m uiautomator2.cli runyaml test.yml 运行

Yaml文件的好处

  • 脚本更简单和直观
  • 使用非常少的接口dump_hierarchy, click。稳定性更好。

    先通过dump_hierarchy接口获取界面xml,然后通过lxml库分析所有组件的位置,调用click完成操作。

  • 脚本运行的时候顺便输出日志,方便调试

  • 性能数据、执行截图可以顺便一起做了(当前现在还没实现)

Yaml用例运行时的日志输出

[I 180904 16:38:57 runyaml:119] Test begins: 网易云音乐测试
[I 180904 16:38:57 runyaml:120] launch app: com.netease.cloudmusic
[I 180904 16:39:02 runyaml:128] ==> {'query': '//*[@content-desc="搜索"]'}
[I 180904 16:39:02 runyaml:87] click: (940, 1602)
[I 180904 16:39:02 runyaml:56] trigger watcher: {'timeout': 0, 'query': '跳过'}
[I 180904 16:39:04 runyaml:87] click: (1008, 156)
[I 180904 16:39:04 runyaml:128] ==> {'text': '周杰伦'}
[I 180904 16:39:05 runyaml:45] input text: 周杰伦
[I 180904 16:39:07 runyaml:128] ==> {'q': '布拉格广场'}
[I 180904 16:39:08 runyaml:87] click: (123, 1194)
[I 180904 16:39:09 runyaml:128] ==> {'q': '//*[@content-desc="播放暂停"]'}
[I 180904 16:39:10 runyaml:87] click: (540, 1773)
[I 180904 16:39:11 runyaml:130] Finished

yaml具体配置

title随便写
packageName写了之后会调用session函数启动应用
steps包含每一个操作步骤
点击操作的完整的写法如下

- action: click
query: //*[@resource-id="tvb"]
timeout: 10

因为action默认就是click,timeout默认10s,query可以简写成q, 所以可以简写成

- q: //*[@resource-id="tvb"]

如果q以/开头代表代表xpath, 如果是字符串,则会按照正则匹配没有元素的text字段

实现输入的写法

- text: 要输入的内容

运行Python代码的写法

- action: python
code: |-
print("Hello world")

断言的写法

- action: assertExists
q: 天气

watchers这个字段的存在是为了方便点击弹窗,写法跟steps类似,区别就是query字段在这里是必须的,timeout默认0s

在每次操作step之前,都会先将hierarchy经过watchers处理。

后话

目前还只是Beta版,可以会有Bug,可能功能还不完善,欢迎大家提意见,我们来一起把它完善了。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 19 条回复 时间 点赞

你算上道啦。基于page source的定位方式比传统的webdriver api要灵活很多,我在新版本的appcrawler里增加了一个填写xpath定位自动在后台转成id定位的功能,用xpath和id定位其实已经速度上是一致的了。其次才是yaml格式带来的灵活配置。

最近我在帮客户做兼容性测试,发现了各家测试平台都不怎么支持appium,目前也在想办法适配atx或uiautomator2 server。目前appium后台开发的uiautomator2 server貌似不兼容标准的selenium client,用的是短连接请求。你是没用selenium自己完全封装的?

恩,没用到selenium

如果xpath转成id 那原来的triggerAction还会生效吗

代码写习惯了觉得代码才是最灵活的,如果这种框架不是自己开发的,往往遇到问题不知道如何解决很费时间。
当然,如果自己有能力,我觉得可以参考这种思想,自己弄一个出来自己用。

我想知道,逻辑计算之类的判断该怎么处理

hello 回复

可以在里面用Python代码的

codeskyblue 回复

哦哦,原来如此~

yaml之前都不知道为何物

codeskyblue 回复

会生效的,机制不一样,只有当需要对具体元素做操作的时候,才会生成api定位。而且失败了还会自动用xpath再重新定位一次确保万无一失。

codeskyblue 回复

因为appium和selenium的java client都没法支撑uiautomator2 server,导致我的appcrawler也没法直接使用uiautomator2 server。你的atx有java或者其他的接口可以调用嘛?实在没办法我也只能再封装个uiautomator2的client了。

有的有的,get page source的接口,或者click,swipe的接口。https://github.com/openatx/uiautomator2

先收藏,等稳定了再使用,楼主是大神!!!

yml的内容管理,缩进报错特别蛋疼,定位错误很麻烦。我们之前拿来管理测试数据用。楼主用yml记录操作行为,有点关键字驱动的味道

操作步骤yml还好 无非做好默认搜索方式然后多次猜测来简化用户表达 不过验证逻辑yml就蛋疼了
想到还有用excel写步骤的 其实和yml差不多
这种case描述最好大家能协作模块化 这对无论什么ui自动化工具都是类似的 是前端 比如u2和appcrawler统一一个格式
验证要考虑考虑 嵌入yml就意味着咬死一个语言了 可能无法跨工具通用

appcrawler总算要有新版本了
@seveniruby u2包了一个jsonrpc的东西 那个本来也是java写的 应该可以直接调

如果封装好 还好 不过 因为 大部分都是自己搞 所以 懒得 维护呢

666,UI点击炒鸡快准

AppetizerIO 回复

理想的配置应该是类似gradle这种基于编程模型的dsl,不过目前java和python中还没有找到特别优雅的实现。

AppetizerIO 回复

新版本偷偷发布到了分支里了,没敢往master里合并。图像识别还没充分测试,一直不满意。再加配置精简了新老版本不兼容,一直没信心对外发布。

codeskyblue 专栏文章:2018年 终总结 中提及了此贴 02月18日 10:26
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册