把移动端回归做成“一键可复现”：Airtest+Poco + Excel/JSON + 重跑归档（附 AI 辅助定位方法论）

用户21504158616
15 阅读6分钟

TL;DR：我做了一套移动端 UI 自动化回归框架（Demo：B 站 App + MuMu/ADB），支持 Excel/JSON 数据驱动、用例 ID/标签筛选、失败重跑、UI 树导出辅助定位、日志/报告/视频产物归档，并提供 Pytest 执行入口以便本地/CI 复用。本文用测试用例中的TC-005 全链路演示，并总结一套“AI 辅助找元素”的 4 步流程。
源码（Gitee）：Airtest+Poco+Ai移动端Ui自动化测试框架: 阿寅作者搭建的Airtest+Poco+Ai移动端Ui自动化测试框架，快速定位ui元素 稳定执行输出结果 ｜演示视频1：poco移动端app自动化测试演示_哔哩哔哩_bilibili ｜演示视频2：excel转json用例运行演示视频_哔哩哔哩_bilibili ｜产物示例截图：

ScreenShot_2026-02-27_143336_980.png

1. 背景：为什么要做“效能型”自动化

在移动端业务里，发版/灰度/活动上线前经常需要做一轮或多轮回归：核心链路要覆盖，且多版本/多机型并行。回归如果完全依赖人工，常见会遇到：

  • 人力被回归绑死：高频迭代下，测试投入被重复劳动吞噬，效率与质量都难保证
  • 定位成本越来越高：UI 变化、加载时机不一致导致偶发失败，排查需要反复复现
  • 产物不统一难追踪：跑完一堆零散日志/截图，复盘成本高，接入 CI 更难

所以我更关注“效能型自动化”的落地点：不仅要能跑脚本，更要把用例标准化、执行编排、产物沉淀做成“可复现的一键流程”。

2. 我做了什么：用例标准化 + 执行编排 + 产物沉淀

这一套框架我把它拆成三块，每块都直接对应回归效能问题：

2.1 用例标准化：Excel/JSON 双入口，JSON 作为稳定形态

  • Excel 适合编写与协作
  • JSON 适合稳定回归与版本管理
  • runner 支持 Excel → 标准 JSON 转换，便于长期维护与复跑

（图2：Excel→JSON 输出示例）

image.png

image.png

为了避免“随手写用例、结构各不相同”的不可维护问题，我先定义了一份可执行的 JSON 用例规范（字段、动作类型、断言/等待写法、稳定性约束等），并让 AI 在生成/补全用例时严格按这份规范输出。这样用例不是临时拼出来的，而是可以长期沉淀、可读、可回归的标准资产。 用例规范文档：

image.png

2.2 执行编排：按用例/标签筛选，失败重跑降低偶发成本

  • 支持只跑指定 case_id 或按 tags 分层（冒烟/回归）
  • 支持失败重跑，把“偶发失败的人工重跑”变成框架能力

image.png

2.3 产物沉淀：日志/报告/视频统一归档，可追踪可复盘

  • 每次执行统一产出：日志、报告（可选）、视频（可选）
  • 产物按用例归档，方便问题定位与复盘，也更适合 CI

image.png

3. 一分钟演示：用 TC-005 跑一条“完整链路”

我选用例集中的 TC-005 来做演示（case_id 注意是 TC-005）。

image.png

运行命令（复制即用）

python .\airtest_poco_case_template.py --run-json .\cases_test_cases2.json --case-id TC-005 --serial 127.0.0.1:7555 --package tv.danmaku.bili --restart-app-each-case

TC-005 做了什么（演示脚本）

  • 首页点击搜索框 → 搜索“基轮同学”
  • 切换到“用户”Tab → 进入 UP 主主页 → 进入投稿列表
  • 打开指定视频 → 点击弹幕输入框 → 弹出登录弹窗 → 关闭弹窗

poco移动端app自动化测试演示_哔哩哔哩_bilibili

4. 用例数据长什么样（最小示例）

我把用例当“数据”管理：case_id/title/tags/steps/expects。这样 runner 才能统一做筛选、重跑、归档。

{
  "case_id": "TC-005",
  "title": "验证查看up主视频",
  "tags": ["regression"],
  "steps": [
    {"action": "click", "target": "poco(\"tv.danmaku.bili:id/search_text\")", "msg": "进入搜索页"},
    {"action": "set_text", "target": "poco(\"tv.danmaku.bili:id/search_src_text\")", "value": "基轮同学", "msg": "输入关键词"},
    {"action": "click", "target": "poco(\"tv.danmaku.bili:id/action_search\")", "msg": "发起搜索"}
  ],
  "expects": []
}

5. UI 树导出：定位“更稳的 selector”的基础设施

UI 自动化里，稳定性很大程度取决于 selector 是否稳定。我在框架里提供了 UI 树导出能力，用来辅助挑选 resource-id/层级锚点：

AI 只按“用例生成规范”产出候选 steps/selector/断言写法，而我会结合 UI 树导出能力在真机/模拟器上验证并固化稳定定位（优先 resource-id，其次层级锚点），以提升用例稳定性。

python .\airtest_poco_case_template.py --dump-ui --serial 127.0.0.1:7555 --dump-ui-out .\ui.xml

image.png

image.png

6. 效能技巧：AI 辅助找元素的 4 步方法论

找一个“稳定元素”往往比写一步操作更耗时。我把 AI 作为“候选生成器”，结合用例描述 + UI 树 + 截图来提效，但最终稳定性由人工验证兜底。

  • Step 1｜收敛场景（要找什么）
    从用例里抽出“动作 + 页面状态 + 验证点”，用一句话描述目标控件和成功标志。
    例：TC-005 中“切到用户 Tab 并进入 UP 主页”，验证锚点是主页昵称控件存在且包含“基轮同学”。

  • Step 2｜提供证据（喂给 AI 的输入）
    准备三份输入：用例步骤描述、--dump-ui 导出的 xml、页面截图（标出控件区域/文案）。

  • Step 3｜产出候选（让 AI 给 3 个备选 + 等待锚点）
    让 AI 输出 3 类候选 selector（resource-id 优先、desc 次之、文本/层级兜底），并给出页面加载的等待锚点（哪个 exists 才算页面 ready）。

  • Step 4｜人工验证并固化（把候选变资产）
    在设备上验证：加 wait_until、页面切换后重取节点、重跑/重启后再跑；通过后把 selector/等待策略沉淀到用例规范与 runner，确保回归可复现。

image.png

7. 本地/CI 复用：为什么要接 Pytest

为了让回归更像“工程化执行”，我把 runner 与 Pytest 的执行入口打通，核心收益是：

  • 用例可参数化执行、可按标签分层
  • 产物目录结构更统一，适合 CI 持续跑与追踪

image.png

8. 为什么用 B 站 App 做 Demo？如何迁移到业务 App？

我目前用公开 App 做演示，目的是让读者可复现且合规。框架层面将 serial/package/用例数据源参数化，迁移到业务 App 时重点是：补齐业务用例与 selector 治理，并沿用“用例标准化 + 编排 + 归档”的效能思路。

9. 总结

我希望这套 Demo 传达的不是“写了多少脚本”，而是把回归做成可持续的效能工具链：

  • 用例标准化（Excel→JSON）
  • 执行编排（筛选/重跑）
  • 产物沉淀（日志/报告/视频归档）
  • AI 辅助定位提效（候选生成 + 人工验证固化）
avatar
文章
阅读
粉丝