Android 游戏自动化测试基础：ADB、Shell、Monkey 与日志

note · 课程笔记 本文提炼自侑虎科技高嵘讲授的游戏自动化测试课程（原题“小熊自动化测试课程”，2021-01-06）。已删除课堂过渡语、口语重复、个人路径、示例密码和具体内部应用标识，并按知识主题重组。课程原计划还包括 Python 与 Airtest；本笔记现有材料主要覆盖 ADB 与 Android 命令行基础。

warning · 使用边界 只对自己拥有或明确获授权的设备与应用执行调试、数据清除、输入注入和压力测试。命令会卸载应用、清除数据或产生大量事件，运行前确认包名、设备序列号与测试环境。

1. 为什么先学 ADB

ADB（Android Debug Bridge）是开发机与 Android 设备之间的调试桥梁。许多 UI 自动化框架会在底层借助 ADB 完成安装、启动、输入、截图、日志和文件传输。理解 ADB 有助于：

• 判断故障发生在设备连接、框架封装还是业务脚本；
• 把环境准备、数据采集与测试执行拆成可复用步骤；
• 在没有完整 UI 框架时快速构造诊断脚本。

ADB 包含开发机上的客户端、后台 server 和设备上的 adbd。应从 Android SDK Platform-Tools 官方渠道取得，不使用来历不明的独立下载站。

2. 设备连接与选择

USB 调试

1. 在测试设备启用开发者选项与 USB 调试。
2. 使用数据线连接，并在设备上确认主机 RSA 指纹。
3. 检查状态：

adb start-server
adb devices -l

unauthorized 表示设备尚未授权；offline 可能需要重连、重启 ADB 或检查驱动。

多设备

脚本中不要默认“只有一台设备”，应显式指定序列号：

adb -s <serial> shell getprop ro.product.model

网络调试会扩大攻击面，只在隔离测试网络中按 Android 当前官方流程启用，用完关闭并撤销配对。

3. 应用安装、启动与数据准备

adb -s <serial> install -r <app.apk>
adb -s <serial> uninstall <package.name>
adb -s <serial> shell pm list packages
adb -s <serial> shell pm clear <package.name>
adb -s <serial> shell am force-stop <package.name>
adb -s <serial> shell am start -n <package.name>/<activity.name>

• install -r 表示保留数据重新安装，但签名、版本和降级规则仍会影响结果。
• pm clear 会删除应用数据，必须在测试环境确认后执行。
• 启动入口可通过构建配置、包管理器或 dumpsys package 核验，不要依赖 top 猜包名。

现代 Android 的 Activity 生命周期应以官方文档和应用日志为准；“运行、暂停、停止、销毁”是便于理解的状态概括，不替代 onCreate、onStart、onResume 等真实回调验证。

4. 文件与 Shell

adb -s <serial> push <local-file> /sdcard/Download/
adb -s <serial> pull /sdcard/Download/<file> <local-dir>
adb -s <serial> shell

设备 Shell 权限受 Android 版本、应用沙箱、SELinux 与是否 root 影响。不要把能在工程机上运行的命令假定为所有量产设备都可用。

常用 Shell 组合

command-a | grep 'pattern'
command-a | awk '{print $1}'
while true; do
  command-a
  sleep 3
done

在 Windows PowerShell、cmd、macOS/Linux Shell 与设备 Shell 之间，管道、引号、变量和文本工具并不完全相同。复杂采集逻辑应明确在哪一层执行，并把脚本纳入版本管理和审查。

5. 输入、截图与录屏

adb -s <serial> shell input text '<text>'
adb -s <serial> shell input keyevent <keycode>
adb -s <serial> shell input tap <x> <y>
adb -s <serial> shell input swipe <x1> <y1> <x2> <y2> <duration-ms>

adb -s <serial> exec-out screencap -p > screenshot.png
adb -s <serial> shell screenrecord /sdcard/test.mp4
adb -s <serial> pull /sdcard/test.mp4 .

坐标脚本容易受分辨率、密度、旋转、系统栏和 UI 改版影响。稳定测试优先使用资源 ID、可访问性节点或游戏框架提供的语义定位；坐标输入适合快速验证和兜底。

不要把解锁密码写入脚本或日志，也不要通过输入注入绕过设备安全策略。

6. 性能数据采集

内存

adb -s <serial> shell dumpsys meminfo <package.name>

记录 PSS 及分类时，同时保存设备、系统、构建、场景和采样时间。一次不回落不能证明泄漏；应按固定步骤多轮采样，并结合对象快照或原生分配工具定位。

CPU 与进程

Android 不同版本的 top 参数和 CPU 口径可能不同：

adb -s <serial> shell top -b -n 1
adb -s <serial> shell dumpsys cpuinfo
adb -s <serial> shell pidof <package.name>

不要用“CPU 数值除以核心数”作为通用换算。某些工具以单核 100% 为上限，某些以整机 100% 为上限；先确认设备版本和命令输出定义。

采集设计

1. 测试开始前记录时间戳、版本和设备属性。
2. 启动被测场景并等待稳定。
3. 按固定间隔采集原始输出，原始数据不要只保留换算结果。
4. 对齐操作事件、日志、CPU、内存与帧时间。
5. 测试结束后归档 seed、脚本、异常截图和退出码。

7. Monkey 稳定性测试

Monkey 向应用或系统发送伪随机事件，适合发现崩溃、ANR 和脆弱状态，不等同于可验证业务结果的功能测试。

adb -s <serial> shell monkey \
  -p <package.name> \
  -s 300 \
  --throttle 300 \
  --monitor-native-crashes \
  -v -v \
  1000

• -p 限制目标包。
• -s 固定伪随机 seed，便于复现相近事件序列。
• --throttle 设置事件间隔。
• 多个 -v 提高日志详细程度。
• 忽略 crash/timeout 的选项会让测试继续，但不能把错误当作通过；流水线仍应解析并报告异常。

执行前关闭可能伤害数据或产生真实交易的入口，使用专用账号与测试环境。复现失败时保存完整命令、seed、设备状态、日志和应用版本。

8. Logcat

adb -s <serial> logcat -c
adb -s <serial> logcat -v threadtime
adb -s <serial> logcat -d > logcat.txt
adb -s <serial> logcat --pid=$(adb -s <serial> shell pidof <package.name>)

常见优先级为 Verbose、Debug、Info、Warn、Error、Fatal。缓冲区名称与可见权限随系统版本变化，可按需选择 main、system、crash 等。

日志本身可能包含用户数据、网络参数、Token 与内部地址。公开或上传前必须脱敏，生产应用也不应记录秘密。

9. 设备信息

adb -s <serial> shell getprop ro.product.model
adb -s <serial> shell getprop ro.product.brand
adb -s <serial> shell getprop ro.build.version.release
adb -s <serial> shell wm size
adb -s <serial> shell wm density
adb -s <serial> shell dumpsys battery
adb -s <serial> shell cat /proc/meminfo

IMEI、Android ID、MAC 等属于设备或个人标识符，权限限制严格，也不应作为普通测试报告的默认字段。仅在具有合法目的和最小必要性时采集，并遵守保存与脱敏要求。

10. 从命令走向自动化框架

一条可维护的自动化链路可拆为：

环境检查 → 安装/清数据 → 启动 → 执行业务动作
        → 并行采集日志与性能 → 断言 → 清理 → 报告

ADB 适合环境与设备层；Python 用于编排、解析和报告；Airtest/Appium 等用于 UI 或游戏交互。框架选择应服从定位稳定性、运行成本和可诊断性，而不是只比较 API 是否“方便”。

参考资料

• Android Developers：Android Debug Bridge
• Android Developers：UI/Application Exerciser Monkey
• Android Developers：Logcat command-line tool