UI-TARS零代码测试实战3步跑通Android自动化测试的10分钟【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS上周四我接手了一个App的回归测试200多条用例手机端每条都要手动点开、输入、截图确认。后来我试着用 UI-TARS 跑 Android 自动化测试把自然语言指令直接喂给模型它输出点击坐标和 pyautogui 脚本全程不用写一条元素定位代码。下面按测试同学能直接照做的顺序讲讲这套东西怎么运转、我踩过哪些坑。场景200条回归用例手动点到哪算哪传统流程里Appium 脚本要维护 resource-idEspresso 要熟悉框架 APIUI 一改脚本就批量失效。我们组当时一个页面改版200 条用例里有 40 多条定位全部报错修定位花了一整天。我想要的其实是给一张截图和一句点登录按钮机器自己找到按钮在哪。这正是 UI-TARS 这类 GUI Agent 的思路——不读页面结构直接看图。项目定位UI-TARS是什么Android World上能考多少分UI-TARS 是字节 Seed 团队开源的、基于视觉语言模型的 GUI 自动化 Agent仓库里包含模型部署方案、codes/ui_tars/解析库和坐标处理工具。它的动作空间统一桌面端有 COMPUTER_USE 模板移动端有 MOBILE_USE 模板模型先输出 Thought推理过程再输出 Action动作函数调用解析库再把文本变成可执行脚本。数据直接引用官方 README 的 Online Benchmark 评测表UI-TARS-1.5 模型Android World 得 64.2此前 SOTAOS-Atlas-7B为 59.5OSWorld100 步得 42.5OpenAI CUA 为 36.4元素定位基准 ScreenSpot-V2 得 94.2。开源的 UI-TARS-1.5-7B 可免费部署部署指南 建议配 L40S 48G 显存的实例。适合谁想摆脱脚本定位维护的测试工程师、评估 GUI Agent 的研究者以及要给自己的业务搭 GUI 自动化流水线的团队。环境准备adb调试怎么配ui-tars解析库怎么装前置条件有三样Android 真机或模拟器开启 adb 调试adb devices能看到设备拿到设备当前屏幕分辨率后面解析坐标要传这个数Python 3.8官方解析库一条命令装好pip install ui-tars # or uv pip install ui-tars装完后 Python 里可直接import ui_tars核心代码在仓库的codes/ui_tars/目录。模型本身不在仓库里需要按 README_deploy.md 把 UI-TARS-1.5-7B 部署成 API 服务HuggingFace Endpoint 或本地推理框架都行拿到模型的文本输出。需要样例数据和测试脚本的话仓库可克隆git clone https://gitcode.com/GitHub_Trending/ui/UI-TARS。本文重点讲模型吐出文本之后怎么把它变成动作这一半。核心工作流MOBILE_USE模板怎么喂模型输出怎么解析运行逻辑是输入、处理、输出三段。输入端一张截图 一句自然语言任务描述提示词由codes/ui_tars/prompt.py里的模板生成。Android 设备用 MOBILE_USE 模板它的动作空间除了 click、type、scroll、drag还有移动端专属的open_app、press_home、press_back、long_press、finished。处理端视觉语言模型看到截图后先输出 Thought 再输出 Action格式固定为函数调用例如click(start_box(197,525))。输出端codes/ui_tars/action_parser.py的parse_action_to_structure_output把文本解析成结构化字典内部用 smart_resize 做坐标换算——模型内部会把图片缩放到 28 的倍数分辨率再看所以坐标必须换算回原图尺度接着parsing_response_to_pyautogui_code生成 pyautogui 脚本。先看第一步解析模型原始输出from ui_tars.action_parser import parse_action_to_structure_output response Thought: 点击确认按钮\nAction: click(start_box(197,525)) parsed parse_action_to_structure_output( response, factor1000, origin_resized_height1080, origin_resized_width1920, model_typeqwen25vl)运行后得到一个列表每个元素是含thought、action_type、action_inputs的字典其中start_box已换算成 0~1 之间的归一化坐标。第二步把结构化动作转成可执行脚本from ui_tars.action_parser import parsing_response_to_pyautogui_code code parsing_response_to_pyautogui_code(parsed, image_height1080, image_width1920) print(code)输出的是一段 pyautogui 脚本开头import pyautogui中间以注释形式保留了 Observation 和 Thought结尾是形如pyautogui.click(196, 519, buttonleft)的语句保存下来即可在模拟器或 adb 设备驱动上执行。关于坐标怎么换算的仓库带了可视化脚本codes/tests/inference_test.py跑完会把模型指的位置用红点画回原图红点落在目标元素上说明分辨率参数传对了偏了就是下面坑里说的第一条。能力边界擅长什么、不擅长什么和Appium差在哪性能对比数据来自论文图表UI-TARS-72B/7B 相对此前 SOTA 的相对提升维度UI-TARSAppium / Espresso定位方式截图像素 视觉理解resource-id / 元素树UI 改版后样式、元素位移只要截图可辨通常仍能找到属性一改定位批量失效编写门槛自然语言描述任务即可需掌握定位语法与框架 API简单固定流程每步都要过模型慢且偶发漂移更快更确定失败可精确定位到行已知短板复杂/模糊界面偶发误识别官方 Limitations 明确列出幻觉问题跨 App 复用差页面维护量大两点需要说清开源 7B 版在部分游戏场景的优化弱于 72B 版README 的 Limitations 一节原话是 7B 未专门针对游戏场景优化长流程里单步成功率会被逐步放大成整体失败率所以回归场景建议每步动作后加截图校验而不是只信点了。实测记录我完整跑了一遍坐标解析流程环境是 Linux 桌面 1920×1080 的截图仓库自带的 GIMP 示例图第一次跑codes/tests/inference_test.py我没核对分辨率参数坐标算出来红点明显偏出Color Management选项一小截。后来明白原因模型内部把 1920×1080 经 smart_resize 放大到 1932×109228 的倍数换算回来本来就有 1~2 像素舍入差我传的截图分辨率又和示例图不一致两者叠加偏移就大了。改成传真实分辨率后重跑终端输出$ python codes/tests/inference_test.py Original coordinate: 1920, 1080 Resized dimensions: 1932, 1092 (195, 519)三行依次是原图分辨率、模型内部缩放分辨率、换算回原图的点击坐标。再把同样输入交给解析库生成的 pyautogui 片段是pyautogui.click(196, 519, buttonleft)——和 195 差 1 像素来自 int 截断与 round 取整两种取整方式点击场景完全可以接受。跑通之后整个解析链路在我这边单次耗时在毫秒级瓶颈全在模型推理上。踩坑记录4个常见现象、原因和解法现象解析后点击位置明显偏移红点不在元素上。 原因origin_resized_height/width传了默认值或错误值或model_type选错qwen25vl 输出绝对坐标doubao 系输出point相对坐标两条换算路径不同。 解法传截图的真实分辨率并指定对应model_type解析前先跑codes/tests/inference_test.py看红点是否落位。现象同一套流程换一台分辨率不同的设备坐标就漂了。 原因坐标系绑定当时截图的分辨率smart_resize 的结果也随之变化。 解法换分辨率后必须重新截图、重新传当前分辨率不要缓存旧坐标设备列表里把分辨率信息一并记录。现象type输入中文时脚本动了我的剪贴板偶发粘贴串内容。 原因parsing_response_to_pyautogui_code默认input_swapTrue走 pyperclip 剪贴板 CtrlV 实现输入。 解法不想动剪贴板就传input_swapFalse回退到pyautogui.write逐键输入速度稍慢但互不干扰。现象解析直接抛Action cant parse错误整轮流程中断。 原因模型输出格式漂移缺Action:前缀、动作串里多了换行或引号未闭合AST 解析失败。 解法提示词严格用 MOBILE_USE 模板定义的输出格式约束模型temperature 调低解析前检查 response 是否含 Thought/Action 两段个别失败轮次截图留档方便回放排查。这条流程在我手上已经稳定跑通了回归验证最大的前期成本就是坐标参数和输出格式的对齐对齐一次之后界面改版也不用再回去改定位代码。延伸阅读文档入口和源码路径在哪总览文档与全部 benchmark 数据README.md模型部署Endpoint 配置、API 调用示例README_deploy.md坐标缩放原理与可视化教程README_coordinates.md核心解析逻辑codes/ui_tars/action_parser.py三套提示词模板codes/ui_tars/prompt.py可运行的坐标换算示例与单元测试codes/tests/inference_test.py、codes/tests/action_parser_test.py多轮对话消息样例含 base64 截图data/test_messages.json论文全文UI_TARS_paper.pdf【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 UI-TARS零代码测试实战：3步跑通Android自动化测试的10分钟
UI-TARS零代码测试实战3步跑通Android自动化测试的10分钟【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS上周四我接手了一个App的回归测试200多条用例手机端每条都要手动点开、输入、截图确认。后来我试着用 UI-TARS 跑 Android 自动化测试把自然语言指令直接喂给模型它输出点击坐标和 pyautogui 脚本全程不用写一条元素定位代码。下面按测试同学能直接照做的顺序讲讲这套东西怎么运转、我踩过哪些坑。场景200条回归用例手动点到哪算哪传统流程里Appium 脚本要维护 resource-idEspresso 要熟悉框架 APIUI 一改脚本就批量失效。我们组当时一个页面改版200 条用例里有 40 多条定位全部报错修定位花了一整天。我想要的其实是给一张截图和一句点登录按钮机器自己找到按钮在哪。这正是 UI-TARS 这类 GUI Agent 的思路——不读页面结构直接看图。项目定位UI-TARS是什么Android World上能考多少分UI-TARS 是字节 Seed 团队开源的、基于视觉语言模型的 GUI 自动化 Agent仓库里包含模型部署方案、codes/ui_tars/解析库和坐标处理工具。它的动作空间统一桌面端有 COMPUTER_USE 模板移动端有 MOBILE_USE 模板模型先输出 Thought推理过程再输出 Action动作函数调用解析库再把文本变成可执行脚本。数据直接引用官方 README 的 Online Benchmark 评测表UI-TARS-1.5 模型Android World 得 64.2此前 SOTAOS-Atlas-7B为 59.5OSWorld100 步得 42.5OpenAI CUA 为 36.4元素定位基准 ScreenSpot-V2 得 94.2。开源的 UI-TARS-1.5-7B 可免费部署部署指南 建议配 L40S 48G 显存的实例。适合谁想摆脱脚本定位维护的测试工程师、评估 GUI Agent 的研究者以及要给自己的业务搭 GUI 自动化流水线的团队。环境准备adb调试怎么配ui-tars解析库怎么装前置条件有三样Android 真机或模拟器开启 adb 调试adb devices能看到设备拿到设备当前屏幕分辨率后面解析坐标要传这个数Python 3.8官方解析库一条命令装好pip install ui-tars # or uv pip install ui-tars装完后 Python 里可直接import ui_tars核心代码在仓库的codes/ui_tars/目录。模型本身不在仓库里需要按 README_deploy.md 把 UI-TARS-1.5-7B 部署成 API 服务HuggingFace Endpoint 或本地推理框架都行拿到模型的文本输出。需要样例数据和测试脚本的话仓库可克隆git clone https://gitcode.com/GitHub_Trending/ui/UI-TARS。本文重点讲模型吐出文本之后怎么把它变成动作这一半。核心工作流MOBILE_USE模板怎么喂模型输出怎么解析运行逻辑是输入、处理、输出三段。输入端一张截图 一句自然语言任务描述提示词由codes/ui_tars/prompt.py里的模板生成。Android 设备用 MOBILE_USE 模板它的动作空间除了 click、type、scroll、drag还有移动端专属的open_app、press_home、press_back、long_press、finished。处理端视觉语言模型看到截图后先输出 Thought 再输出 Action格式固定为函数调用例如click(start_box(197,525))。输出端codes/ui_tars/action_parser.py的parse_action_to_structure_output把文本解析成结构化字典内部用 smart_resize 做坐标换算——模型内部会把图片缩放到 28 的倍数分辨率再看所以坐标必须换算回原图尺度接着parsing_response_to_pyautogui_code生成 pyautogui 脚本。先看第一步解析模型原始输出from ui_tars.action_parser import parse_action_to_structure_output response Thought: 点击确认按钮\nAction: click(start_box(197,525)) parsed parse_action_to_structure_output( response, factor1000, origin_resized_height1080, origin_resized_width1920, model_typeqwen25vl)运行后得到一个列表每个元素是含thought、action_type、action_inputs的字典其中start_box已换算成 0~1 之间的归一化坐标。第二步把结构化动作转成可执行脚本from ui_tars.action_parser import parsing_response_to_pyautogui_code code parsing_response_to_pyautogui_code(parsed, image_height1080, image_width1920) print(code)输出的是一段 pyautogui 脚本开头import pyautogui中间以注释形式保留了 Observation 和 Thought结尾是形如pyautogui.click(196, 519, buttonleft)的语句保存下来即可在模拟器或 adb 设备驱动上执行。关于坐标怎么换算的仓库带了可视化脚本codes/tests/inference_test.py跑完会把模型指的位置用红点画回原图红点落在目标元素上说明分辨率参数传对了偏了就是下面坑里说的第一条。能力边界擅长什么、不擅长什么和Appium差在哪性能对比数据来自论文图表UI-TARS-72B/7B 相对此前 SOTA 的相对提升维度UI-TARSAppium / Espresso定位方式截图像素 视觉理解resource-id / 元素树UI 改版后样式、元素位移只要截图可辨通常仍能找到属性一改定位批量失效编写门槛自然语言描述任务即可需掌握定位语法与框架 API简单固定流程每步都要过模型慢且偶发漂移更快更确定失败可精确定位到行已知短板复杂/模糊界面偶发误识别官方 Limitations 明确列出幻觉问题跨 App 复用差页面维护量大两点需要说清开源 7B 版在部分游戏场景的优化弱于 72B 版README 的 Limitations 一节原话是 7B 未专门针对游戏场景优化长流程里单步成功率会被逐步放大成整体失败率所以回归场景建议每步动作后加截图校验而不是只信点了。实测记录我完整跑了一遍坐标解析流程环境是 Linux 桌面 1920×1080 的截图仓库自带的 GIMP 示例图第一次跑codes/tests/inference_test.py我没核对分辨率参数坐标算出来红点明显偏出Color Management选项一小截。后来明白原因模型内部把 1920×1080 经 smart_resize 放大到 1932×109228 的倍数换算回来本来就有 1~2 像素舍入差我传的截图分辨率又和示例图不一致两者叠加偏移就大了。改成传真实分辨率后重跑终端输出$ python codes/tests/inference_test.py Original coordinate: 1920, 1080 Resized dimensions: 1932, 1092 (195, 519)三行依次是原图分辨率、模型内部缩放分辨率、换算回原图的点击坐标。再把同样输入交给解析库生成的 pyautogui 片段是pyautogui.click(196, 519, buttonleft)——和 195 差 1 像素来自 int 截断与 round 取整两种取整方式点击场景完全可以接受。跑通之后整个解析链路在我这边单次耗时在毫秒级瓶颈全在模型推理上。踩坑记录4个常见现象、原因和解法现象解析后点击位置明显偏移红点不在元素上。 原因origin_resized_height/width传了默认值或错误值或model_type选错qwen25vl 输出绝对坐标doubao 系输出point相对坐标两条换算路径不同。 解法传截图的真实分辨率并指定对应model_type解析前先跑codes/tests/inference_test.py看红点是否落位。现象同一套流程换一台分辨率不同的设备坐标就漂了。 原因坐标系绑定当时截图的分辨率smart_resize 的结果也随之变化。 解法换分辨率后必须重新截图、重新传当前分辨率不要缓存旧坐标设备列表里把分辨率信息一并记录。现象type输入中文时脚本动了我的剪贴板偶发粘贴串内容。 原因parsing_response_to_pyautogui_code默认input_swapTrue走 pyperclip 剪贴板 CtrlV 实现输入。 解法不想动剪贴板就传input_swapFalse回退到pyautogui.write逐键输入速度稍慢但互不干扰。现象解析直接抛Action cant parse错误整轮流程中断。 原因模型输出格式漂移缺Action:前缀、动作串里多了换行或引号未闭合AST 解析失败。 解法提示词严格用 MOBILE_USE 模板定义的输出格式约束模型temperature 调低解析前检查 response 是否含 Thought/Action 两段个别失败轮次截图留档方便回放排查。这条流程在我手上已经稳定跑通了回归验证最大的前期成本就是坐标参数和输出格式的对齐对齐一次之后界面改版也不用再回去改定位代码。延伸阅读文档入口和源码路径在哪总览文档与全部 benchmark 数据README.md模型部署Endpoint 配置、API 调用示例README_deploy.md坐标缩放原理与可视化教程README_coordinates.md核心解析逻辑codes/ui_tars/action_parser.py三套提示词模板codes/ui_tars/prompt.py可运行的坐标换算示例与单元测试codes/tests/inference_test.py、codes/tests/action_parser_test.py多轮对话消息样例含 base64 截图data/test_messages.json论文全文UI_TARS_paper.pdf【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考