Monkey测试这个活儿圈子里一直有两种声音。一种觉得它就是个“猴子”在屏幕上乱点属于毫无技术含量的稳定性测试跑就完了另一种则认为它真能炸出一堆偶现崩溃、ANR和内存问题是发版前最省心的兜底手段。我自己做移动端质量保障这么多年更偏向后者但前提是——你得会正确地用它。很多人跑Monkey就是一行adb shell monkey 10000跑完看个结果就收工。这其实浪费了Android官方这个工具大半的能力。今天这篇就把Monkey测试从原理到实操、从参数调优到日志定位、从坑点到扩展思路整个捋一遍希望能让正在用或者准备用的朋友少走点弯路。1. 先搞清楚Monkey到底在干什么1.1 一个简单的比喻请个“猴子”来砸场子Monkey是Android SDK里自带的一个命令行工具它的工作方式特别直白向系统发送伪随机的用户事件流比如点击、滑动、按键、系统事件模拟人胡乱操作手机时的场景。你可以把它理解为一只精力旺盛的猴子坐在你的App面前完全不按常理出牌到处乱按乱划。为什么要这么干因为真实用户里总有一些“特殊操作流派”——连点、快速滑动、后台切来切去、横竖屏切换、弱网加打断这些组合场景靠测试人员手工复现是很痛苦的。而Monkey能用极低的成本在短时间内制造成千上万次随机事件把App推到各种极限状态。很多低频偶现的崩溃、无响应ANR、内存泄漏往往就是在这种高频随机操作下现出原形。1.2 Monkey测试的价值边界不过得先把话说清楚Monkey不是万能的。它擅长的是“找崩溃”不是“找Bug”。它不校验业务逻辑对不对不关心界面显示是否符合预期它的评价标准就一条系统在大量随机操作下稳不稳有没有Crash、ANR、Native Crash以及CPU、内存有没有异常飙升。所以它最适合的场景是版本发版前的稳定性回归测试对已上线的老项目做兼容性摸底测试资源紧张时的冒烟兜底配合Monkey Runner或自研脚本做问题复现不适合的场景也很明确涉及业务流程正确性的功能测试、依赖账号状态和数据校验的用例、需要精确断言的UI自动化测试。这些是Appium、Espresso等工具的主场。1.3 谁应该认真读这篇文章如果你是个刚接触App自动化测试的新人能把Monkey命令跑通、看懂日志就已经超过大多数测试群里“只会跑命令”的同行了。如果你是有一定经验的测试开发这篇文章里关于参数组合调优、日志分析定位、CI集成和二次开发的思路应该能帮你把这套工具真正用出生产力。2. 动手之前把环境准备和核心原理吃透2.1 环境准备其实就一个命令的事Monkey是Android SDK自带的工具所以环境要求并不复杂一台电脑装好Android SDK Platform-Tools确保adb命令可用一台Android设备或模拟器开启开发者选项里的USB调试最好准备一台独立的测试机别拿主力机跑因为Monkey操作很“暴力”容易误触到系统设置、卸载应用甚至恢复出厂设置数据安全第一检查环境是否OK终端里执行adb devices能看到设备序列号就说明连接正常。接下来确认Monkey工具路径which monkey # 或者在Windows下直接在platform-tools目录中运行Monkey工具的本体其实是个脚本加JAR包组合其核心是一个monkey.jar安装在系统分区里。但你不用关心它装在哪因为adb shell monkey这个命令会自动把参数传给系统里的Monkey框架。2.2 Monkey的执行机制事件注入是怎么回事这里稍微讲点原理理解了它后面排查问题会顺很多。Monkey的运行依赖Android系统里的Instrumentation机制和Window Manager。当你在终端敲下adb shell monkey工具会做这么几件事解析命令行参数确定事件序列的生成策略连接活动管理器ActivityManager获取当前设备前台App的状态通过系统服务向窗口管理器WindowManager注入输入事件循环执行直到事件数量跑满或者遇到崩溃、ANR等终止条件事件注入的粒度很细包含ACTION_DOWN、ACTION_UP、ACTION_MOVE等触摸事件以及各种KeyEvent按键事件、系统级事件。Monkey自己维护一个事件源按策略随机选择下一个要发送的事件发送间隔由--throttle参数控制。这解释了一个关键问题为什么Monkey测试不能并行跑多个设备场景因为事件注入是全局的它操作的不只是你的App而是整个设备界面。如果同时开两个Monkey进程两个猴子互相抢设备焦点事件注入就会乱套测试结果自然不可信。所以跑Monkey时一个设备只跑一个Monkey进程这是基本原则。2.3 设备端状态检查清单正式开跑前建议做一轮快速检查App处于可测试状态能用adb shell am start拉起来别一启动就崩溃测试账号已登录基础数据已准备好Monkey跑起来不会帮你登录关闭系统自动更新、通知弹窗、锁屏避免外部干扰影响事件注入确认设备的“保持唤醒”已开启否则屏幕暗了Monkey的操作会出现大量无效事件每一条都有实际意义。第4条尤其常见——设备锁屏后Monkey还在疯狂注入事件结果注入到锁屏界面上测试对象压根没被覆盖到最后测了个寂寞。这种问题还不好定位因为日志里全是正常的事件记录。3. Monkey命令与参数一次讲透3.1 基础命令结构adb shell monkey [options] event-countevent-count是必填参数表示要发送的随机事件总数。options不需要时可以省略但实际测试中几乎都会用到。一个比较典型的完整命令长这样adb shell monkey -p com.example.app --throttle 300 -s 12345 -v -v -v --pct-touch 50 --pct-motion 20 --pct-trackball 0 --pct-syskeys 0 --pct-appswitch 5 --pct-anyevent 0 --ignore-crashes --ignore-timeouts --kill-process-after-error 10000这条命令有点长下面拆开逐个解释。3.2 关键参数详解与取值逻辑先把最常用的参数用一张表列出来参数作用实测建议-p 包名指定测试目标包可多个不写会作用到设备上所有App--throttle 毫秒每个事件之间的间隔300~500ms比较稳太短会导致事件丢失-s 种子值随机数种子复现用固定种子可复现同一序列-v日志级别最多三个-v定位问题建议用三个日志最详细--pct-touch 百分比触摸事件点击占比25~50--pct-motion 百分比滑动事件占比15~25--pct-trackball 百分比轨迹球事件占比手机设备建议0--pct-syskeys 百分比系统按键占比建议0~2太高会触发Home、音量等--pct-appswitch 百分比启动Activity的占比5~10模拟用户切换页面--pct-anyevent 百分比其他各类事件0~5--ignore-crashes遇到Crash不中断继续执行大面积扫查时建议开--ignore-timeouts遇到ANR不中断继续执行同上--kill-process-after-error出错后杀掉App进程再继续配合ignore系列参数使用百分比这块要重点说一句所有--pct-*参数的值加起来不需要等于100Monkey会丢掉未分配的部分或者按比例归一化处理。但各值最好有明确设计意图别全堆在一个类型上。我自己的经验是常规稳定性测试可以把触摸和滑动事件加起来占70%左右留一点给系统键和App切换。这样既保证了界面操作强度又能模拟用户偶尔按Home、切后台场景。但--pct-syskeys真的别给太高系统按键事件会打断当前Activity甚至拉到通知栏事件流会乱掉。3.3 日志级别与信息提取-v参数控制日志冗余级别从低到高分别是一个-v只输出启动信息、事件流基本信息和最终结果两个-v增加每个事件注入的Activity切换信息三个-v输出最详细的日志包含每个事件的类型、坐标等细节但日志细节多不代表一定要用三个-v。日常快速验证跑一个-v就够定位Crash时再用三个-v把输出重定向到文件方便回溯。adb shell monkey -p com.example.app -v -v -v --throttle 300 -s 12345 10000 monkey_log.txt 21这里的21很重要。Monkey的日志既有标准输出又有错误输出两个都重定向到一个文件才能完整记录整个执行过程。很多人第一次跑完发现日志文件是空的就是因为去掉错误输出给丢了。3.4 复现问题离不开的种子值-s参数是Monkey测试里被低估的宝藏。它指定随机数生成器的初始种子相同的种子值、相同的事件总数、相同的参数组合Monkey会生成完全相同的事件序列——也就是说你遇到一个崩溃只要把种子值记下来后续任何时候都能复现同一次“猴子行为”。排查问题时的标准流程是发现崩溃记录当前使用的-s 值、事件总数和所有参数用相同的命令重新跑一次看能否复现如果能复现缩小事件范围逐步定位是哪一类事件触发的实操中有些团队会把“种子值事件数参数”做成一条记录联同Crash日志一起归档到Bug描述里开发修复时就能精准复现。这比让开发自己盲猜复现路径省力太多。4. 实操过程完整跑一次Monkey测试4.1 第一次快速冒烟跑假设要测试的App包名是com.example.demo目标设备已经连接。我先跑一条最基础的命令验证工具链路是否顺畅adb shell monkey -p com.example.demo 1000这个命令没有设置种子和事件间隔Monkey会以最快的速度连续发送1000个事件。跑完终端会显示类似这样的统计信息Events injected: 1000 :Dropped: keys0 pointers0 trackballs0 flips0 ## Network stats: elapsed time56243ms (0ms mobile, 56243ms wifi) // Monkey finished只要出现Monkey finished且没有** Monkey aborted due to error基本说明链路正常。这一步的价值是快速判断App在当前状态下会不会“见光死”——如果连基础事件都扛不住后面就不用调参了先修Bug吧。4.2 一次经典稳定性测试的完整参数设计快速冒烟通过后进入正式的稳定性测试。我一般这样设计参数adb shell monkey -p com.example.demo \ --throttle 300 \ -s 20250115 \ -v -v -v \ --pct-touch 50 \ --pct-motion 20 \ --pct-pinchzoom 5 \ --pct-trackball 0 \ --pct-syskeys 2 \ --pct-appswitch 8 \ --pct-anyevent 5 \ --ignore-crashes \ --ignore-timeouts \ --kill-process-after-error \ 20000这里的事件总数是20000--throttle 300让每个事件间隔300毫秒。算一下总时长20000个事件每个事件之间平均300ms再加上事件本身执行和页面加载的时间整体跑下来大约需要1.5~2小时。这个时长合适——太短测不出问题太长占着设备也没必要。参数设计逻辑再讲透一点--pct-touch 50点击类事件占一半这是所有移动App最频繁的操作手势--pct-motion 20滑动手势覆盖列表滚动、轮播图切换--pct-pinchzoom 5双指缩放地图、图片类页面常用--pct-trackball 0手机设备没有轨迹球直接归零腾出占比给其他事件--pct-syskeys 2保留少量系统键验证Home键切后台后再回来的状态恢复能力--pct-appswitch 8模拟用户在App之间切换--pct-anyevent 5兜底事件类型保证事件源多样性跑完后日志尾部同样要出现Monkey finished或者对应的aborted原因。如果跑完没有任何异常恭喜至少说明这次版本的稳定性是过关的。4.3 测试过程中实时观察设备状态Monkey在跑的时候同时打开另一个终端窗口观察设备状态能抓到不少有意思的信息。CPU和内存adb shell top -n 1 | grep com.example.demoLogcat中的崩溃日志adb logcat -v time | grep -E FATAL EXCEPTION|ANR in|am_crash这两个窗口开着一旦Monkey执行出错你能立刻从Logcat看到对应的崩溃栈从top看到异常占用。这种边跑边观察的方式比跑完再回头翻日志高效得多。我自己还习惯在Monkey跑的过程中每隔几分钟截一次图用adb exec-out screencap -p screen.png导出来。别小看截图它记录的是崩溃发生时页面当时长什么样对开发排查“这个崩溃到底是怎么触发的”特别有用。4.4 日志结果怎么看Monkey测试结束后的输出分三部分第一部分是事件执行日志。格式类似:Switch: #Intent;actionandroid.intent.action.MAIN;categoryandroid.intent.category.LAUNCHER这里记录每一步在执行什么事件、切换到了哪个Activity。配合-v -v -v的详细输出可以还原出测试执行的时间线。第二部分是统计信息。Events injected: 20000 :Dropped: keys0 pointers0 trackballs0 flips0这里的Dropped统计丢掉的输入事件数量。如果这个值很大说明设备处理不过来或者有卡顿——系统已经把事件丢弃了Monkey是在“空转”测试的有效性会打折扣。第三部分是结果判定。Monkey finished全部事件执行完毕没崩溃测试通过** Monkey aborted due to error执行过程中遇到崩溃、ANR或超时被中断// CRASH、// ANR明文标识的类型看到Monkey finished还不能掉以轻心崩溃日志要在Logcat里翻一遍才算数因为有些Native层崩溃Monkey不会直接终止需要从Logcat的DEBUG、libc、Fatal signal等关键字里捞出来。5. 常见问题与排查技巧实录5.1 必坑指南我踩过的那些Monkey测试的坑Monkey测试看着简单实际操作层面坑是真不少。这里分享几个我踩过且印象深刻的坑一事件都注入到锁屏界面了。设备测试过程中屏幕休眠Monkey不会自动唤醒屏幕所有触摸事件全打在锁屏或熄屏上。测试跑完日志里全是正常事件记录但App实际一个事件都没收到。解决办法简单粗暴测试全程禁止锁屏或者用svc power stayon true保持屏幕常亮。坑二Monkey把系统设置的弹窗当成了测试目标。比如App崩溃后弹出系统的“应用已停止运行”对话框Monkey会把崩溃弹窗当成可点击界面继续点甚至点到“卸载应用”。所以测试机上别放重要数据权限弹窗尽量提前处理好该给权限的给权限该关通知的关通知。坑三测试开始没多久就遇到权限弹窗但权限弹窗不是目标App的WindowMonkey事件全部打在弹窗上后续所有点击事件都无效。这种问题怎么发现看日志里--pct-syskeys和弹窗切换记录能瞄出端倪更直接的办法是跑的时候多截图。我现在的习惯是测试前把全部运行时权限预先授权adb shell pm grant逐一处理然后再跑Monkey。坑四误用了旧版SDK的Monkey很多新参数不支持命令行直接报错。比如--pct-pinchzoom在旧版中不存在。解决办法是升级Platform-Tools到最新版并确认设备系统版本不要太老。5.2 拿到崩溃日志后如何快速定位Monkey测试的价值在于发现问题但这还不够关键是问题的定位效率。拿到一份Crash日志我一般按下面这个顺序排查第一步看是不是App自身的崩溃。搜索FATAL EXCEPTION向下找到Process: com.example.demo和Caused by:。这一段基本就是崩溃的根因。第二步看崩溃发生的Activity和事件上下文。回到Monkey日志找到崩溃前的最后几条事件记录看是在哪个Activity、哪个页面。比如日志显示正在相册页滑动时崩溃问题大概率出在图片加载或内存处理上。第三步结合设备状态判断是不是资源问题。看崩溃时间段top输出里的内存占用如果接近系统上限很可能是OOM被系统杀死这种通常和图片缓存、WebView内存泄漏挂钩。第四步用种子值复现并精简。把-s种子固定事件总数慢慢缩小比如从20000降到5000、再降到1000看能不能用更短的事件序列复现同一个崩溃。复现出来之后连测试参数一起提给开发开发照着跑就能复现不用自己绞尽脑汁去构造路径。ANR问题稍微特殊一点。Monkey日志里出现ANR in com.example.demo通常还要去/data/anr/目录拉trace文件adb shell ls /data/anr/ adb pull /data/anr/traces.txt这个trace里记录了ANR发生时各个线程的调用栈看主线程卡在什么地方问题就基本清楚了。5.3 常见问题速查表现象最可能的原因解决方案monkey aborted但没有崩溃栈事件序列变化导致状态异常查看Logcat中临近时间的Activity切换记录测试提前结束日志显示ANR有耗时操作阻塞主线程拉取/data/anr/traces分析调用栈测试过程中网络异常Wi-Fi不稳定或系统休眠断开使用有线连接或关闭Wi-Fi休眠策略事件数跑完了但日志不完整日志被系统缓冲区覆盖增加-v数量输出重定向到文件跑完发现App数据被清空了--pct-syskeys触发系统设置操作降低系统键占比加--pkg-blacklist-file排除系统应用崩溃复现不出来种子值或事件参数对不上完整记录命令参数和Logcat时间戳Native层崩溃Fatal signal内存越界或so库问题结合tombstone日志分析5.4 对测试结果保持警惕Monkey测试绿的不代表App稳定性真的没问题。有一个很容易被忽略的现象Monkey的事件是随机且不带业务语义的它很难触发需要特定业务前置条件的页面。比如一个支付流程需要登录、选择商品、确认订单三步Monkey大概率不会那么“巧”地把这三步全部操作对。所以Monkey测试覆盖到的是“通用交互稳定性”业务链路相关的稳定性还要靠自动化测试用例补。另外我遇到过几次情况Monkey测试过程中App没崩但后台日志显示大量内存泄漏。这是因为Monkey的操作节奏偏快有些泄漏需要长页面停留、多次进出才能累积到崩溃阈值。所以严谨的团队的每次Monkey测试后还要补一轮adb shell dumpsys meminfo分析对比测试前后同一场景的内存占用变化。6. 如何把Monkey测试做出工程化价值6.1 在CI流水线里接入Monkey测试基础跑法通了之后接下来值得做的事就是把Monkey测试接到持续集成流水线里让每次构建都自动跑一轮稳定性冒烟。一个可参考的流水线设计构建阶段打包Debug/Release APK并签名部署阶段通过adb安装到测试设备集群执行阶段按预设参数跑Monkey测试事件总数按每日回归和发版前分级数据采集阶段自动拉取Logcat、Monkey日志、截图、崩溃日志结果判定阶段解析日志关键字生成HTML报告有Crash/ANR则挂掉Pipeline通知阶段失败时自动推送消息到IM群这里最难的一点是设备和CI的集成。设备多了之后真机管理平台需要维护一套设备分配和清理机制避免多个任务抢占同一台设备。现在有Sonic云真机、AtxServer2等开源自研平台可以配合本质上是把Monkey命令封装成平台任务由平台统一调度和执行。6.2 基于Monkey日志做二次开发有人觉得Monkey只能输出日志不能自己控制其实不然。Monkey的日志格式是固定的解析起来并不难。你可以写个小脚本把--pct-*分布、事件注入量、异常类型做成可视化报表。更进一步Monkey还有--script参数可以指定一个脚本文件在随机事件流之外插入特定操作。比如在随机点击的间隙插入一段“登录”操作这样即使前置条件复杂Monkey也能在业务状态下跑圈。脚本文件的基本格式是// 等待2秒 type wait duration 2000 // 点击坐标(100,200) type tap x 100 y 200 // 启动指定Activity type launchActivity activity com.example.demo/.MainActivity这种脚本用法适合做“登录后无人值守的随机稳定性测试”比纯随机事件又多了一层业务覆盖。实际使用中需要配合--script file.txt参数传入脚本。6.3 与其他稳定性测试工具的搭配思路Monkey不是唯一的选择但它是性价比最高的入门方案。和市面其他工具放一起对比它的优劣势很清楚工具核心能力优势劣势Monkey随机事件注入系统自带、零依赖、上手快无业务断言、随机不可控Maxim智能遍历Monkey扩展可配置事件策略、更智能的点击需要额外安装、维护成本AppCrawler自动遍历爬取基于页面遍历的深度测试对复杂页面适配有要求自研脚本定制事件流完全可控开发成本高实际工作里我的组合拳一般是优先用Monkey做常规随机稳定性测试配合每次发版再用Maxim或AppCrawler做版本重点功能的深度遍历在发版前补一轮。两者覆盖维度不同——Monkey覆盖的是“无序操作下的系统稳定性”遍历工具覆盖的是“功能路径可达的完整性”。6.4 把Monkey测试结果变成团队能看懂的结论最后想聊一个容易被忽视的点测试结果输出。很多团队跑完Monkey把日志扔到群里就完事了其他人根本看不懂。我的经验是每次跑完输出一份简版报告内容包含测试环境设备型号、Android版本、App版本测试参数种子值、事件总数、事件类型占比结果统计总事件数、实际注入数、丢弃数异常清单崩溃类型、发生的Activity、疑似原因分析复现步骤种子值、最小化事件序列这份报告用固定模板生成统一存档。这样不仅开发能快速定位问题连续几个版本跑下来还能对比出稳定性趋势——比如某个版本的Crash率从3%涨到10%那说明这个版本引入了明显的稳定性回归测试同学在评审会上就有据可依了。7. 关于Monkey测试我最后想说的话Monkey测试这个东西工具本身很简单但真正能把它用出价值的人往往都是那些肯在日志分析、参数设计和流程规范上花功夫的测试工程师。我见过太多人把Monkey当成“跑一跑交差”的任务写完报告就完事结果稳定性的坑留到线上被用户踩。我个人实际工作里最受益的一个习惯是每次Monkey测试前先把测试目标和预期结果写清楚——是验证新版本没有崩溃还是排查某个历史Bug是否修复还是摸底某个新引入的三方SDK稳定性目标不同参数设计的侧重点就完全不同。带着目标去跑跑完后才有底气说“这个版本稳定性状态如何”。如果你所在的项目还没有把Monkey测试纳入日常回归体系建议从下一次构建开始加一条最简单的任务指定包名、固定种子、跑5000个事件输出一份日志存档。坚持几个版本之后你再回头看会发现这项工作早就不只是“让猴子乱按”那么简单了。