简介面向移动APP测试方向的初学者和测试工程师这份精编资料以Android环境为核心系统整理了APP测试需要掌握的知识点。内容先介绍Genymotion模拟器和adb常用命令涵盖设备连接、apk安装卸载、包名查看、文件导入导出等高频操作随后梳理APP常见测试类型包括安装测试、卸载测试、功能测试、功能交互、通知栏测试、双卡双待测试并逐一介绍activity、service、broadcast receiver、content provider等Android四大组件在测试中的关注点再进一步涉及Fiddler抓包、JSON数据校验以及性能测试中的启动时间、切换时间、内存堆内存等关键指标帮助读者理解从环境准备到业务功能、性能验证的完整测试链路。资料为单个PDF文件大小约1020KB结构紧凑按主题分段便于离线阅读和目录检索。已有230人学习下载适合随身速查也可作为面试前快速回忆体系化知识的索引。1. 拿到“移动APP测试大全精编资料.pdf”后先别急着翻页一份以“大全精编”命名的移动APP测试文档价值从来不是因为它写得全而是因为它能帮你在一小时内列出一份不重不漏的测试基线。移动APP测试的麻烦在于维度太多功能、兼容、性能、弱网、存储、安全、自动化回归每一类都有独立工具链和判定口径新手容易被“功能test pass”带偏老手则容易在重复劳动里漏掉边缘场景。我拿到这类PDF时惯常做法是把它当成三层东西看第一层是知识索引告诉我哪些维度必须覆盖第二层是参数基线告诉我各维度用什么命令和阈值去判定第三层是可以直接改造成回归用例的检查清单。下面按这个思路把移动APP测试拆成能落地的执行路径每一步都给命令和参数不写空话。2. 从资料到用例移动APP测试的功能与兼容性分层2.1 先按测试金字塔给移动APP测试分层再决定人力往哪放移动APP测试最忌讳一上来就对着界面点。我拿到“大全精编”这类资料后第一步永远是先把测试范围压到金字塔结构里底层是单元与接口测试能自动化就自动化跑得最快中间层是业务逻辑与集成测试用真机或模拟器跑顶层是UI与端到端场景这部分人力最贵留给高频核心路径。一个容易忽视的事实是——移动APP测试里真正消耗资源的是顶层界面的碎片化回归而不是底层逻辑。因此在设计用例之前先按下表把维度、时机与负责人理清楚再写具体用例测试维度执行时机核心手段责任角色功能测试每个迭代冒烟、全量前用例设计手工/UI自动化测试工程师兼容性测试发版前、系统大版本更新后真机矩阵云真机抽样测试工程师性能测试版本稳定后、发布候选阶段adb/PerfDog等采集性能测试或开发弱网测试弱网场景相关的功能合入后Fiddler/Charles真实弱网测试工程师安全测试上线前专项、渗透演练静态扫描抓包渗透工具安全测试工程师稳定性测试合码后冒烟前、夜间回归Monkey/Appium长跑测试工程师分层完成后你会发现一个常见问题功能测试用例写得过细导致每次发版要回归一整天而兼容性测试却只靠两台模拟器草草收场。正确顺序是先定兼容性矩阵再倒推功能用例的优先级因为兼容性往往是返工成本最高的维度。2.2 用设备矩阵收敛兼容性测试成本而不是堆设备兼容性测试的经典误区是“越多越好”。实际上Android碎片化的核心变量是系统版本、屏幕分辨率、厂商ROM和内存档位这四个维度用正交表各取两到三个典型值就能覆盖八成以上线上问题。我常用的做法是维护一张设备矩阵表每行一台设备每列一个关键特征设备代号系统版本分辨率厂商ROM内存用途D1Android 131080p原生8GB主功能回归D2Android 10720p厂商A4GB低端机验证D3Android 142K厂商B12GB大屏适配D4iOS 最新全覆盖不涉及不涉及视觉与交互一致性矩阵里的D1负责主流程D2负责内存压力下的稳定性D3负责高分辨率下UI错位与字体缩放D4作为跨平台参照系。用这个矩阵把功能用例按“高、中、低”三个优先级打标只有高优先级用例需要在全部设备上跑中优先级跑D1与D2低优先级只在D1上跑。这样兼容性测试的时间可以从三天压到半天同时不会漏掉关键路径的系统版本差异。2.3 云真机与本地机群怎么选本地机群适合需要反复插拔U盘、调试蓝牙外设、读取OTG设备的场景而覆盖碎片化机型、快速在不同系统版本间切换时公有云真机平台更划算。云真机的优势不是设备多而是矩阵数据可复用——每次发版前可以按同一套矩阵脚本并行执行冒烟用例结果自动归档。不过在链路设计上要注意云真机的弱点是网络环境不可控任何涉及弱网、音视频实时传输的用例都不要放到云真机上跑否则结果不具备参考性。对这类用例保留两台本地真机用路由器限速或Fiddler延迟注入来做。3. 用 adb 命令把性能测试变成移动APP测试的固定动作3.1 冷启动耗时用 am start -W 拿到权威数据移动APP测试里的启动耗时以系统给我的数据为准而不是拿秒表测。adb shell am start -W会直接输出启动过程中的关键时间点是Android平台上最基础也最被低估的性能测试命令。# 先强制停止目标应用保证冷启动环境干净 adb shell am force-stop com.example.demo # 启动并等待Activity完全绘制完成 adb shell am start -W com.example.demo/.MainActivity输出里有三个关键字段ThisTime表示最后一个Activity启动耗时TotalTime表示启动过程中所有Activity的总耗时WaitTime包含系统进程调度等额外等待。判定基线通常看首次冷启动TotalTime——中低端机型不超过2秒高端机型控制在1秒以内复测三次取中位数避免单次偶发波动造成误判。注意am force-stop只杀进程不清理缓存如果需要模拟“安装后首次启动”的极限条件还要追加清缓存命令。# 清除应用全部数据模拟首次安装后的启动环境 adb shell pm clear com.example.demo3.2 帧率与卡顿读 dumpsys gfxinfo 的 janky 行手游和短视频应用最关心的流畅度指标在Android上可以通过gfxinfo拿到逐帧数据。这个命令对移动APP测试的意义在于它能给出卡顿发生的精确时刻而不是只报一个平均帧率。平均帧率会掩盖掉周期性掉帧的问题——只要有一两秒的顿挫平均帧率看起来还是接近60但实际上用户已经感知到卡了。# 重置帧率统计信息保证从当前时刻开始采集 adb shell dumpsys gfxinfo com.example.demo reset # 让应用执行3-5分钟核心场景操作然后再执行下面命令读取统计结果 adb shell dumpsys gfxinfo com.example.demo在输出内容里需要重点关注Janky frames的总数与比例以及50th percentile、90th percentile、95th percentile这些帧耗时百分位。判定基线是这样中端机在滚动列表场景下Janky frames占比不超过10%90%帧耗时控制在16毫秒以内只允许偶尔超过这个值。如果95%分位帧耗时超过32毫秒说明存在肉眼可见的卡顿需要结合HWC和SurfaceView信息进一步定位。3.3 CPU、内存、流量与功耗四个命令各管一边移动APP测试里性能问题很少只出现在单一维度上。CPU飙高往往伴随内存抖动流量的异常浪涌又可能拖垮整个应用的响应速度。把这四个维度做成固定采集模板比临时查命令更靠谱。# 抓取应用进程CPU占用率采样5次间隔2秒 adb shell top -n 5 -d 2 | grep com.example.demo # 读取Java堆与Native堆使用情况 adb shell dumpsys meminfo com.example.demo # 抓取各UID的流量统计重点看应用启动、刷新、后台三段的差值 adb shell cat /proc/net/dev # 更精确的做法是读取应用UID对应的/proc/uid_stat/目录 adb shell cat /proc/uid_stat/uid/tcp_rcv adb shell cat /proc/uid_stat/uid/tcp_snd功耗测试分两条路径精细路径用dumpsys batterystats采集各应用耗电占比与唤醒锁持有时间快速路径直接在真机上把屏幕亮度固定为50%后台静置8小时对比前后电量差。无论哪条路径都要保证测试过程中没有其他应用在后台下载或同步数据否则功耗数据完全不可信。采集这些数据时我一般会在同一台设备上连续跑三轮取中位数报告避免单次结果受系统后台Job的影响。这里踩过的一个典型坑是拿开发机的模拟器性能数据当Android真机的性能基线两者完全是两个量级没有可比性。4. 弱网、存储与稳定性移动APP测试里最容易漏的三个场景4.1 用 Fiddler 模拟弱网参数调到真弱而不是假弱移动APP对弱网的反应是很多线上故障的源头。常见做法是用Fiddler的CustomRules.js做延迟注入但很多人把参数调得太温和——延迟50毫秒根本算不上弱网只能算“稍微慢一点”。我一般会在脚本里同时设置上行延迟、下行延迟和丢包模拟三类典型环境弱WiFi下行丢包1%、延迟150ms、3G网络延迟350ms、带宽降到1Mbps、极差网络丢包5%、延迟800ms、带宽压到200Kbps。具体做法是在OnBeforeRequest和OnBeforeResponse里加入延迟逻辑// Fiddler CustomRules.js 片段 // 通过URL关键词开关弱网环境比如包含weaknet3g就走3G参数 if (oSession.HostnameIs(api.example.com)) { if (oSession.isFlagSet(SessionFlags.RequestBodyBytesSent)) { // 模拟上行带宽限制每KB数据延迟10ms oSession[request-trickle-delay] 10; } }这里的参数逻辑是request-trickle-delay控制请求体的延迟模拟上传弱网响应侧在OnBeforeResponse里用oSession[response-trickle-delay] 300控制每KB下载数据的延迟模拟下行限速。这样调整后App的表现会明显出现加载转圈、图片分块加载、请求超时等现象这才是弱网测试的意义所在。执行弱网用例时要特别关注三件事一是请求超时后的重试策略二是弱网下数据一致性比如购物车加了商品却因为超时显示失败三是页面是否有对应的加载态与错误提示文案。4.2 Monkey稳定性测试通过标准不是“没报错”而是“还活着”Monkey是Android平台最粗暴也最高效的稳定性测试工具。很多人跑完Monkey看一眼没有crash就收工这是错误的。Monkey的通过标准应该分三层无Java异常、无ANR、进程仍然存活。进程存活这一点最容易被漏掉——有些Monkey跑崩时进程被杀但logcat里的异常堆栈被后续日志刷掉了导致误判为通过。# 以固定种子值执行保证可复现 adb shell monkey -p com.example.demo \ --throttle 300 \ -s 66666 \ --pct-touch 60 \ --pct-motion 20 \ --pct-syskeys 5 \ --ignore-crashes false \ --ignore-timeouts false \ 30000参数说明--throttle 300表示事件间隔300毫秒值过大会降低压力值、过小则容易让低端机直接触发系统级ANR但这不代表应用有问题-s 66666是随机种子固定它才能保证两次测试的路径一致从而复现同一个崩溃--pct-touch 60和--pct-motion 20把80%的事件集中在触摸与滑动上因为这两类事件最能暴露列表滑动、View复用与手势冲突问题。跑完后用下面命令确认进程是否还活着# 检查进程状态如果输出里没有任何信息说明应用已崩溃闪退 adb shell pidof com.example.demo # 抓取崩溃堆栈到本地文件 adb logcat -d *:E monkey_errors.txt4.3 存储空间与老化app内部存储写测试怎么设计移动APP测试中存储相关问题在旧版本升级场景里特别常见。应用内数据库升级失败、日志文件无限增长、缓存清理不彻底导致的“存储空间不足”都是高发问题。除了常规的在系统设置里查看App占用外可以在测试前快速“填满”空间模拟极端场景。做法是把设备内存塞到剩余空间500MB以下再执行App的下载、拍照、视频录制等写存储功能观察异常处理逻辑。# 生成一个大文件占用存储空间注意替换可写路径 adb shell dd if/dev/zero of/sdcard/fill_zero_1g bs1M count1024 # 测试完成后清除占位文件 adb shell rm /sdcard/fill_zero_1g这里的逻辑是存储即将写满时很多App首次写入会失败但不应该崩溃或丢失用户数据。测试时要重点观察应用是否有“空间不足”的明确提示、写入失败后的重试机制是否生效、以及回退后应用内已有数据是否完整。另一个容易忽略的坑是App自己的缓存目录/data/data/包名/cache不受用户手动清理控制有些应用在这里积累大量瞬时文件时间长了会反向挤占系统存储检查这类问题可以对比测试前后的dumpsys diskstats或者直接用文件管理器看cache目录大小是否呈线性增长。5. 把PDF里的“精编资料”改造成固定回归套件资料只有变成可执行的回归脚本才算真正落地。我的经验是把PDF里的Checklist切成两层第一层是冒烟清单只保留核心业务路径每次发版前跑一遍第二层是专项清单按功能模块拆开对应各自的测试脚本。先把清单转成Markdown表格每个用例一行对应一个自动化测试用例ID这样文档和脚本能一一对上。然后按此搭一个最精简的移动APP自动化回归骨架用Appium驱动哪怕是零基础也能照抄着改# mobile_regression.py from appium.webdriver.webdriver import WebDriver desired_caps { platformName: Android, deviceName: Android, appPackage: com.example.demo, appActivity: .MainActivity, } driver WebDriver(http://localhost:4723/wd/hub, desired_caps) # 核心路径登录→首页→进入详情页→返回 login_button driver.find_element(id, btn_login) login_button.click()这段代码的逻辑说三层一是platformName和deviceName指明必须跑在Android真机或模拟器上不能拿桌面浏览器顶替二是appPackage和appActivity必须与目标应用的AndroidManifest.xml里的启动Activity完全一致否则启动必失败三是定位方式用id优先因为xpath在版本迭代里极容易碎。跑通这条用例后把一个用例复制成五份分别替换为不同账号、不同列表数据量、不同系统语言环境就形成了最小回归集。整个回归集放在提交前的冒烟阶段跑比发版后拿用户填坑要便宜得多。把这个回归集和PDF里的清单放在同一目录文档每更新一版就跑一遍回归集去校验文档里的预期是否与代码行为一致——资料能保持更新脚本也有意义两个都不吃灰。本文还有配套的精品资源点击获取 
长河君 · 2026/9/20 1:34:23 · 阅读 1.2k 移动APP测试实战：从功能兼容到性能弱网，构建完整回归基线
简介面向移动APP测试方向的初学者和测试工程师这份精编资料以Android环境为核心系统整理了APP测试需要掌握的知识点。内容先介绍Genymotion模拟器和adb常用命令涵盖设备连接、apk安装卸载、包名查看、文件导入导出等高频操作随后梳理APP常见测试类型包括安装测试、卸载测试、功能测试、功能交互、通知栏测试、双卡双待测试并逐一介绍activity、service、broadcast receiver、content provider等Android四大组件在测试中的关注点再进一步涉及Fiddler抓包、JSON数据校验以及性能测试中的启动时间、切换时间、内存堆内存等关键指标帮助读者理解从环境准备到业务功能、性能验证的完整测试链路。资料为单个PDF文件大小约1020KB结构紧凑按主题分段便于离线阅读和目录检索。已有230人学习下载适合随身速查也可作为面试前快速回忆体系化知识的索引。1. 拿到“移动APP测试大全精编资料.pdf”后先别急着翻页一份以“大全精编”命名的移动APP测试文档价值从来不是因为它写得全而是因为它能帮你在一小时内列出一份不重不漏的测试基线。移动APP测试的麻烦在于维度太多功能、兼容、性能、弱网、存储、安全、自动化回归每一类都有独立工具链和判定口径新手容易被“功能test pass”带偏老手则容易在重复劳动里漏掉边缘场景。我拿到这类PDF时惯常做法是把它当成三层东西看第一层是知识索引告诉我哪些维度必须覆盖第二层是参数基线告诉我各维度用什么命令和阈值去判定第三层是可以直接改造成回归用例的检查清单。下面按这个思路把移动APP测试拆成能落地的执行路径每一步都给命令和参数不写空话。2. 从资料到用例移动APP测试的功能与兼容性分层2.1 先按测试金字塔给移动APP测试分层再决定人力往哪放移动APP测试最忌讳一上来就对着界面点。我拿到“大全精编”这类资料后第一步永远是先把测试范围压到金字塔结构里底层是单元与接口测试能自动化就自动化跑得最快中间层是业务逻辑与集成测试用真机或模拟器跑顶层是UI与端到端场景这部分人力最贵留给高频核心路径。一个容易忽视的事实是——移动APP测试里真正消耗资源的是顶层界面的碎片化回归而不是底层逻辑。因此在设计用例之前先按下表把维度、时机与负责人理清楚再写具体用例测试维度执行时机核心手段责任角色功能测试每个迭代冒烟、全量前用例设计手工/UI自动化测试工程师兼容性测试发版前、系统大版本更新后真机矩阵云真机抽样测试工程师性能测试版本稳定后、发布候选阶段adb/PerfDog等采集性能测试或开发弱网测试弱网场景相关的功能合入后Fiddler/Charles真实弱网测试工程师安全测试上线前专项、渗透演练静态扫描抓包渗透工具安全测试工程师稳定性测试合码后冒烟前、夜间回归Monkey/Appium长跑测试工程师分层完成后你会发现一个常见问题功能测试用例写得过细导致每次发版要回归一整天而兼容性测试却只靠两台模拟器草草收场。正确顺序是先定兼容性矩阵再倒推功能用例的优先级因为兼容性往往是返工成本最高的维度。2.2 用设备矩阵收敛兼容性测试成本而不是堆设备兼容性测试的经典误区是“越多越好”。实际上Android碎片化的核心变量是系统版本、屏幕分辨率、厂商ROM和内存档位这四个维度用正交表各取两到三个典型值就能覆盖八成以上线上问题。我常用的做法是维护一张设备矩阵表每行一台设备每列一个关键特征设备代号系统版本分辨率厂商ROM内存用途D1Android 131080p原生8GB主功能回归D2Android 10720p厂商A4GB低端机验证D3Android 142K厂商B12GB大屏适配D4iOS 最新全覆盖不涉及不涉及视觉与交互一致性矩阵里的D1负责主流程D2负责内存压力下的稳定性D3负责高分辨率下UI错位与字体缩放D4作为跨平台参照系。用这个矩阵把功能用例按“高、中、低”三个优先级打标只有高优先级用例需要在全部设备上跑中优先级跑D1与D2低优先级只在D1上跑。这样兼容性测试的时间可以从三天压到半天同时不会漏掉关键路径的系统版本差异。2.3 云真机与本地机群怎么选本地机群适合需要反复插拔U盘、调试蓝牙外设、读取OTG设备的场景而覆盖碎片化机型、快速在不同系统版本间切换时公有云真机平台更划算。云真机的优势不是设备多而是矩阵数据可复用——每次发版前可以按同一套矩阵脚本并行执行冒烟用例结果自动归档。不过在链路设计上要注意云真机的弱点是网络环境不可控任何涉及弱网、音视频实时传输的用例都不要放到云真机上跑否则结果不具备参考性。对这类用例保留两台本地真机用路由器限速或Fiddler延迟注入来做。3. 用 adb 命令把性能测试变成移动APP测试的固定动作3.1 冷启动耗时用 am start -W 拿到权威数据移动APP测试里的启动耗时以系统给我的数据为准而不是拿秒表测。adb shell am start -W会直接输出启动过程中的关键时间点是Android平台上最基础也最被低估的性能测试命令。# 先强制停止目标应用保证冷启动环境干净 adb shell am force-stop com.example.demo # 启动并等待Activity完全绘制完成 adb shell am start -W com.example.demo/.MainActivity输出里有三个关键字段ThisTime表示最后一个Activity启动耗时TotalTime表示启动过程中所有Activity的总耗时WaitTime包含系统进程调度等额外等待。判定基线通常看首次冷启动TotalTime——中低端机型不超过2秒高端机型控制在1秒以内复测三次取中位数避免单次偶发波动造成误判。注意am force-stop只杀进程不清理缓存如果需要模拟“安装后首次启动”的极限条件还要追加清缓存命令。# 清除应用全部数据模拟首次安装后的启动环境 adb shell pm clear com.example.demo3.2 帧率与卡顿读 dumpsys gfxinfo 的 janky 行手游和短视频应用最关心的流畅度指标在Android上可以通过gfxinfo拿到逐帧数据。这个命令对移动APP测试的意义在于它能给出卡顿发生的精确时刻而不是只报一个平均帧率。平均帧率会掩盖掉周期性掉帧的问题——只要有一两秒的顿挫平均帧率看起来还是接近60但实际上用户已经感知到卡了。# 重置帧率统计信息保证从当前时刻开始采集 adb shell dumpsys gfxinfo com.example.demo reset # 让应用执行3-5分钟核心场景操作然后再执行下面命令读取统计结果 adb shell dumpsys gfxinfo com.example.demo在输出内容里需要重点关注Janky frames的总数与比例以及50th percentile、90th percentile、95th percentile这些帧耗时百分位。判定基线是这样中端机在滚动列表场景下Janky frames占比不超过10%90%帧耗时控制在16毫秒以内只允许偶尔超过这个值。如果95%分位帧耗时超过32毫秒说明存在肉眼可见的卡顿需要结合HWC和SurfaceView信息进一步定位。3.3 CPU、内存、流量与功耗四个命令各管一边移动APP测试里性能问题很少只出现在单一维度上。CPU飙高往往伴随内存抖动流量的异常浪涌又可能拖垮整个应用的响应速度。把这四个维度做成固定采集模板比临时查命令更靠谱。# 抓取应用进程CPU占用率采样5次间隔2秒 adb shell top -n 5 -d 2 | grep com.example.demo # 读取Java堆与Native堆使用情况 adb shell dumpsys meminfo com.example.demo # 抓取各UID的流量统计重点看应用启动、刷新、后台三段的差值 adb shell cat /proc/net/dev # 更精确的做法是读取应用UID对应的/proc/uid_stat/目录 adb shell cat /proc/uid_stat/uid/tcp_rcv adb shell cat /proc/uid_stat/uid/tcp_snd功耗测试分两条路径精细路径用dumpsys batterystats采集各应用耗电占比与唤醒锁持有时间快速路径直接在真机上把屏幕亮度固定为50%后台静置8小时对比前后电量差。无论哪条路径都要保证测试过程中没有其他应用在后台下载或同步数据否则功耗数据完全不可信。采集这些数据时我一般会在同一台设备上连续跑三轮取中位数报告避免单次结果受系统后台Job的影响。这里踩过的一个典型坑是拿开发机的模拟器性能数据当Android真机的性能基线两者完全是两个量级没有可比性。4. 弱网、存储与稳定性移动APP测试里最容易漏的三个场景4.1 用 Fiddler 模拟弱网参数调到真弱而不是假弱移动APP对弱网的反应是很多线上故障的源头。常见做法是用Fiddler的CustomRules.js做延迟注入但很多人把参数调得太温和——延迟50毫秒根本算不上弱网只能算“稍微慢一点”。我一般会在脚本里同时设置上行延迟、下行延迟和丢包模拟三类典型环境弱WiFi下行丢包1%、延迟150ms、3G网络延迟350ms、带宽降到1Mbps、极差网络丢包5%、延迟800ms、带宽压到200Kbps。具体做法是在OnBeforeRequest和OnBeforeResponse里加入延迟逻辑// Fiddler CustomRules.js 片段 // 通过URL关键词开关弱网环境比如包含weaknet3g就走3G参数 if (oSession.HostnameIs(api.example.com)) { if (oSession.isFlagSet(SessionFlags.RequestBodyBytesSent)) { // 模拟上行带宽限制每KB数据延迟10ms oSession[request-trickle-delay] 10; } }这里的参数逻辑是request-trickle-delay控制请求体的延迟模拟上传弱网响应侧在OnBeforeResponse里用oSession[response-trickle-delay] 300控制每KB下载数据的延迟模拟下行限速。这样调整后App的表现会明显出现加载转圈、图片分块加载、请求超时等现象这才是弱网测试的意义所在。执行弱网用例时要特别关注三件事一是请求超时后的重试策略二是弱网下数据一致性比如购物车加了商品却因为超时显示失败三是页面是否有对应的加载态与错误提示文案。4.2 Monkey稳定性测试通过标准不是“没报错”而是“还活着”Monkey是Android平台最粗暴也最高效的稳定性测试工具。很多人跑完Monkey看一眼没有crash就收工这是错误的。Monkey的通过标准应该分三层无Java异常、无ANR、进程仍然存活。进程存活这一点最容易被漏掉——有些Monkey跑崩时进程被杀但logcat里的异常堆栈被后续日志刷掉了导致误判为通过。# 以固定种子值执行保证可复现 adb shell monkey -p com.example.demo \ --throttle 300 \ -s 66666 \ --pct-touch 60 \ --pct-motion 20 \ --pct-syskeys 5 \ --ignore-crashes false \ --ignore-timeouts false \ 30000参数说明--throttle 300表示事件间隔300毫秒值过大会降低压力值、过小则容易让低端机直接触发系统级ANR但这不代表应用有问题-s 66666是随机种子固定它才能保证两次测试的路径一致从而复现同一个崩溃--pct-touch 60和--pct-motion 20把80%的事件集中在触摸与滑动上因为这两类事件最能暴露列表滑动、View复用与手势冲突问题。跑完后用下面命令确认进程是否还活着# 检查进程状态如果输出里没有任何信息说明应用已崩溃闪退 adb shell pidof com.example.demo # 抓取崩溃堆栈到本地文件 adb logcat -d *:E monkey_errors.txt4.3 存储空间与老化app内部存储写测试怎么设计移动APP测试中存储相关问题在旧版本升级场景里特别常见。应用内数据库升级失败、日志文件无限增长、缓存清理不彻底导致的“存储空间不足”都是高发问题。除了常规的在系统设置里查看App占用外可以在测试前快速“填满”空间模拟极端场景。做法是把设备内存塞到剩余空间500MB以下再执行App的下载、拍照、视频录制等写存储功能观察异常处理逻辑。# 生成一个大文件占用存储空间注意替换可写路径 adb shell dd if/dev/zero of/sdcard/fill_zero_1g bs1M count1024 # 测试完成后清除占位文件 adb shell rm /sdcard/fill_zero_1g这里的逻辑是存储即将写满时很多App首次写入会失败但不应该崩溃或丢失用户数据。测试时要重点观察应用是否有“空间不足”的明确提示、写入失败后的重试机制是否生效、以及回退后应用内已有数据是否完整。另一个容易忽略的坑是App自己的缓存目录/data/data/包名/cache不受用户手动清理控制有些应用在这里积累大量瞬时文件时间长了会反向挤占系统存储检查这类问题可以对比测试前后的dumpsys diskstats或者直接用文件管理器看cache目录大小是否呈线性增长。5. 把PDF里的“精编资料”改造成固定回归套件资料只有变成可执行的回归脚本才算真正落地。我的经验是把PDF里的Checklist切成两层第一层是冒烟清单只保留核心业务路径每次发版前跑一遍第二层是专项清单按功能模块拆开对应各自的测试脚本。先把清单转成Markdown表格每个用例一行对应一个自动化测试用例ID这样文档和脚本能一一对上。然后按此搭一个最精简的移动APP自动化回归骨架用Appium驱动哪怕是零基础也能照抄着改# mobile_regression.py from appium.webdriver.webdriver import WebDriver desired_caps { platformName: Android, deviceName: Android, appPackage: com.example.demo, appActivity: .MainActivity, } driver WebDriver(http://localhost:4723/wd/hub, desired_caps) # 核心路径登录→首页→进入详情页→返回 login_button driver.find_element(id, btn_login) login_button.click()这段代码的逻辑说三层一是platformName和deviceName指明必须跑在Android真机或模拟器上不能拿桌面浏览器顶替二是appPackage和appActivity必须与目标应用的AndroidManifest.xml里的启动Activity完全一致否则启动必失败三是定位方式用id优先因为xpath在版本迭代里极容易碎。跑通这条用例后把一个用例复制成五份分别替换为不同账号、不同列表数据量、不同系统语言环境就形成了最小回归集。整个回归集放在提交前的冒烟阶段跑比发版后拿用户填坑要便宜得多。把这个回归集和PDF里的清单放在同一目录文档每更新一版就跑一遍回归集去校验文档里的预期是否与代码行为一致——资料能保持更新脚本也有意义两个都不吃灰。本文还有配套的精品资源点击获取