移动APP测试实战：从Genymotion环境到adb性能与稳定性命令详解

简介：面向移动端测试工程师的APP测试精编合集，内容覆盖从环境搭建到性能分析的完整知识链。资料为PDF文档，共1个文件，包体仅1020KB，便于碎片时间学习与移动端查阅；目前已有230人浏览学习，适合初入行的功能测试、转岗移动测试的读者系统梳理知识体系。文档从Genymotion安卓虚拟环境入手，详细拆解adb安装、卸载、查看包名、文件拉取与导入等高频命令，随后梳理APP安装、卸载、功能、业务、性能等常见测试类型，并涉及Fiddler抓包与JSON数据交互。针对安卓四大组件、日志查看、进程与用户ID隔离、冷热启动时间、Dalvik与native堆内存等性能指标做了实用笔记整理，可帮助测试人员快速定位问题并开展专项测试。整体以笔记式要点呈现，适合随时查阅、补足移动APP测试的知识盲区。

1. 移动APP测试的起点：不是用例，是环境

很多团队开始做移动APP测试时，第一反应是先写功能用例，再拿一台真机到处点。我们早期也这么干，结果大量时间浪费在找设备、等安装、手动清缓存上，真正验证业务的时间反而被压缩。后来把 Genymotion 虚拟环境加 adb 命令作为第一道关卡，整个测试才变得可复现。这份移动APP测试相关的整理资料最早是一份 PDF，团队里不少人习惯先转成 Word 再做标注，但真正值钱的是里面那些可以直接落地的命令和参数：多设备安装、包名查询、内存与 CPU 定位、Monkey 稳定性验证。适合刚接触移动APP测试的测试工程师，也适合已经跑过功能用例、想补上性能与稳定性方法论的老手。

2. 先搭一台可控的测试机：Genymotion 与 adb 命令速查

2.1 为什么测试环境要选 Genymotion 而不是直接上真机

Genymotion 是安卓虚拟环境，优点是快照、重置、多开非常方便。尤其是跑 Monkey 或者异常测试之后，系统状态可能已经乱掉，真机恢复需要重新刷机或等很长时间，Genymotion 只需要恢复快照，秒级回到干净环境。我的建议是：日常功能、性能、稳定性测试放在 Genymotion 上，真机留给兼容性阶段的特定厂商机型验证。安装 Genymotion 后，需要把它的 tools 目录加进环境变量，通常是 C:\Program Files\Genymobile\Genymotion\tools，否则 adb 命令会报“不是内部或外部命令”。

2.2 adb 设备连接与多设备安装

adb 全称 Android Debug Bridge，也就是安卓调试桥。连接多个虚拟设备时，每个设备在 adb devices 里显示为 IP 地址加端口号。之前我们一度以为每次只能装一台，直到项目要求同时跑不同 Android 版本的虚拟设备，才意识到-s参数才是多设备并行的关键。

adb devices adb install D:\ecmobile3.2.apk adb -s 172.31.129.22:5555 install D:\ecmobile3.2.apk adb uninstall com.example.app adb -s 172.31.129.22:5555 uninstall com.example.app

第一行查看已经连接的设备，会显示对应的 IP 和端口。第二行是单设备安装，适用于只有一台设备的情况。后面两行是在多台设备共存时必须加-s IP:端口，否则 adb 会提示有多台设备、不知道操作哪一台。读取包名后再用 shell 确认是安装到了目标设备，避免测了半天发现装的旧包。

2.3 用 aapt 从 APK 里取出真正的包名

安装、卸载、Monkey、清数据，全都依赖包名。APK 文件名称往往和包名不一致，例如 ecmobile3.2.apk 的实际包名可能是 com.ecmobile.app。最好的做法是在安装前直接用 aapt 读取。

aapt d badging D:\ecmobile3.2.apk | find "package"

Windows 下过滤用 find，注意过滤条件要加双引号；macOS 或 Linux 下把 find 换成 grep。这条命令输出的 package 行里，name='com.example.app' 就是要找的内容。拿到包名后，后面所有命令行操作都会顺畅很多。

2.4 进入安卓系统并理解关键目录

执行 adb shell 后，会进入一个类似 Linux 的环境，常用命令都可以直接用。但真正有用的是理解几个目录在测试中的价值。

adb shell cd /data/data/com.example.app ls

进入目录后可以看到 databases、shared_prefs、cache 等子目录。shared_prefs 通常只有应用真正进入过系统才会生成，如果还没有登录过就有这个文件，反而要怀疑是否有非预期初始化。databases 下会有 ecmobile.db 和 ecmobile.db-journal，前者是数据库文件，后者是日志文件，回滚和崩溃恢复都靠它。

2.5 文件进出安卓系统：pull 与 push

模拟器里的数据有时需要导出到宿主机分析，比如 GC 日志、Monkey 日志、Emmagee 生成的报告。

adb pull /system/GCfile.txt D:\GCfile.txt adb push D:\app.apk /data/local/tmp/app.apk

pull 是把安卓系统里的文件拉到宿主机，push 是从宿主机推到安卓系统。最容易踩的坑是路径分隔符：Linux 里用斜杠/，Windows 里用反斜杠\。如果 push 到/data/local/tmp遇到权限问题，可以先看目标目录是否可写。修改系统级文件前也需要先挂载，常见做法是执行 mount 命令重新挂载 /system，再 chmod 777 /system，这样才能编辑 /etc/hosts 做域名绑定，模拟线上环境指向测试服务器。

3. 性能测试抓数据：启动时间、内存与 CPU 的量化方法

3.1 先分清负载、压力、容量和 APP 性能维度

移动APP测试里的性能测试，容易一上来就盯着工具看，但维度选错了会白测。在 PC 端性能测试中，负载测试是在不同负载下看系统各项指标是否和需求说明书一致，同时测出最大负载和最佳负载，针对的是系统能力；压力测试是在极限负载下看系统能否长时间稳定运行，针对的是耐力；容量测试则针对数据库容量、带宽等资源上限。

APP 侧性能测试更关心另一组指标：启动时间、切换时间、存储空间、内存、CPU、GPU、流量、功耗。这些数据不能只看一次，必须做横向和纵向对比。横向是跟竞争对手的同类功能比，纵向是跟自己的历史版本比。所以我们的习惯是每轮迭代都保留一份基线数据，否则后面拿到一个新版本，根本说不清启动时间变长了是回归还是正常波动。

3.2 启动时间：首次启动、热启动与冷启动的区别

启动时间是用户感知最强的指标。首次启动是安装后第一次运行，涉及资源初始化、数据库创建，通常最慢。非首次启动又分热启动和冷启动：热启动时 APP 对应进程还活着，冷启动时进程不存在。很多 APP 并支持表面上直接杀掉进程再打开，但那种情况不一定算冷启动，正确的做法是在安卓系统里杀掉进程后再启动。

adb shell ps | grep com.example.app adb shell am force-stop com.example.app adb shell am start -W -n com.example.app/.MainActivity

先用 ps 看进程是否在运行，再用 am force-stop 杀掉进程，最后用 am start -W 启动并输出启动耗时。注意启动时间不只包含 Activity 创建，还要把欢迎页和首页加载时间一起算进去，所以一般会用 Logcat 里的 Displayed 字段来校准。

adb logcat -v time | find "Displayed"

Displayed 后面会显示 MainActivity 加耗时，比如+1s234ms。不同版本的 Android 输出格式略有差异，但这是直接反映首屏可交互时间的可靠来源。

3.3 内存：native 堆、Dalvik 堆与 OOM

安卓内存可以从两个角度看：native 堆内存主要由镜像文件生成，/data/data/包名/lib 里的 .so 文件是主要来源；Dalvik 堆内存是 Java 程序产生的，我们可以通过系统配置看到堆的限制。

adb shell cat /system/build.prop | grep heap

不同设备输出电压略有不同，但关键参数是这几项：

很多 OOM 不是内存真的不够，而是超过 heapgrowthlimit。当 APP 打开一张超大图片时，内存瞬间暴涨，最容易触发这个问题。查看每个应用的内存占用时，用 adb shell top 动态采样。

adb shell top -n 400 | grep com.example.app adb shell procrank

-n 400表示采样 400 次，grep 过滤出目标进程，避免屏幕信息过多。procrank 能看到更精细的内存排行。这类命令更适合在脚本里跑，把输出重定向到文件，再用 Excel 整理 PSS 变化曲线。

3.4 GC 日志与 APP 占用空间

GC 垃圾回收在移动端是个容易被忽略的性能点。GC 频率过高，表现为界面卡顿、电池消耗变快。抓 GC 日志需要先挂载系统目录，因为日志要写到 /system 下面。

adb shell mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system chmod 777 /system logcat -v time -v threadtime | grep GC > GCfile.txt Ctrl+C

挂载时报错时，通常是 /system 分区格式或设备节点路径不对，网上常见的命令是 yaffs2，但现在的模拟器更多是 ext4，需要先用 df 看一下 /system 的实际挂载点。日志拉到宿主机后，用 Excel 打开，重点看 GC 次数、暂停时间和 free 值的变化。

APP 占用空间也属于性能的一部分，不能只靠手机设置里的存储信息，命令行下更直接：

adb shell du -sH /data/data/包名

第一次执行和几分钟后再执行，数值可能都会变化。所以这个值要多次采样取平均值，不能拿第一次的结果当结论。

3.5 CPU、GPU 与功耗的测试工具

CPU 测试常用 Emmagee，这是网易开源的一款 APP 性能测试工具，项目里叫它“机关枪”。流程很简单：在 Genymotion 里安装 Emmagee，选择被测应用，点击开始，操作完业务后停止，工具会把数据导出到 /sdcard 目录。退出安卓系统后执行 adb pull 把结果拉出来。

GPU 测试更多靠开发者选项。在设置里打开“显示 GPU 过度绘制”，杀掉进程重新打开软件，界面会显示不同颜色的图层。颜色越深说明同一区域绘制次数越多，浪费 GPU 资源，也很耗电。过度绘制类 bug 一般定级不高，常见是 p3 或 p4，但在低端机上影响明显，不能因为级别低就不提。

功耗测试有个更简单的办法：安装前记录电量，安装后记录电量，两者相减就是安装功耗。使用功耗则要在固定亮度、关闭后台的情况下跑 30 分钟标准业务，对比前后电量变化。

4. 稳定性、异常与弱网：Monkey 随机事件流和网络工具

4.1 Monkey 参数到底怎么传

Monkey 是安卓系统自带的命令行稳定性测试工具，通过向系统发送伪随机用户事件流来模拟点击、滑动、多点触控和手势输入。Monkey 不是 PK 工具，它只负责制造事件，判断 APP 是否崩溃是我们要做的事。

adb shell monkey -p com.example.app --throttle 500 -s 9 -v -v -v 1000 > D:\monkey_log.txt

这条命令的参数含义是：-p指定被测包名，--throttle 500表示每个事件间隔 500 毫秒，-s 9是随机种子，-v是日志级别，连续三个-v输出最详细日志，1000是事件总数。实际执行时，种子很重要：如果测试发现问题，用同一个种子可以复现同样的事件序列。日志要重定向到宿主机文件，而不是直接打印在屏幕上，否则几十万行日志完全没法看。

Monkey 测试之前，建议先用 simiasque 这个 apk 工具屏蔽通知栏。否则随机事件很容易把通知栏滑下来，干扰被测应用，日志里会出现大量与业务无关的点击。测试结束后，不要只看最后结果，直接在日志里搜关键字：

findstr /C:"ANR" /C:"Exception" /C:"Crash" D:\monkey_log.txt

在 Windows 上用 findstr，Linux 下用 grep。如果日志最后一行是 monkey finished，表示执行完成；如果中间出现 ANR、Exception 或 Crash，就要定位具体页面并报 bug。经验值是 3 万事件以内出现一次 Crash，系统的稳定性已经算比较糟糕，需要优先处理。

4.2 异常场景设计不只是断电

稳定性测试除了 Monkey，还要覆盖功能使用过程中的异常。最典型的是断电重启：APP 写了一半数据，突然断电，重启后数据库能不能通过 journal 文件恢复。另一个场景是网络中断：先把网络断开，卸载应用，重新安装，进入软件首页发现空白，这时再打开网络，页面还是空白，这就是一个真实 bug。

adb shell rm -rf /data/data/包名/cache/* adb shell ls /data/data/包名

清除缓存也会暴露问题。很多 APP 的缓存文件被随手写在私有目录下，卸载之前记录缓存文件数量，重新安装后对比数量，如果少了关键文件，可能出现登录态失效、图片丢失等问题。还要注意 APK 文件名不要包含中文，某些测试渠道或自动化脚本对中文文件名的处理并不可靠，一旦安装不上，优先怀疑这一点。

4.3 弱网与网络切换：参数怎么设

网络测试在真实项目里经常被忽略，等用户反馈“加载不出来”才想起来补。弱网工具推荐 Windows 下的 Network Link Simulator，也可以直接用之前准备好的网络模拟工具。安装完成后，新建一个 Link，需要配置上行速率、下行速率、丢包、错误和延迟这几个参数。

注意方向问题：上行的方向是客户端到服务端，下行是服务端到客户端。最初版本里把这组概念写反过，结果测出来的下载问题被当成了上传问题，排错方向完全对不上。设置完参数后，要在 Filter 里添加要模拟的网卡，选择 Dialup 56k 这类预设场景，然后点击 Start，再去操作 APP 的核心流程。

不同网络之间的切换也要测试，例如从 WiFi 切到 4G，再切到 3G。切换过程里 APP 是否重新发请求、页面是否长时间白屏，都是常见问题。业务抓包时，Fiddler 只能抓 HTTP 协议包，对原生 APP 的私有 TCP 或 UDP 协议无能为力，所以它更适合验证 WebView 页面和 HTTP 接口。Fiddler 的 Tools-Options 里可以设置解码，Inspector 面板查看 JSON 子请求，AutoResponder 编写自定义响应，Filters 按 host 过滤出我们要看的域名，这样日志不会被无关请求淹没。

5. 兼容性、易用性与回归：把测试经验沉淀成可复用清单

5.1 兼容性矩阵别贪多，按用户设备收敛

安卓系统碎片化是绕不开的问题，各厂商软硬件差异直接在测试里表现为安装失败、闪退、权限弹窗不一致。做兼容性测试时，维度要覆盖厂商、屏幕尺寸、屏幕像素、分辨率和权限设置。厂商至少包含华为、小米、OPPO、vivo 这几类主流 ROM，屏幕尺寸从 4 寸到 6.7 寸都要有代表机型，像素密度决定图片是否模糊或内存占用。很难把所有机型测一遍，合理做法是借助阿里云 mqc、百度云测、testin、腾讯优测这类平台做云端兼容性遍历，再针对用户占比最高的 TOP 10 机型做线下真机抽查。

5.2 易用性检查：开发者选项里的可视化入口

易用性不能只靠主观感受。在开发者选项里打开“显示布局边界”，可以看到每个按钮的实际点击范围。常见问题是按钮视觉区域小，但布局边界特别大，用户点旁边也会触发，造成误操作。还要检查图标在无字模式下能不能被识别，以及界面层级是否过深。通知栏测试也可以在这里一起验证：锁屏键、HOME 键、BACK 键按下后，系统会给 APP 发送广播，如果 APP 注册了 receiver，就会触发特定功能，需要分别确认回到前台后的页面状态和业务数据。

5.3 回归时快速启动被测页面

从测试计划、测试方案、用例设计到预测试、执行和回归，每个项目都会走一遍。回归测试阶段最怕的是连被测入口都找不到。我们会在用例评审前先整理一张 APK 清单，用 aapt 批量提取包名和启动 Activity，然后用 adb 直接拉起页面。

adb shell am start -W -n com.example.app/.MainActivity

这条命令可以直接启动指定页面，-W参数会等待启动完成并输出耗时，适合把回归测试第一步固定下来。对比历史版本的启动时间，比用秒表手工计时要准确得多，也能直接反馈到性能基线上。

本文还有配套的精品资源，点击获取