UI-TARS 教程:3 步跑通 Android 零代码自动化测试完整指南
【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS
不会写元素定位器,也能做 Android 自动化测试吗?UI-TARS 是一个基于视觉语言模型的开源自动化智能体,主打零代码测试:它直接看截图、用一句自然语言理解界面,并输出可执行的操作代码。在 Android World 基准上它取得 64.2 分,高于此前最佳的 59.5 分。本教程带你用 3 步完成从安装到跑通完整流程的搭建过程。
谁需要它:零代码测试的三类典型场景
如果你的工作命中下面任何一种情况,UI-TARS 值得试试:
- 回归测试维护成本高:测试团队依赖 Appium 或 Espresso,UI 一改,定位脚本就要跟着改。UI-TARS 靠看截图识别控件,界面小改动的代价明显更低。
- 跨设备兼容性验证:需要在多台模拟器或真机上跑同一套流程,分辨率各不相同。它的坐标系统会自动适配不同分辨率,不用逐台写适配逻辑。
- 非开发人员做轻自动化:产品、运营或 QA 想用一句话描述测试步骤,让系统替自己执行,而不必先学会一套自动化框架。
UI-TARS 是什么:不依赖元素 ID 的核心能力
一句话概括:UI-TARS 是一个"看屏幕、再决定做什么"的多模态智能体,底座是视觉语言模型。对测试工作真正有用的能力有四点:
- 视觉定位界面:不需要元素 ID、不需要可访问性树,直接从当前截图里找到目标控件。
- 自然语言下指令:用大白话描述测试步骤,例如"打开电商应用,搜索机械键盘",不必学习任何 DSL。
- 移动端专属动作模板:内置 MOBILE_USE 模板,覆盖手机场景的常用指令——
open_app启动应用、press_home回主屏、press_back返回键、long_press长按、swipe滑动(拖拽)。 - 输出可直接执行:模型输出能被解析成结构化动作,再生成可运行的 pyautogui 脚本;坐标随原始屏幕分辨率自动换算。
三步跑通环境:从安装到验证
第一步:一键安装解析包
模型本体的部署方式见 README_deploy.md,测试链路里真正高频使用的轻量后处理包,一行命令即可装上:
pip install ui-tars第二步:配置测试对象
- 启动 Android 模拟器,或连接开启 adb 调试的真机。
- 记下设备屏幕分辨率(如 1080×1920),后续坐标解析要用这两个参数。
第三步:最小示例验证
下面的代码能打印出结构化动作,说明环境已就绪:
from ui_tars.action_parser import parse_action_to_structure_output response = "Thought: Click the search box\nAction: click(point='<point>500 300</point>')" parsed = parse_action_to_structure_output( response, factor=1000, origin_resized_height=1920, origin_resized_width=1080, model_type="qwen25vl", ) print(parsed)一个完整工作流演示:自动完成商品搜索
拿电商里最常见的任务走一遍:打开应用 → 搜索"机械键盘" → 点开第一个结果 → 加入购物车。
第 1 步:用自然语言写任务。用 MOBILE_USE 模板(定义在 codes/ui_tars/prompt.py)拼好提示词,任务描述就是一句人话:"打开电商应用,搜索'机械键盘',点开第一个商品,点击加入购物车。"
第 2 步:模型返回"思考 + 动作"。面对每一帧截图,模型先输出一行推理(Thought),再给出一个动作(Action),比如click(point='<point>500 300</point>')。
第 3 步:解析动作并适配坐标。模型输出的坐标是相对缩放后图像的,parse_action_to_structure_output会按你传入的原始分辨率把它换算回真实屏幕位置。下面这张原图就是解析前用于定位的截图:
换算后的落点用红点标回截图上,效果如下,可以直观确认点得准不准:
第 4 步:生成脚本,闭环执行。最后把结构化动作转成 pyautogui 代码,执行循环就是"截图 → 模型推理 → 解析 → 执行动作 → 再截图":
from ui_tars.action_parser import parsing_response_to_pyautogui_code code = parsing_response_to_pyautogui_code( responses=parsed, image_height=1920, image_width=1080, )循环一旦接通,换个任务描述就能复用到下单、发布内容、填写表单等流程。
它是怎么做到的:三层结构背后的 Android 自动化智能体
别把 UI-TARS 当成"识别 + 点击"的简单两步。从内到外它是三层结构:
- 底层是环境:模拟器或真机承担真实用户的操作环境角色——提供截图、执行点击与输入,并回传新的界面状态。
- 中层是核心模型,由四个模块协同:感知负责元素描述与屏幕文字识别;动作把各类操作统一到一个动作空间里,并支持多步轨迹;推理让模型先想清楚再动手;学习通过轨迹自举、Agent DPO 等手段持续优化模型表现。
- 上层是人机交互:你用自然语言下达指令,随时可以观察中间过程并修正方向。
"先想后做"的设计也解释了它为什么比纯模板匹配更稳:界面变了,模型会基于新画面重新推理,而不是照着旧脚本盲点。
数据说话:Android World 拿到 64.2
Android 场景里最关键的数字是:UI-TARS 在 Android World 基准上得 64.2 分,此前 SOTA 为 59.5 分。其他测试项上它的成绩也值得一提:
- 桌面操作 OSWorld:42.5 分
- GUI 元素定位 ScreenSpotPro:61.6 分(此前 SOTA 43.6 分)
和 Appium/Espresso 手写定位器的传统路线相比,它的价值不只是分数:不依赖元素 ID 树意味着 UI 改动后通常不用整体重写脚本,跨设备、跨应用的维护成本更低。
稳定性与避坑:Android 自动化测试的四个高频问题
- 坐标偏了怎么办:先核对解析时传入的分辨率参数是否和真实截图一致。坐标系统就是按这两个数做比例换算,参数错了点就会按比例偏。
- 动态界面不稳定:关键步骤之间加短暂等待,重要操作失败后重新截图再试。动作空间里本身就提供了
wait类动作可供使用。 - 个别元素识别不到:换一张更清晰的截图,或在指令里把元素特征写具体一点——位置、颜色、旁边有什么文字。
- 不要完全信任模型:官方也把"幻觉"列为已知局限,模糊界面上模型可能误判元素。断言环节建议加一次截图复核,确认结果后再下结论。
写在最后 & 资源导航
一句话总结:UI-TARS 把 Android 自动化测试里"定位元素、维护脚本"的部分换成了视觉理解,让零代码测试变成一条可复现的路线。三步搭好环境,一段自然语言描述就能跑完完整流程,足够你先把手上的回归用例迁移过来。
想继续深入,资料都在仓库里:
- 项目总览与快速开始:README.md
- 模型部署指南:README_deploy.md
- 坐标处理教程:README_coordinates.md
- 核心源码(提示词模板与动作解析器):codes/ui_tars/
- 测试消息示例数据:data/test_messages.json
- 需要完整源码时:
git clone https://gitcode.com/GitHub_Trending/ui/UI-TARS
【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考