移动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 packageWindows 下过滤用 find注意过滤条件要加双引号macOS 或 Linux 下把 find 换成 grep。这条命令输出的 package 行里namecom.example.app 就是要找的内容。拿到包名后后面所有命令行操作都会顺畅很多。2.4 进入安卓系统并理解关键目录执行 adb shell 后会进入一个类似 Linux 的环境常用命令都可以直接用。但真正有用的是理解几个目录在测试中的价值。目录作用测试上的用途/data/app已安装 APK 文件验证安装文件是否存在/data/dalvik-cachedex 可执行文件首次启动变慢时关注/data/data/包名/databases用户数据库和 journal 日志数据清理、回滚验证/data/data/包名/shared_prefs用户设置 xml 文件登录态、偏好设置验证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.apkpull 是把安卓系统里的文件拉到宿主机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 DisplayedDisplayed 后面会显示 MainActivity 加耗时比如1s234ms。不同版本的 Android 输出格式略有差异但这是直接反映首屏可交互时间的可靠来源。3.3 内存native 堆、Dalvik 堆与 OOM安卓内存可以从两个角度看native 堆内存主要由镜像文件生成/data/data/包名/lib 里的 .so 文件是主要来源Dalvik 堆内存是 Java 程序产生的我们可以通过系统配置看到堆的限制。adb shell cat /system/build.prop | grep heap不同设备输出电压略有不同但关键参数是这几项参数名含义dalvik.vm.heapsize256m进程可申请的最大堆dalvik.vm.heapstartsize8m进程启动时分配的堆dalvik.vm.heapgrowthlimit96m超过该值容易产生 OOMdalvik.vm.heaptargetutilization0.75堆空间利用目标dalvik.vm.heapminfree512k堆释放后的最小空闲dalvik.vm.heapmaxfree8m堆释放后的最大空闲很多 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 CtrlC挂载时报错时通常是 /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但在低端机上影响明显不能因为级别低就不提。维度工具或命令关注点CPUEmmageeCPU 占用率、瞬时尖峰GPU开发者选项显示 GPU 过度绘制图层数量、耗电存储du -sHAPP 数据膨胀功耗电量统计安装、待机、使用功耗功耗测试有个更简单的办法安装前记录电量安装后记录电量两者相减就是安装功耗。使用功耗则要在固定亮度、关闭后台的情况下跑 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 上用 findstrLinux 下用 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需要配置上行速率、下行速率、丢包、错误和延迟这几个参数。参数建议初始值说明上行速率128kbps客户端向服务端发送数据下行速率512kbps服务端向客户端发送数据Loss2%丢包率Latency200ms延迟Error0.1%错误率注意方向问题上行的方向是客户端到服务端下行是服务端到客户端。最初版本里把这组概念写反过结果测出来的下载问题被当成了上传问题排错方向完全对不上。设置完参数后要在 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参数会等待启动完成并输出耗时适合把回归测试第一步固定下来。对比历史版本的启动时间比用秒表手工计时要准确得多也能直接反馈到性能基线上。本文还有配套的精品资源点击获取