我把 Agent 接入到手机，APP 测试效率翻倍：基于优测 UBox 的真机测试实践
过去做 APP 回归测试，最耗时间的往往不是验证功能，而是围绕手机反复做准备和收尾：找设备、装包、登录、处理弹窗、截图、拉日志，再换一台手机重来一遍。
把 Agent 接入优测 UBox 后，我做的并不是让 AI 代替测试人员，而是把真实手机变成 Agent 可以调用的执行资源。测试人员负责定义目标、风险和判断标准，Agent 负责调度设备、执行操作、记录过程并整理结果。效率提升的关键，也不是 AI 点击屏幕比人快，而是设备准备、测试执行、问题取证和失败复跑可以被统一编排。
本文将为大家分享一个 Agent 接入云真机，用于 APP 测试的提效实践。
一、先改变测试任务的表达方式
传统自动化测试以步骤为中心：点击哪个坐标、输入什么内容、等待几秒、判断哪个元素。Agent 测试更适合以目标为中心：要验证什么、允许怎么做、看到什么算通过、失败时需要留下哪些证据。
例如，“测试登录功能”对 Agent 来说过于模糊。更有效的任务应该写成：
优测设备：选择一台 Android 14 真机，安装最新测试包，使用测试账号完成登录。检查是否成功进入首页、用户昵称是否正确显示。遇到权限弹窗时允许；如出现白屏、卡死、闪退或错误提示，立即截图并保存日志。禁止修改密码和访问生产环境，任务结束后释放设备。
这条任务同时给出了设备、前置条件、目标、判断标准、异常处理和执行边界。Agent 不再只是机械点击，而是围绕测试目标完成一条可追踪的闭环。
我通常把任务拆成六部分：
| 任务要素 | 需要写清楚什么 |
|---|---|
| 测试目标 | 本次要验证的业务结果 |
| 设备条件 | 系统、版本、机型、数量 |
| 前置状态 | 测试包、账号、初始数据和网络环境 |
| 操作范围 | 允许进入的页面和可执行动作 |
| 通过标准 | 页面、数据、提示或状态应满足什么条件 |
| 证据与边界 | 何时截图、保存什么日志、哪些动作禁止执行 |
任务描述越接近一份结构化测试契约，Agent 的执行越稳定。
二、我的实际用法：把一轮测试拆成五个阶段
1. 先让 Agent 准备设备，而不是直接开测
测试开始前，Agent 根据系统版本、品牌或机型要求选择在线真机，确认设备可用，再完成应用安装和启动。
过去，这些准备工作需要测试人员逐台操作。接入 UBox 后，设备查询、连接和操作都进入同一条任务链，测试人员不必在多个工具之间切换。
如果要做兼容性测试，可以先要求 Agent 返回候选设备列表，再由测试人员确认覆盖范围。这样既保留了人工决策，也减少了找设备和切设备的时间。
2. 用确定的主路径约束 Agent
Agent 能处理页面变化，但不代表任务可以完全开放。核心业务流程仍应给出明确顺序，例如“启动应用—登录—搜索—进入详情—加入购物车—提交订单”。
Agent 的自主性主要用在变化较大的环节：识别不同版本的权限弹窗、处理升级提示、适应控件位置变化、判断当前是否进入目标页面。
主路径保持确定，页面处理允许动态调整，通常比“完全写死”或“完全放开”更可靠。
3. 把取证变成默认动作
人工测试经常遇到一个问题：发现异常时只顾着复现，回头才发现截图、录屏或日志不完整。
在 Agent 任务中，我会提前规定关键节点和失败节点的取证要求：进入首页后截图、提交操作前截图、异常时保存当前画面和日志、任务结束后汇总设备信息与操作结果。
UBox 可以返回设备画面、截图、日志等信息。把取证写进任务后，证据采集不再依赖测试人员的临场反应，问题定位也更容易复盘。
4. 失败后不要盲目重试
Agent 遇到超时或识别失败时，最危险的做法是不断重复点击。更合理的处理顺序是：
- 保存当前页面和设备状态；
- 判断是网络慢、页面未加载、弹窗遮挡，还是应用异常；
- 对可恢复问题重试一次；
- 仍然失败则停止任务，保留日志和操作轨迹；
- 释放设备，等待人工分析。
这样可以避免 Agent 在错误页面持续操作，也能减少无效占用设备的时间。
5. 最后由人判断，而不是让 Agent 独自下结论
Agent 可以根据页面状态给出初步结果，但测试结论仍需要可验证的依据。
我会让 Agent 输出执行设备、完成步骤、异常位置、截图或日志证据，以及未完成原因。测试人员只需要重点复核失败项和高风险项，不必重新观看全部执行过程。
这一步把测试人员从“操作执行者”变成“任务设计者和结果审核者”，也是人工占用时间明显下降的关键。
三、四类最值得先落地的测试场景
场景 1：发版后的冒烟测试
每次出包后，让 Agent 在一台或多台指定系统版本的真机上完成安装、启动、登录和核心链路检查。
冒烟测试路径短、频率高、通过标准清晰，最适合作为第一条 Agent 真机任务。团队可以先验证一条稳定链路，再逐步增加页面和设备数量。
推荐任务写法：
优测设备：在 Android 13 和 Android 14 真机上执行版本冒烟测试。安装指定测试包，依次检查启动、登录、首页加载和个人中心。关键节点截图，异常时保存日志。分别输出两台设备的结果，结束后释放设备。
场景 2：多机型兼容性验证
传统兼容性测试的瓶颈通常不是用例本身，而是设备切换和结果整理。
通过 UBox，Agent 可以按任务要求调度不同系统和机型执行同一条测试链路。测试人员不再逐台重复操作，而是集中分析不同设备上的页面错位、控件不可点击、系统权限异常和功能差异。
多设备并行前，建议先在单台设备上跑通任务模板。否则，一条不稳定的任务会在多台设备上同时放大问题。
场景 3：探索性测试
固定脚本适合验证已知路径，Agent 更适合围绕一个目标探索页面和组合操作。
例如：
优测设备：在 15 分钟内探索个人中心和设置页面，检查所有可见入口能否正常打开，重点关注快速连续点击、前后台切换和重复提交。发现白屏、卡死、闪退或错误提示时停止并记录现场。禁止退出账号、修改密码和执行付费操作。
探索任务必须限制页面范围、执行时长、最大风险和停止条件。没有边界的“随便测测”通常只会产生大量操作，却难以形成有效结论。
场景 4：核心链路巡检
对于登录、搜索、下单、消息收发、直播观看等关键流程，可以让 Agent 定期在真机上执行验证。
与接口监控相比，真机巡检覆盖页面渲染、控件交互、系统权限和终端兼容性，更接近真实用户体验。它适合补充接口监控，但不应替代后端可用性和业务指标监控。
涉及支付、发帖、删除数据或账号安全设置时，应使用专用测试环境和测试账号，并设置人工确认点。
四、效率为什么会提升
1. 从逐台串行，变成多设备并行
人工测试一次通常只能专注操作一台手机。Agent 可以把同一任务分发到多台设备，测试人员主要关注任务设计和结果审核。
设备数量增加后，测试总耗时不再与机型数量近似线性增长。真正的瓶颈会从“谁来操作设备”转向“如何设计稳定任务和快速分析结果”。
2. 从人工取证，变成过程自动留痕
截图、日志、设备信息和异常位置随任务一起保存，减少了发现问题后重新复现、重新补证据的时间。
尤其是偶现问题，第一次出现时能否保留完整现场，直接决定后续定位成本。
3. 从重复操作，变成任务模板复用
稳定的冒烟、登录、搜索和下单任务可以沉淀为模板。发版时只需要替换测试包、设备范围和账号信息，不必重新描述整套流程。
模板复用的重点不是复制一段提示词，而是复用目标、通过标准、异常处理、证据要求和风险边界。
4. 从头复现，变成基于轨迹复跑
当任务失败时，可以根据设备、步骤和现场信息快速定位失败环节，再针对该环节复跑，而不是从头人工操作。
如果问题只出现在特定系统或机型上，还可以直接在同类设备上复现，减少环境准备时间。
5. 从全程盯守，变成人工重点审核
过去测试人员需要全程操作和观察。现在可以让 Agent 执行低风险、重复性强的任务，测试人员集中审核失败项、差异项和高风险节点。
所谓“效率翻倍”，本质上是单位人工时间内完成了更多有效测试任务，而不是单个点击动作快了多少。
五、如何判断是否真的提效
不要只看一条用例跑了多久。更有价值的是在接入前后持续记录以下指标：
| 指标 | 观察重点 |
|---|---|
| 人工占用时长 | 准备设备、执行和取证分别花了多久 |
| 单轮覆盖设备数 | 同一时间能完成多少机型验证 |
| 有效任务完成率 | Agent 完成目标且证据完整的任务占比 |
| 失败证据完整率 | 异常是否包含设备、步骤、截图和日志 |
| 问题复现时间 | 从收到失败结果到稳定复现需要多久 |
| 任务模板复用率 | 有多少任务可以在下次发版直接复用 |
可以用一个简单口径评估：测试效率 = 单位时间完成的有效测试任务数 × 证据完整率 ÷ 人工投入时长。
如果只增加任务数量，却产生大量误判和无效操作，并不算提效。覆盖范围、结果可信度和人工投入必须一起看。
六、接入只需要了解这几件事
UBox Skill 把云真机的使用说明、调用约定和 CLI 能力打包后提供给 Agent。准备好优测账号、云真机资源、访问凭证和 Skill 包，在 WorkBuddy、CodeBuddy 或自建 Agent 中加载后，即可通过自然语言发起设备任务。
实际接入涉及团队信息、Token 申请、Skill 加载和首次配置，不同环境可能略有差异。本文不重复展开，直接参考官方文档：
让 Agent 用上真实手机：优测云真机 MCP 与 Skills 接入方法
接入完成后，建议先用“查询设备—连接—截图—释放设备”的最小任务验证链路，再开始执行完整 APP 测试。
七、三个容易踩的坑
1. 把 Agent 当成万能自动化脚本
Agent 擅长理解目标和处理变化，但不适合在没有边界的情况下自行探索所有功能。核心路径、通过标准和禁止动作仍需由测试人员定义。
2. 只写操作，不写判断标准
“打开页面并点击按钮”只能证明动作执行了，不能证明功能正确。每个关键步骤都应明确期望页面、数据状态或结果提示。
3. 忘记异常停止和设备释放
任务失败、超时或人工中断后，都必须停止无效操作并释放设备。否则不仅占用资源，还可能让后续任务继承错误状态。
结语
把 Agent 接入手机之后，最有价值的变化不是多了一种自动点击工具，而是 APP 测试拥有了新的协作方式：
- 测试人员定义目标、风险和判断标准；
- Agent 规划步骤、执行任务并处理页面变化；
- UBox Skill 与 CLI 把任务交给真实设备；
- 云真机返回画面、日志和执行结果；
- 测试人员集中审核异常和高风险节点。
如果准备开始，建议选择一条每天或每次发版都会执行的冒烟链路。先把“选设备—装包—执行—取证—释放”跑成稳定闭环，再增加机型、场景和并发规模。
先让 Agent 稳定完成一件高频小事，再让它承担更多测试任务。这个顺序，往往比一开始追求全自动更快看到效率收益。
参考资料
本文未注明其它来源的内容，其版权归优测云服务平台所有，未经允许不得转载本文内容。如需转载本文，请在显著位置注明出处（优测云服务平台，以及文章链接：https://utest.21kunpeng.com/home/topic/ubox0812）
