夜雨聆风在之前的一篇《深度 | TestHub UI自动化测试实战&设计思路详解》文章中，我们深入介绍了TestHub UI自动化测试模块的设计理念，并且结合实际业务，开展了从元素创建到编排用例的项目测试实战。
今天这篇，我们深入介绍一下APP测试模块的设计理念以及具体用法~
1.设计理念
APP测试模块同UI自动化测试模块一样，总体也遵循了PO模式的设计理念。但也有几条值得一提的设计思路：
- 把设备当资源管，而不是当配置管：每台设备有状态机（可用/锁定/离线/在线），有锁机制（手动锁定/远程会话锁定/自动化执行锁定），有心跳和超时自动释放；
- 测试场景是"画"出来的，不是"写"出来的：模块里包含UI Flow（JSON配置），用来描述每一步要干什么：点击图片A、输入文字B、等待C出现……前端有个场景编排器，拖拖拽拽就把流程拼出来了。后端有个
UiFlowRunner，负责把这些JSON翻译成Airtest能听懂的动作； - 远程控制和自动化共用一套设备体系：可以在工作台上实时操控一台手机（投屏+触控），也可以给这台手机下发自动化用例。两种模式共享同一套设备锁定逻辑，互不打架；
- 执行和报告分离，任务状态和测试结果分离：一个用例执行完了，"执行有没有跑完"是一个状态，"用例到底通过还是失败"是另一个结果。网络断了导致任务异常，和用例本身断言失败，是两码事。
2.技术栈
- 自动化引擎选了Airtest：网易开源的一套UI自动化框架，核心能力是图像识别。Airtest底层连的是ADB，对Android设备的操控能力很全。模块里
AirtestBase类封装了设备连接、重试、超时保护、截图、启停APP这些基础能力。 - 文字识别用Tesseract。 有些场景光靠图片匹配不够，比如要读取屏幕上显示的数字（账号余额、成绩之类的），就得靠OCR。
OCRHelper封装了Tesseract，支持中英文混合识别，还做了图像裁剪、对比度增强、置信度过滤、结果缓存这些优化。 - 设备投屏选了自建的scrcpy： scrcpy是开源界做Android投屏的事实标准，但TestHub没有直接装个scrcpy客户端完事，而是自己管理了scrcpy-server的生命周期：把server推到设备上、建立ADB端口转发、通过socket接收视频流和控制流。视频流走一个socket，控制指令走另一个socket，全部通过WebSocket桥接到前端浏览器。画质参数（码率、分辨率、帧率）可调，还有边界保护防止异常参数把服务搞挂。用户在浏览器里就能操控手机，不用装任何客户端。
- 后端是Django + DRF + Django Channels：这是TestHub全平台的统一选型，APP模块没有另起炉灶。REST API走DRF ViewSet，实时通信走Channels WebSocket。两个WebSocket Consumer各司其职：
AppExecutionConsumer推送用例执行进度，RemoteDeviceConsumer负责远控会话（投屏+控制+logcat日志流）。 - 测试执行走pytest子进程 + Allure报告：
AppTestExecutor不是在Django进程里直接跑测试，而是拉起一个pytest子进程，通过环境变量传参（用例ID、设备ID、包名、执行记录ID），子进程跑完再解析Allure的原始结果JSON来统计通过/失败； - 其他配角： ADB负责所有设备层操作（装包、启停APP、读性能数据、取logcat）；androguard/aapt负责解析APK文件提取包名版本号；OpenCV+PIL+numpy做图像处理；Celery/Django Q负责定时任务调度；Vue 3 + Element Plus做前端，ECharts画Dashboard，Monaco Editor做组件配置编辑。
3.架构拆解
把模块竖着切开，大致是这么几层：
- 数据模型层：这是整个模块的地基，用来管理项目、设备、UI元素、测试用例、执行记录等；
- 设备管理层：跟ADB打交道的统一入口。所有对设备的操作——列设备、连设备、装APK、启停APP、读文件、跑dumpsys、取logcat——都封装在这里面；
- 执行引擎层：真正跑测试的地方，分两个角色：AppTestExecutor-负责调度者，UiFlowRunner-解析执行；
- 实时通信层：两个WebSocket Consumer：AppExecutionConsumer负责监听用例跑到了哪一步，RemoteDeviceConsumer就重了，它管的东西很多：连接时锁设备、建scrcpy会话、启心跳循环；断开时释放锁、停scrcpy、清logcat进程；
- 投屏服务层：
ScrcpyService按设备ID管理会话，处理投屏服务； - 性能监控层：
DevicePerformanceSampler不依赖任何第三方SDK，纯靠ADB读Linux系统文件和dumpsys来采数据：/proc/stat算CPU使用率（两次采样做差值），/proc/meminfo读内存，/proc/net/dev算网络速率，dumpsys battery读电池，df读存储，dumpsys gfxinfo算帧率和卡顿率。 - 其他支撑：APK解析、元素管理、通知、定时任务等；
1.拆解业务流程
说了这么多，我们就以“高德打车”这个业务流程为例，来实际讲解一下，应该如何在TestHub上开展APP测试实战。
UI自动化的本质就是把人工操作流程通过系统或工具转化为自动化操作流程，从而提高效率、便于回归。
那么，我们首先就是要考虑“高德打车”这个业务流程的手动实现：
- 首先要打开高德地图APP，这个没什么说的；
- 第二步，点击“打车”，进入打车模块；
- 输入目的地，搜索；
- 从搜索结果中确认目的地；
- 点击确认，开始打车（当然如果要选择打车类型的话，还需要勾选类型，例如：快车、专车等）；
2.连接设备
打开手机USB调试开关，通过USB线连接手机与电脑，手机弹出是否允许调试的提示中选择允许。进入设备管理，刷新，确保设备处于可用状态。
3.创建元素
回归到平台上，我们首先要做的就是把这些人工操作步骤中涉及到的元素创建好，统一管理，便于我们后期编排组装，形成测试用例。
3.1 添加“高德打车”元素
① 这里我们进入到元素管理，点击“从设备创建”。
② 选择我们的手机设备，点击“从设备截图”，填写表单信息：
- 元素名称：任意，例如“高德地图”；
- 所属项目：可选，选择归属项目；
- 元素类型：支持图片元素、坐标元素、区域元素。如果选择图片元素，鼠标在左侧手机屏幕中框出待测APP的图标区域即可；
- 图片分类：可以选择默认分类，也可以自己创建一个单独的分类；
- 模板文件名：自定义填写；
③ 保存元素
保存完成后，元素管理列表就会新增显示刚刚创建的“高德地图”元素。
3.2 添加“打车”及其他待操作元素
接着，我们再按照上面的流程添加第2个“打车”元素，以此类推，创建第3、4、5......个元素。
我们需要模拟人工输入目的地的操作，需要点击输入框，所以这里要把目的地输入框也截图创建元素。
通俗点来说就是：人在操作过程中操作了哪些元素，就要把哪些元素创建保存下来。
结果如此一番创建后，我们会得到以下元素：
- 高德地图：通过它来打开高德APP
- 打车图标：点击它进入高德地图的“打车”模块
- 目的地搜索框：点击目的地搜索框，弹出输入框
- 输入终点：输入框中输入终点
- 目的地：点击后确认目的地
4.用例编排
既然业务流程拆解、元素也创建好了，剩下的就是将上述元素按照与人工操作一样的顺序编排成一条测试用例。核心思路如下：
- 从左侧组件库的基础组件中拖动组件到场景步骤，例如：点击、输入、滑动、等待等等，也就是对于元素要做什么操作；
- 在右侧组件配置中选择要操作的元素，所以每一条完整的场景步骤都是：元素+操作的组合。例如下图点击高德地图APP：
以上述“高德打车”这个场景为例，我所需要编排的场景步骤（动作+元素）就是：
编排完成后，记得点击顶部的“保存用例”。
5.执行用例
用例编排、保存用例后，就可以在测试用例列表中查看到。点击运行，随后开始执行用例。
下面来看看执行效果：
6.查看报告
执行后的用例，可以在报告管理-用例报告中查看测试报告详情。
除了元素管理、用例编排、测试套件、定时任务，APP测试模块也提供了其他多种实用功能，例如：
- 在手机投屏页面可以直接创建元素。
- 设备性能监控
- APP性能监控
- 调试日志查看
APP测试模块不是那种"一上来就让人眼前一亮"的东西，但它解决了该解决的问题：设备调度的冲突、自动化和远控的共存、执行过程的可观测、测试结果和任务状态的区分——这些都是真在测试平台上踩过坑才会做的设计。
技术栈上也没有追新，Airtest、Tesseract、scrcpy、Django Channels都是被验证过的方案。图像识别+OCR+坐标定位三种元素策略并存，本质上是为了适配现实中各种"不标准"的APP。
开源测试平台Testhub官网地址（内测中）
地址：https://testhub.aisky.cloud/
往期精彩：
基于AI的全链路性能测试提效：7个 Skill技能，亲测好用，实现全链路压测落地
测试人的免费宝藏学习网站，TestHub官网上线：使用手册 + 视频教程 + 学习中心 + 开源专区，强烈建议收藏
90%测试团队都在踩坑，Hermes Tester Skills 技能系统，1:1复刻团队测试能力
Skill一键生成专业性能测试计划，7个Skill技能亲测好用，实现全链路压测落地（第二篇）
Skill生成2000万专业性能测试数据，实战亲测，自动化一键生成（第三篇）
测试人经常被问为什么没有提前发现这些问题？压测就绪检查全流程实战，7大性能测试 Skill(第四篇)
告别手动编写JMeter脚本，一个 Skill搞定99% 脚本配置，自动生成分布式压测脚本，7大性能测试 Skill(第五篇)
testhub社群，添加微信：
