爱意满满的作品展示区。
ZhaokunZhang

移动端回归测试人手不够,我落地了一套 VLM 真机自动化方案,想听听大家意见

  •  
  •   ZhaokunZhang · 4 days ago · 1638 views

    最近在公司里落地了一套移动端 AI 自动化回归方案,想拿出来和大家交流一下,也听听有没有类似场景的同学。

    先说背景。

    我们这边移动端有 Android 、iOS ,现在还有鸿蒙。业务迭代比较快,每次发版前都要做一些主流程回归。

    比如:

    • 登录
    • 内容浏览
    • 内容发布
    • 视频播放
    • 核心页面跳转
    • 多端基础兼容验证

    问题是,测试资源并不是特别充足。

    不是没人测,而是没有一个专门的人长期维护复杂自动化。很多时候是测试同学过一遍主流程,开发自己再补一遍。

    时间紧的时候,大家其实都知道一些边角路径覆盖不到,但也只能先保核心链路。


    之前也看过传统自动化方案,比如 Appium 、xpath 、坐标、录制回放这些。

    实际落下来,问题基本差不多:

    页面一改,脚本就容易挂。

    Android 、iOS 、鸿蒙三端表现不完全一样。

    弹窗、权限、加载中、toast 、偶现卡顿这些情况,都要额外处理。

    最关键的是,如果没有专门自动化测试同学长期维护,这套东西很容易变成:

    刚开始能跑,过一段时间没人敢动。

    所以我后来尝试了另一条路:

    能不能把 case 写成人话,然后让模型看真实手机截图,自己判断下一步怎么操作。

    比如一个 case 可能就是:

    打开 App ,登录账号,进入首页,确认能看到推荐列表。

    系统拿到这个 case 后,分配一台真机。

    执行过程中,每一步截图给 VLM ,让模型判断当前页面状态、下一步点哪里、输入什么、是否已经完成。


    这个方向我一开始也只是想验证一下。

    但后面做着做着,发现单纯做一个本地 demo 意义不大。因为公司里真正要用,光能跑起来还不够。

    所以后面我把它补成了一个偏平台化的东西,目前已经在公司内部落地使用。

    大概流程是:

    外部系统投递一批 case
            ↓
    平台根据端类型寻找空闲设备
            ↓
    真实手机开始执行
            ↓
    每一步记录截图、模型判断、操作结果
            ↓
    执行结束后生成报告
            ↓
    case 结果和批次结果回传给业务系统
    

    现在它可以覆盖 Android 、iOS 、鸿蒙三端真机。

    不过我自己的感受是,这个东西真正有价值的地方,不是“AI 能点手机”。

    单纯让模型看图点一下,其实很容易做成 demo 。

    真正落地的时候,麻烦的反而是这些:

    • 页面是否已经稳定下来
    • 模型是不是一直卡在同一个页面
    • 弹窗、权限、广告、toast 这种临时 UI 怎么处理
    • 失败以后怎么复盘
    • 多台设备怎么调度
    • 结果怎么让内部系统消费
    • 怎么让开发和测试愿意相信这个报告

    所以我后面做的时候,重点其实放在了执行链路上,而不只是模型本身。


    当然,现在这个方案也不是没有问题。

    稳定性肯定还不如写死脚本。

    同一个 case 多跑几次,偶尔会出现模型判断不一致。

    起始状态也很重要。账号状态、权限状态、弹窗状态如果不干净,模型很容易被带偏。

    成本也要算。因为每一步都调 VLM ,跑多了肯定不是免费的。

    另外像验证码、人脸、安全键盘、强风控这些场景,我也不觉得它适合硬做。

    所以我现在对它的定位不是替代测试,也不是替代传统自动化。

    更像是一个兜底工具。

    比如:

    • 开发提测前,先跑一遍主流程
    • 发版前,跑几条核心冒烟
    • 晚上定时跑一批基础回归
    • Android 、iOS 、鸿蒙三端做主链路对比
    • 没有专门自动化测试岗位的团队,先把最痛的几个流程托管起来

    目前我们内部已经用它跑了一些真实场景,确实能减少一部分重复点点点的工作。

    但我也知道这个方向还不算成熟,所以想听听大家意见。


    我比较想请教几个问题:

    1. 你们公司移动端回归一般是怎么做的?
    2. 如果没有专门自动化测试岗位,自动化最后通常是谁维护?
    3. VLM 看图操作真机这种方式,你们觉得最大的问题会是稳定性、成本,还是失败复盘?
    4. 如果只是用来兜底主流程冒烟,而不是做完整测试,你们觉得有没有价值?
    5. 这种方案要接进公司内部测试平台,你们最关心的是报告可信度、执行稳定性,还是环境隔离?

    我把目前整理出来的版本开源了,项目叫 ai-phone:

    https://github.com/dongxinsuperman/ai-phone.git

    目前主力分支是 next/server-brainmain 分支已经归档冻结。

    发出来主要不是想说这个方案已经多完善,而是因为它确实在公司里跑起来了,也踩到了一些传统自动化和 VLM 落地之间的问题。

    想听听大家怎么看这个方向,欢迎提建议,也欢迎拍砖。

    21 replies    2026-05-21 22:05:42 +08:00
    clemente
        1
    clemente  
       4 days ago
    钝刀秀刀功

    不如做全套 hook + ai
    beimenjun
        2
    beimenjun  
    PRO
       4 days ago
    之前有做 iOS 的自动化测试,其实我想的这种方案应该往外接机械设备实现现实的点击 + 摄像头来实时采集数据 + 大模型根据摄像头内容来决定点击的方向走。

    这类方案需要同时满足,“稳定、快、可复制、便宜”,感觉才有比较大的前途。

    你这一套不知道在“快”和“便宜”上不知道是如何解决问题的。
    jinxgogo
        3
    jinxgogo  
       4 days ago
    测试人员:“做个人吧,别再造轮子,测试都要步前端后尘了”
    cthunter
        4
    cthunter  
       4 days ago
    试用了一下,很不错的工作!
    前几天跑了一段时间 Midscene ,跑常规用例太慢,token 太耗了,你这个如果能和 Appium 结合起来就好了,跑完直接生成 Appium 脚本。
    ZhaokunZhang
        5
    ZhaokunZhang  
    OP
       4 days ago
    @jinxgogo 不是的,从我之前在杭州的经历,这个是减负的。
    edsion996
        6
    edsion996  
       4 days ago
    钝刀秀刀功 +1
    pipasese
        7
    pipasese  
       4 days ago via iPhone
    可以让你的这套流程写 UITest ,把流程固定下来。
    WebKit
        8
    WebKit  
       4 days ago
    直接用 codex ,把测试用例给他,让他测试就好了。界面什么的,自己通过源码找跳转方法和路径。目前测试没啥问题
    kkwwuuww
        9
    kkwwuuww  
       4 days ago
    安装 app 的部分怎么处理?
    lancevps
        10
    lancevps  
       3 days ago
    持续集成是问题,你这套流程跟 AI 生成用例相比并没有效率上优势
    XuDongJianSama
        11
    XuDongJianSama  
       3 days ago
    挺难的,ai 视觉又弱又慢,不如多招大学生测试,严格按照测试流程一步步操作完哈哈。人吞图像的速度贼快
    ZhaokunZhang
        12
    ZhaokunZhang  
    OP
       3 days ago
    @XuDongJianSama 像我之前呆的杭州、沈阳公司,普遍没有测试岗位,这才找这种的,以前都自测。
    ZhaokunZhang
        13
    ZhaokunZhang  
    OP
       3 days ago
    @WebKit 我这边都是端内 web view 有些需要触发端内桥的功能。主要是这个。 作者本人没 v2 号。
    ZhaokunZhang
        14
    ZhaokunZhang  
    OP
       3 days ago
    @cthunter 如果 deepseek 视觉模型全量,估计成本更低。
    ZhaokunZhang
        15
    ZhaokunZhang  
    OP
       3 days ago
    @beimenjun 关于经济性和速度,其实做了不少工作:
    经济:
    开启模型主动式缓存:模型在首次执行测试用例时就会有约 90% 的 token 消耗落在缓存区,消耗其实不算大。
    同时有分段逻辑:当模型上下文达到 30K token 时会主动断连,并注入上下文辅助信息,保证执行稳定,同时避免触发模型阶梯计费。
    速度:
    纯视觉回放比较复杂,要速度会牺牲稳定性,要保证稳定又会牺牲速度,因为无法自动判断每个动作是否准确落下。
    目前有三种缓存策略,适配不同场景:
    1. 固定轨迹回放
    * 按首次执行的动作完整回放,对业务稳定性要求高。
    * 每步页面检测严格,保证稳定后执行,但速度一般。
    2. 路标缓存回放
    * 每步执行后与首次缓存路标对齐,判断动作是否正确。
    * 正确就继续回放;不正确就按首次执行真实间隔加载完成,再由 VLM 局部介入修复本步骤,修复后继续缓存回放。
    * 静态需求场景下速度最快。
    3. 位置重建缓存回放
    * 针对业务频繁变动的场景,将首次执行动作抽象缓存,再次执行只询问模型位置,不重新推理。
    * 保证实时正确,同时节省成本,速度比首次执行略快。

    弹窗/非业务浮层标记逻辑
    * 在路标和位置重建回放中,如果弹窗存在,会帮助关闭;不存在则跳过继续回放,保证整体稳定性。
    这些方案各自适配不同场景,但天然都对业务稳定性有一定要求。
    ZhaokunZhang
        16
    ZhaokunZhang  
    OP
       3 days ago
    @kkwwuuww 目前真机手装,后续会加入这个功能,上传分发
    ZhaokunZhang
        17
    ZhaokunZhang  
    OP
       3 days ago   ❤️ 1
    @clemente 你提的 hook + AI 方式确实在调试和快速验证上很高效,但在我们公司属于开发自测阶段的验证手段,在测试场景里,我们还是需要在真实设备上多端完整走一遍用户流程,确保交互和界面行为都被覆盖。
    ZhaokunZhang
        18
    ZhaokunZhang  
    OP
       3 days ago
    @lancevps 这个可能理解岔了,AI 生成测试用例是输入,AI Phone 做的是执行。目前我们使用的典型场景是:AI 生成测试用例后(比如 cursor 生成的),触发器直接自动调用 ai-phone 开始端到端的真机执行
    XuDongJianSama
        19
    XuDongJianSama  
       3 days ago
    对了对了,想起来了,给 app 支持上无障碍 taklback ,ai 直接取无障碍数据,还能对照看 app 代码。就能高速稳定测试了。跟测试的 ai 说 taklback 看不清的就截图看看,确实是 taklback 没做好就让他改 taklback 。

    ai 本来就是眼睛不好的盲人,让盲人 ai 把整个测试流程跑没 bug 。然后人扫一眼各个界面都正常就行。或者让 ai 顺手把各个界面截图,但不去看。人等 ai 测完了快速扫一眼界面截图就行
    beimenjun
        20
    beimenjun  
    PRO
       3 days ago
    @ZhaokunZhang 你有计算过大概单 Case 的具体消耗吗?感觉如果你可能还是要给出一个大家使用这一套成本的估算。
    ZhaokunZhang
        21
    ZhaokunZhang  
    OP
       3 days ago
    @beimenjun 通过询问作者得到一份真实场景的数据
    一条中长复杂度的 App 自动化 case ,从进入洋葱 App 做题板块,到循环完成 5 道题,并断言结束页结果正确。该 case 实际共请求豆包视觉模型 doubao-seed-1-6-vision-250815 共 33 次。

    在执行过程中,我们在调用层实现了 Token 经济熔断机制:当上下文 token 接近一档上限时,主动切断当前会话上下文并开启新一段请求,避免后续 prompt tokens 持续累积进入更高计费档位。这个真实案例中,第 21 次模型请求时 prompt tokens 达到 31,328 ,第 22 次请求被熔断切段后降到 2,982 。

    这次真实执行的 token 数据为:总 prompt tokens = 486,363 ,总 completion tokens = 2,613 ,其中 cached tokens = 438,549 ,缓存命中率 90.2%,真实推理 token 为 50,427 。

    按该模型一档计价口径估算:未命中输入 0.72 元 / 百万 tokens ,缓存命中输入 0.16 元 / 百万 tokens ,输出 7.2 元 / 百万 tokens 。

    费用公式为:

    总费用 = 未命中输入 token × 未命中输入单价 + 缓存命中 token × 缓存命中单价 + 输出 token × 输出单价

    代入数据:

    未命中输入 token = 486,363 − 438,549 = 47,814 ,费用约 0.034 元;缓存命中 token = 438,549 ,费用约 0.070 元;输出 token = 2,613 ,费用约 0.019 元。

    所以这条 33 次模型请求的中长复杂度 case ,整体推理费用约为 0.12 元上下。该金额已经包含缓存命中 token 的计费,但未包含缓存存储费;缓存存储费量级很小,暂不计入。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   842 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 63ms · UTC 21:11 · PVG 05:11 · LAX 14:11 · JFK 17:11
    ♥ Do have faith in what you're doing.