1. 为什么你需要uiautomator2和ATX如果你正在做Android应用的测试尤其是那种需要反复点击、滑动、输入的操作手动一遍遍来不仅效率低还容易出错。我之前带团队的时候就见过测试同学因为重复劳动而疲惫不堪甚至漏掉一些边界情况。这时候自动化测试工具就成了“救命稻草”。在众多工具里uiautomator2和ATX是我个人非常喜欢的一个组合。简单来说uiautomator2是谷歌官方UIAutomator框架的Python封装它让你能用Python脚本直接操控手机点击屏幕上的任何元素。而ATX你可以把它理解为一个更强大的“指挥中心”。它由网易开源不仅封装了uiautomator2还增加了很多实用的功能比如无线连接手机、同时操控多台设备、支持iOS虽然本文聚焦Android以及内置了图像识别等黑科技。这个组合最大的魅力在于“简单直接”。相比一些重量级的测试框架它的学习曲线平缓你不需要搭建复杂的服务端几行Python代码就能让手机动起来。特别适合测试工程师、开发自测或者任何想用脚本解放双手的朋友。我自己的体验是从环境搭建到写出第一个自动化脚本快的话半小时就能搞定这种即时反馈的成就感非常强。2. 手把手搭建你的测试环境光说不练假把式咱们直接从安装开始。这里我会把每一步都拆开讲包括我踩过的一些坑帮你一次成功。2.1 安装Python与必备库首先确保你的电脑上安装了Python建议版本是3.7或以上。打开你的命令行终端Windows用CMD或PowerShellMac/Linux用Terminal。安装ATX框架这是我们的主菜pip install atx这个命令会安装ATX及其核心依赖。有时候网络问题会导致安装慢或失败可以试试加上国内的镜像源比如pip install atx -i https://pypi.tuna.tsinghua.edu.cn/simple接下来安装uiautomator2。ATX虽然内置了它但为了使用一些更底层的特性或者确保版本最新我们通常也会单独安装pip install --pre --upgrade uiautomator2这里的--pre参数允许安装预发布版本--upgrade确保升级到最新。我建议加上因为这两个项目更新挺活跃的新版本往往修复了不少旧版的bug。2.2 初始化你的第一台测试机安装好库之后关键的一步来了在手机上安装必要的辅助服务。找一台Android手机打开“开发者选项”里的“USB调试”模式然后用数据线连接到电脑。在命令行中执行python -m uiautomator2 init这个命令非常关键。它会自动在你的手机上安装两个APP一个叫ATX的守护应用和一个叫com.github.uiautomator的测试服务应用。第一次运行时手机会弹出安装提示你点击确认即可。注意如果这一步卡住或者失败大概率是USB连接有问题。请检查1) 开发者选项和USB调试是否确已开启2) 电脑上是否安装了该手机的USB驱动尤其是Windows系统3) 可以尝试换一条数据线。我在Windows上就遇到过因为驱动没装好折腾了半天。成功之后你会看到命令行输出类似“Successfully init”的信息。这时候其实你已经可以断开USB线了因为ATX支持Wi-Fi连接后面我们会讲到。2.3 安装可视化神器Weditor对于新手来说直接写代码去定位屏幕上的按钮、文本框是一件很头疼的事。这时候就需要Weditor出场了。它是一个基于网页的UI元素查看器可以像“解剖”一样把当前手机屏幕的UI层级结构展示出来并直接获取元素的定位信息。安装它pip install -U weditor安装完成后启动它python -m weditor命令执行后会自动在你的默认浏览器中打开一个本地网页通常是http://localhost:17310。页面左上角需要你输入设备的连接信息。如果是USB连接直接输入127.0.0.1:7912这是默认的USB连接地址并点击“Connect”。如果是Wi-Fi连接则需要输入手机的IP地址和端口例如192.168.1.100:7912。连接成功后你就能在网页上实时看到手机的屏幕镜像点击页面上的任何元素右侧就会显示它的各种属性比如resourceId,text,className,bounds等。写脚本时直接复制这些属性值来定位元素效率提升十倍不止。我刚开始用的时候感觉就像开了“写轮眼”屏幕上的每个元素都无所遁形。3. 编写你的第一个自动化脚本环境准备好了工具也打开了现在让我们来写一段真正的代码让手机自动操作。我们就用原文的例子打开手机“设置”点击搜索框输入“流量”两个字。3.1 连接设备首先在Python脚本中我们需要先初始化设备连接。这里演示Wi-Fi连接的方式这也是ATX的亮点之一。import uiautomator2 as u2 # 方式一通过设备的IP地址连接Wi-Fi连接需确保手机和电脑在同一局域网 d u2.connect(192.168.1.100) # 替换成你手机的IP # 方式二如果只用一台手机且通过USB连接可以简写为 # d u2.connect() # 会自动查找USB设备 # 打印设备信息确认连接成功 print(d.info)运行这段代码如果成功你会打印出一串JSON格式的设备信息包括屏幕分辨率、品牌型号等。看到这个就说明你的脚本已经和手机“握手”成功可以发号施令了。3.2 模拟操作从点击到输入现在我们来模拟人的操作流程解锁屏幕如果需要- 打开设置 - 点击搜索 - 输入文字。# 1. 唤醒并解锁屏幕假设没有密码 d.screen_on() # 点亮屏幕 d.unlock() # 解锁如果设置了密码这里需要更复杂的处理 # 2. 启动“设置”应用 # 方法A通过应用包名和活动名启动最精准 d.app_start(com.android.settings, com.android.settings.Settings) # 方法B如果不知道包名可以先在桌面找到设置图标点击这里需要借助Weditor定位 # d(text设置).click() # 稍等片刻让设置应用完全加载 d.sleep(2) # 3. 点击顶部的搜索框 # 使用Weditor查看到的元素属性进行定位。这里假设搜索框的resource-id是 com.android.settings:id/search_action_bar search_box d(resourceIdcom.android.settings:id/search_action_bar) if search_box.exists: search_box.click() else: # 如果id找不到可以尝试用描述(description)或文本(text)定位 d(description搜索设置).click() d.sleep(1) # 等待搜索界面弹出 # 4. 在搜索输入框中输入“流量” # 同样使用Weditor找到输入框的resource-id input_field d(resourceIdandroid:id/search_src_text) if input_field.exists: input_field.set_text(流量) # 输入文字 print(已输入‘流量’) else: print(未找到输入框) # 5. 等待几秒查看结果然后按返回键退出搜索 d.sleep(3) d.press(back) # 模拟按下返回键 d.press(back) # 再按一次可能退出设置这段代码几乎就是“所见即所得”的翻译。d(定位条件).click()就是点击set_text()就是输入。关键在于定位条件的获取这正是Weditor大显身手的地方。多运行几次你会对这套操作逻辑越来越熟悉。3.3 运行与调试将上面的代码保存为一个.py文件比如first_test.py然后在命令行运行python first_test.py你的手机应该会自动亮屏、解锁如果没密码、打开设置、进行搜索。如果某一步失败了别慌这是常态。首先检查命令行输出的错误信息其次用print语句输出每一步执行前的元素是否存在exists属性最后祭出Weditor重新确认一下元素的属性在你当前的手机系统版本上是否发生了变化。不同品牌的手机小米、华为、原生安卓的设置应用界面可能略有差异定位方式需要灵活调整。4. ATX的核心魔法无线多设备协同测试单台设备的自动化已经能省不少力但ATX真正让我觉得“厉害”的功能是它对多设备无线协同的优雅支持。想象一下你需要测试一个社交APP的群聊功能或者需要同时在不同分辨率的手机上跑兼容性测试一台台手机插线、执行、拔线简直是一场噩梦。ATX让这一切变得简单。4.1 无线连接配置首先确保你的所有测试手机和电脑都在同一个Wi-Fi网络下。在每台手机上重复我们之前做的python -m uiautomator2 init步骤通过USB连一次即可。初始化完成后每台手机都会在7912端口启动一个服务。然后在电脑上你需要获取每台手机的IP地址。一般在手机的“设置”-“关于手机”-“状态信息”里可以找到。假设我们有三台手机手机A: 192.168.1.100手机B: 192.168.1.101手机C: 192.168.1.1024.2 编写多设备操控脚本ATX提供了非常直观的多设备控制方式。你可以同时对所有设备执行相同操作也可以分别控制。import uiautomator2 as u2 import threading import time # 创建多个设备连接对象 devices { phone_a: u2.connect(192.168.1.100), phone_b: u2.connect(192.168.1.101), phone_c: u2.connect(192.168.1.102), } # 示例1同步操作 - 同时在三台手机上打开浏览器 def sync_operation(): print(开始同步打开浏览器...) for name, d in devices.items(): d.app_start(com.android.chrome) # 以Chrome为例 print(f{name}: 浏览器已启动) print(所有设备操作完毕。) # 示例2异步操作 - 使用多线程同时执行不同的任务 def async_operation(): def task1(device, name): device.open_notification() print(f{name}: 打开了通知栏) time.sleep(2) device.press(back) def task2(device, name): device(text相机).click() print(f{name}: 尝试打开相机) time.sleep(3) device.press(back) threads [] # 手机A执行任务1手机B执行任务2 t1 threading.Thread(targettask1, args(devices[phone_a], Phone_A)) t2 threading.Thread(targettask2, args(devices[phone_b], Phone_B)) threads.extend([t1, t2]) for t in threads: t.start() for t in threads: t.join() print(异步任务执行完成。) # 示例3分布式测试同一场景 - 同时测试同一个APP的登录功能 def test_login_across_devices(): app_package com.example.demoapp # 替换成你的APP包名 for name, d in devices.items(): d.app_start(app_package) d.sleep(2) # 假设登录按钮的id是 btn_login if d(resourceIdbtn_login).exists: d(resourceIdbtn_login).click() print(f{name}: 点击登录按钮) # 这里可以继续添加输入用户名密码等操作 d.sleep(1) if __name__ __main__: # 执行同步操作 sync_operation() time.sleep(3) # 执行异步操作 # async_operation() # time.sleep(3) # 执行分布式测试 # test_login_across_devices()通过这种方式你就像一个乐队的指挥可以轻松让多台设备齐奏或分声部演奏。在实际项目中我用它来并行执行安装包安装测试、不同网络环境下的功能验证效率提升非常明显。以前需要一整天才能完成的兼容性测试遍历现在喝杯咖啡的功夫脚本就帮你跑完了。4.3 效率对比单机 vs. 多机我们来算一笔时间账。假设一个测试用例需要执行5分钟。单机串行测试10台设备5分钟 * 10台 50分钟加上手动换机、启动的时间轻松超过一小时。ATX多机并行测试10台设备理想情况下只需要5分钟以最慢的那台为准。这不仅仅是时间上的线性提升。并行测试能更快地发现那些与特定机型、系统版本相关的兼容性问题比如“在小米上正常在OPPO上崩溃”。问题能更早暴露开发修复的周期也就更短。我团队在引入多设备并行测试后版本发布前的全量兼容测试时间直接缩短了60%以上。5. 深入对比uiautomator2/ATX 与 Appium很多朋友会问有了Appium这样知名的“全能选手”为什么还要考虑uiautomator2和ATX呢这里我结合自己多年的使用经验做一个更接地气的对比不罗列概念只讲实际感受。特性维度uiautomator2 / ATXAppium架构与部署轻量级直连设备。就像一个特派员直接和手机上的服务通信。安装简单pip install加init就搞定不需要启动独立的服务端。重量级C/S架构。需要启动一个Appium Server作为中间层再去驱动设备。部署环境相对复杂依赖Node.js和各类驱动。上手速度极快。Python语法直观的API配合Weditor新手半天就能写出可用的脚本。学习成本主要集中在元素定位上。有一定坡度。需要理解WebDriver协议、Desired Capabilities等概念配置项繁多对新手不够友好。执行速度通常更快。因为是直接与Android系统服务通信指令传输路径短执行点击、滑动等原生操作响应迅速。相对稍慢。指令需要经过Appium Server转发多了一层开销在大量快速操作时可能感觉到延迟。多设备支持原生支持且简单。ATX框架层面就提供了多设备连接和控制的便捷方法无线连接稳定是它的核心卖点之一。支持但配置繁琐。需要为每个设备启动不同的Appium Server端口并通过不同的Session管理脚本编写上也需要处理多driver。跨平台ATX支持iOS但主力在Android。ATX虽然通过facebook-wda支持iOS但社区生态和易用性上Android端更成熟。核心优势。真正的“一次编写多端运行”理论上。对iOS和Android的支持都很全面是跨平台测试的首选。元素定位依赖原生属性。主要通过resource-id、text、class-name等。Weditor工具能极大提升定位效率。策略丰富。除了原生属性还支持XPath、Accessibility ID、CSS选择器用于WebView等定位方式更灵活尤其在处理复杂或动态元素时可能有优势。社区与生态活跃但规模中等。中文文档和社区支持不错问题反馈和解决速度较快。极其庞大。全球性的开源社区海量的插件、教程和解决方案遇到任何稀奇古怪的问题几乎都能找到答案。适合场景Android专项测试、快速原型、多设备并行测试、对执行速度要求高的场景。特别适合测试团队内部快速搭建自动化能力。大型企业级测试、跨平台iOS/Android测试、需要与CI/CD深度集成、已有WebDriver技术栈的团队。怎么选呢我的建议是如果你的测试重心是Android应用追求快速上手和高效执行尤其是涉及多设备同步操控那么uiautomator2ATX组合是你的不二之选。它像一把锋利的手术刀精准而高效。如果你面对的是一个庞大的、需要同时覆盖iOS和Android的测试体系或者团队已经熟悉了Selenium/WebDriver那一套那么Appium这个“瑞士军刀”可能更合适。在实际工作中我甚至见过两个工具混用的团队用ATX做Android端的日常快速回归和兼容性测试用Appium来维护那套跨平台的核心冒烟测试用例。6. 实战进阶技巧与避坑指南用了这么久我也积累了一些能让脚本更健壮、开发更顺畅的实战技巧以及一些常见的“坑”在这里分享给你。技巧1使用更稳定的定位策略不要过度依赖text属性因为文字可能变化或者被国际化。优先使用resourceId它是开发同学在代码中赋予控件的唯一ID最稳定。如果都没有可以考虑使用className结合instance第几个同类元素或者使用相对定位、兄弟定位等高级语法。# 不推荐依赖可能变化的文本 d(text登录).click() # 推荐使用稳定的resourceId d(resourceIdcom.xx.app:id/btn_login).click() # 次选类名索引 d(classNameandroid.widget.Button, instance0).click()技巧2给操作加上等待和重试机制手机应用加载有快有慢网络有时不稳定。直接操作很容易因为元素没加载出来而报错。一定要使用显式等待。# 等待某个元素出现最多等10秒 d(resourceIdtarget_id).wait(timeout10.0) # 等待元素出现后再点击 d(resourceIdtarget_id).wait(timeout10.0).click() # 更灵活的重试操作 def click_with_retry(element, retries3): for i in range(retries): if element.exists: element.click() return True else: print(f元素未找到第{i1}次重试...) time.sleep(1) print(重试多次后仍未找到元素) return False click_with_retry(d(text确认))技巧3利用ATX的图像识别辅助定位有些时候界面元素是图片或者自定义视图没有标准的属性。ATX集成了图像识别功能可以派上用场。# 首先在目标设备上截取一张小图作为模板保存为‘target.png’ # 然后在脚本中匹配 pos d.image.match(target.png) # 在屏幕中查找该图片 if pos: d.click(pos.x, pos.y) # 点击找到的图片中心坐标这个功能在测试游戏或者一些非标准控件时特别有用。常见坑与解决方案坑1init失败提示Timeout或Connection refused。这几乎都是USB连接问题。确保驱动安装正确可以试试adb devices命令看是否能列出设备。有时需要重启adb服务adb kill-server adb start-server。坑2脚本在电脑上运行正常放到服务器上跑就失败。很可能是因为服务器是Linux系统而你的脚本里包含了Windows特有的路径或操作。另外服务器上的Python环境、依赖库版本也需要保持一致。建议使用requirements.txt管理依赖。坑3多设备测试时某台设备突然没反应。无线连接毕竟受网络波动影响。可以在脚本开头加入设备状态检查如果连接断开则尝试重连或者记录日志方便排查。for name, device in devices.items(): try: device.info # 尝试获取信息如果断开会抛异常 except Exception as e: print(f{name} 连接异常尝试重连...) devices[name] u2.connect(device_ip) # 重新连接坑4升级系统或APP后脚本大面积失效。这是自动化测试的常态。应对方法是1) 元素定位尽量使用最稳定的属性2) 将定位信息如resourceId抽离到单独的配置文件中方便统一修改3) 建立脚本的定期维护机制。说到底自动化测试脚本不是一劳永逸的它需要随着产品的迭代而维护。但前期投入的时间会在无数次的回归测试中加倍回报给你。从打开第一个Weditor到成功指挥十台手机同时运行用例这个过程本身就充满了工程师的乐趣。