一.常用的abd命令有哪些
1.什么是 ADB?
通俗解释:
ADB 就像一个桥梁,让电脑能控制连接的手机,比如安装APP、抓日志、重启设备等。
专业术语总结:
ADB(Android Debug Bridge)是 Android SDK 提供的命令行工具,允许开发者通过 USB 或网络方式与 Android 设备交互,执行调试、安装、日志查看等操作。
2.常用 ADB 命令(通俗讲解 + 专业术语)
编号 | 命令 | 通俗解释 | 面试术语总结 |
---|---|---|---|
1 | adb devices | 查看连接到电脑的手机 | 查看当前已连接并授权调试的设备列表 |
2 | adb install xxx.apk | 把 APK 装到手机上 | 向设备推送并安装指定 APK 应用 |
3 | adb uninstall 包名 | 卸载 APP | 从设备中卸载指定包名的应用 |
4 | adb shell | 进入手机命令行模式 | 启动与设备交互的 Linux shell 环境 |
5 | adb logcat | 看手机日志 | 实时输出系统或应用日志信息 |
6 | adb pull /sdcard/xxx.txt | 把手机文件拷到电脑 | 从设备复制文件到本地电脑 |
7 | adb push local.txt /sdcard/ | 把电脑文件拷到手机 | 从本地电脑复制文件到设备 |
8 | adb reboot | 让手机重启 | 重启设备 |
9 | adb reboot recovery | 进 recovery 模式 | 重启设备并进入恢复模式 |
10 | adb logcat > log.txt | 把日志保存到文件 | 将日志输出保存到本地文件,便于分析 |
11 | adb shell pm list packages | 查看手机装了哪些包 | 列出设备中安装的所有应用包名 |
12 | adb shell am start -n 包名/类名 | 启动一个 App 页面 | 通过 ActivityManager 启动指定组件 |
13 | adb shell input tap x y | 模拟点击屏幕 | 通过坐标模拟用户点击事件 |
14 | adb shell input text "hello" | 输入文本 | 模拟用户输入字符 |
15 | adb shell screencap /sdcard/screen.png | 手机截图 | 在设备端截图并保存到指定路径 |
16 | adb shell screenrecord /sdcard/demo.mp4 | 录制屏幕 | 在设备端录制屏幕内容为视频 |
17 | adb shell dumpsys | 获取系统信息(超详细) | 调用系统服务获取当前状态、配置、性能等信息(常用于ANR、内存分析) |
18 | adb bugreport | 导出完整 bug 报告 | 收集系统诊断信息,生成 bugreport.zip,常用于故障复现分析 |
二.用过monkey吗?用monkey来做什么?发现过什么问题
1.通俗解释
Monkey 是 Android 自带的一个小工具,它可以“像个调皮的小猴子一样”,随机地点击屏幕、滑动、输入等,模拟用户的乱操作,来看看 App 会不会崩溃或卡住。
我们常常用它来做稳定性测试(就像你不停地狂点 APP,看它会不会出问题)。
Monkey 是用来测试 APP 在“被乱点”的时候会不会崩溃、ANR(无响应)或者卡住。就像你把手机交给小孩子乱玩,看 APP 会不会挂掉。
比如:我设置 Monkey 连续点 1 万次,如果在这过程中 APP 崩了、卡了,那就说明代码还有 bug。
2.monkey来做什么
Monkey 是 Android SDK 自带的命令行工具,可用于对应用进行随机事件压力测试,通过模拟用户点击、滑动、旋转、按键等操作,验证应用在高压环境下的稳定性与健壮性。Monkey 常用于:
稳定性回归测试
发现 ANR(Application Not Responding)
崩溃(Crash)
看门狗错误(Watchdog)
内存泄漏相关的问题
3. 用 Monkey 发现过哪些问题
以前跑 Monkey,APP 被乱点几千次之后就崩了,后来发现是某个页面的按钮点太快会导致空指针异常。
还发现过页面卡死,点来点去卡在 loading 页面一直转圈,发现是网络请求超时没做兜底。
4.面试总结
用过 Monkey 工具,它是 Android 自带的随机事件测试工具,主要用于稳定性测试。我曾用它对项目进行过 10,000 次事件压力测试,发现过由于按钮快速重复点击导致的空指针崩溃,也遇到过因网络请求未限流导致界面卡死的问题。通过 logcat 和 crash 报告进行分析后修复,增强了 APP 的稳定性。
三.APP崩溃/闪退,一般是什么原因造成的?
“APP 崩溃或闪退的常见原因主要包括以下几类:
空指针引用(NullPointerException):未初始化对象即调用方法。
数组越界或集合下标异常(IndexOutOfBoundsException)。
主线程阻塞:如网络请求或 I/O 操作未异步处理,导致 ANR 或 watchdog 杀死进程。
内存溢出(OOM):例如加载大图、频繁创建对象未释放。
权限缺失:如未申请相机、定位权限直接调用 API,系统拦截后崩溃。
系统兼容性问题:Android/iOS 系统升级导致某些 API 或行为变化。
第三方 SDK 异常:集成不当或版本不兼容引发崩溃。
并发访问异常:如多线程同时访问同一资源未加锁,出现 race condition。
遇到这类问题,我会第一时间查看 logcat
(Android)或 Xcode控制台日志
(iOS)获取异常堆栈,然后结合崩溃监控工具如 Firebase Crashlytics、Bugly 等分析定位并复现问题。”
四.ISO系统和Andriod系统的区别
对比维度 | iOS(苹果) | Android(安卓) |
---|---|---|
是谁的系统? | 苹果自家的,只给 iPhone/iPad 用 | Google 开发的,手机厂商都能用 |
开源吗? | 不开源(只有 Apple 自己能改) | 开源,谁都可以拿去改(MIUI、华为鸿蒙其实都是 Android 魔改) |
界面统一吗? | 非常统一,几乎每台 iPhone 用起来都差不多 | 很碎片化,不同厂商界面差很多(小米、三星、华为各不一样) |
App 安装方式? | 只能从 App Store 装,限制严 | 可以用第三方市场,甚至直接安装 APK |
安全性高吗? | 高,权限限制多,审核严格 | 相对低,有风险 APP 更容易安装进系统 |
通知栏/后台机制? | 管控非常严格,省电但限制多 | 灵活,但后台容易耗电、掉消息 |
用户量? | 高端用户多、付费能力强 | 用户基数大,覆盖广 |
适配难度? | 少数几个设备,适配容易 | 屏幕尺寸五花八门,适配很难 |
总结:iOS 是封闭、安全、统一的苹果自研系统,而 Android 是开源、灵活、适配复杂的谷歌系统。
五.怎么测试APP的兼容性
APP 兼容性测试是指在不同软硬件环境下验证应用是否能正确安装、运行、显示和交互,确保功能一致性与稳定性。
方法 | 简述 |
---|---|
真机测试 | 在多品牌多型号手机上逐一测试,稳定性高,成本大 |
云真机测试 | 如阿里云测、百度 MTC、腾讯 WeTest 等云平台远程调试 |
模拟器测试(辅助) | Android Studio / Xcode 模拟器模拟不同设备,效率高但不稳定 |
自动化测试结合 | 使用 Appium + 多设备运行,提高覆盖效率 |
总结:APP 兼容性测试主要是通过在不同品牌、不同系统版本、不同分辨率和网络环境下验证应用的功能、UI 和性能是否一致,常用真机测试、云测平台与自动化测试相结合,确保广泛用户的使用体验稳定可靠。
六.APP的性能测试如何做?
APP 性能测试是指评估移动应用在不同负载、操作或环境下的运行效率、响应速度、资源消耗和稳定性,确保其在实际使用中具备良好用户体验。
1.通俗易懂地解释
性能测试就是看 APP 有没有卡顿、耗不耗电、用不用太多内存、网络快不快。
举几个例子你就明白了:
你打开 APP 是不是很慢?👉 就要测“启动耗时”
滑动页面会不会卡?👉 就要测“帧率”
用久了手机发热严重?👉 就要测“CPU 和电量”
看视频会不会卡顿?👉 就要测“网络延迟”
用得时间长 APP 会不会越来越卡?👉 就要测“内存占用”
测试时可以通过真机 + 工具来一起测,比如 Android 可以用 adb
、systrace
、perfetto
,iOS 可以用 Instruments。
2.常见性能测试维度
测试维度 | 说明 |
---|---|
启动时间 | 冷启动、热启动时间是否满足业务要求(<3s) |
CPU 使用率 | 高负载是否造成手机发热、卡顿 |
内存使用(RAM) | 是否存在内存泄漏、频繁 GC 等问题 |
帧率(FPS) | 页面滑动或动画是否流畅(安卓应 ≥60fps) |
电量消耗 | 后台/前台运行是否耗电异常 |
网络性能 | 请求延迟、丢包率、上传/下载速度等 |
磁盘读写 | 是否频繁或大量读写导致系统卡顿 |
Crash/ANR 概率 | 高并发/高操作是否导致崩溃或无响应 |
3.测试方法
方法 | 举例 |
---|---|
手动测试 + 真机监控 | 使用开发者工具查看内存、CPU、帧率等 |
借助工具监控 | Android 使用 adb、systrace、Android Profiler;iOS 使用 Instruments |
自动化采集指标 | 使用 PerfDog、GT(腾讯)、Firebase、Bugly 性能面板 |
持续集成集成测试 | 将性能测试接入 CI 流水线做持续监控 |
压测/弱网测试 | 模拟极端场景下的性能表现(弱网、低电量、多任务等) |
4.总结
APP 的性能测试主要包括启动时间、CPU/内存占用、帧率、耗电、网络请求等维度,我通常通过真机测试结合工具(如 Android Profiler、Instruments、PerfDog 等)监控关键指标,结合自动化或持续集成,发现卡顿、耗电或内存泄漏等问题,从而优化用户体验。
七.手机APP更新测试,说一下测试点
APP 更新测试,就是在用户已经装了旧版本的情况下,我们发了一个新版本,用户从应用市场、弹窗提示、自动下载等方式更新了之后:
你要验证的核心是:
更新完能不能用?数据会不会丢?界面会不会错?功能有没有崩?兼容有没有问题?
总结:APP 更新测试主要包含 5 个方面:更新流程验证、数据保留、功能回归、界面显示、特殊场景兼容性。我通常会覆盖手动更新、市场更新、强制/非强制升级场景,同时重点验证更新后用户数据迁移是否正常、功能是否稳定,以及弱网/中断/空间不足等边界情况,确保升级过程稳定可靠。
八.如何模型弱网测试
弱网测试就是模拟手机在网络不好的情况下(比如地铁、山区、信号差的地下车库)使用 APP,观察它有没有:
页面加载超时?
网络断了有没有提示?
上传/下载失败了会不会重试?
弹窗卡住?转圈圈不消失?
所以我们要人为“制造”这些糟糕的网络,比如:
变慢(比如速度只有 50kb/s)
丢包(有一半数据发不出去)
延迟高(点按钮后3秒才响应)
断连、频繁切换网络
APP弱网测试是通过工具或脚本模拟网络延迟、丢包、限速、断网等环境,验证应用在异常网络下的稳定性、加载表现和容错能力。
1.如何模拟弱网环境
1. 使用系统自带模拟工具(推荐)
✅ Android 设备:
开发者选项 > 网络限制
可选择:无网络
仅限 2G、3G、4G
模拟高延迟(Android 11+)
✅ iOS 设备(需 Mac):
使用 Mac 上的 Network Link Conditioner(网络链路调节器)
选项如:Edge、3G、High Latency DNS、Very Bad Network 等
安装路径:Xcode > Additional Tools
2. 使用专业弱网模拟工具(功能最强)
工具名称 | 平台 | 功能简介 |
---|---|---|
Charles | Win/Mac | 抓包 + 弱网模拟(限速、丢包、断连) |
Network Link Conditioner | Mac / iOS | 苹果官方网络模拟器(延迟、丢包、带宽) |
Clumsy | Windows | 模拟丢包、延迟、限速等 |
NetEm(Linux) | Linux | 命令行模拟网络质量,非常灵活 |
腾讯 GT / PerfDog | Android | 性能 + 网络模拟一体工具 |
3. 使用真机切换网络测试
方法 | 描述 |
---|---|
物理切换网络 | 手动切换 WiFi ↔ 4G ↔ 飞行模式 |
信号屏蔽 | 使用屏蔽盒、地下室、地铁等物理弱网环境 |
热点共享限速 | 用路由器/AP 控制热点限速(限上传/下载) |
4. 自动化 + 弱网脚本结合
可以通过脚本在测试中动态切换网络、限速、模拟断连,例如:
adb shell "svc data disable" # 模拟断网 adb shell "svc data enable" # 恢复联网
2.测试重点场景建议:
场景 | 建议关注 |
---|---|
首次打开 APP | 启动慢、接口失败是否兜底 |
图片/视频加载 | 是否有加载占位图、加载失败提示 |
表单提交 | 网络断掉后是否重试/提示用户 |
登录注册 | 异常网络下是否提示明确错误 |
上传文件 | 是否支持断点续传、失败后提示 |
IM/消息类 | 消息是否延迟/丢失/乱序 |
网络切换 | WiFi ↔ 4G 是否会断流、卡住、重连失败 |
九.针对App的安装功能,写出测试点
1.App 安装功能测试点(分类整理)
① 安装流程测试
测试点 | 说明 |
---|---|
正常安装是否成功 | 在常见设备上下载安装是否顺利 |
是否弹出权限/授权提示 | 如安装来源、安全提醒是否正常出现 |
应用图标是否显示在桌面 | 安装完成后是否能在主屏找到 APP 图标 |
安装后是否能正常启动 | 安装完成后点击是否能打开主页 |
安装包签名一致性 | 升级/重装时签名是否一致,防止安装失败 |
安装路径是否正确 | 检查是否默认安装到系统路径(特别是支持 SD 卡时) |
② 安装异常场景测试
测试点 | 说明 |
---|---|
空间不足是否提示 | 安装过程中手机空间不足是否提示清晰,是否失败后恢复正常 |
安装中断后是否能恢复 | 安装一半断电、拔数据线,重新安装是否正常 |
多次点击安装是否冲突 | 连续点击多次安装包是否导致异常 |
多版本覆盖安装是否兼容 | 从旧版本到新版本安装,或降级安装是否提示/阻止 |
非官方渠道安装是否受限 | 非市场 APK 是否可安装、是否弹出风险提示 |
③ 系统版本与兼容性测试
测试点 | 说明 |
---|---|
不同 Android/iOS 系统安装是否正常 | Android 814 / iOS 1317 是否均可安装 |
不同 ROM(MIUI/EMUI/ColorOS)适配 | 是否因系统安全策略被限制安装 |
是否支持快速安装 | 如 Android 使用 split APK、iOS 是否支持 TestFlight |
④ 安装后行为验
测试点 | 说明 |
---|---|
安装后是否自动启动 | 是否在某些厂商系统下自动拉起(需判断是否合规) |
是否能被桌面搜索到 | 安装完成后桌面是否能正确检索 |
是否能正常卸载 | 卸载是否彻底,是否残留数据或图标 |
2.面试总结术语
针对 App 的安装功能,我会从安装流程、异常场景、系统兼容性和安装后行为四方面进行测试,包括正常安装、签名验证、空间不足、覆盖安装、系统适配等,确保用户在各种条件下都能顺利、安全地完成安装并正常使用 App。
十.做兼容性测试时,如何选择机型
在兼容性测试中,我会结合市场占有率、操作系统版本、分辨率、性能层级和厂商定制系统等五个维度,选取具有代表性的机型进行覆盖测试,确保功能和显示在主流与边缘用户场景下都能稳定运行。
十一.测过APP的push推送吗,需要考虑哪些点
Push(消息推送)就是让 APP 在没打开的情况下也能收到消息,比如:
微信来消息了、
支付宝到账提醒、
淘宝双11给你发促销通知
测试的时候要关注的核心点就是:
消息推得过来吗?推得准吗?推的时候 APP 是不是在前台/后台/被杀死都能正常弹出?点了推送能不能跳到指定页面?
总结:我测试过 APP 的 Push 推送功能,主要从 通道配置、多场景状态(前台/后台/杀进程)、通知内容展示、跳转逻辑、用户设置控制、消息频率与多设备同步 等维度进行覆盖测试,确保推送消息在各类设备和系统状态下都能准确送达、合理展示并跳转无误。还结合了 厂商推送统计平台(如极光后台)与客户端日志(推送 token、收达时间) 做推送链路的验证,确保消息从服务端发出到客户端展示全链路可控。
十二.APP冷启动和热启动的区别
我们拿“打开 APP”来打比方:
类型 | 通俗理解 |
---|---|
❄️ 冷启动(Cold Start) | 第一次打开 APP,或者 APP 完全被关闭了,重新启动,相当于“从头开始启动” |
🔥 热启动(Hot Start) | APP 只是“退到后台”,你再切回来,就像是“把它从后台唤醒” |
举个例子:
你刚开机,点微信 → 冷启动
微信退到后台没关 → 你再点回来 → 热启动
你把微信从后台滑掉(彻底杀死)再点开 → 冷启动
对比项 | 冷启动(Cold Start) | 热启动(Hot Start) |
---|---|---|
启动时机 | 应用未运行或进程被杀死 | 应用仍在后台,未被系统杀死 |
系统行为 | 创建新进程、初始化 Application、Activity 生命周期全走一遍 | 直接从后台恢复,Activity 可能只走 onRestart/onResume |
加载时间 | 启动慢,耗时长(初始化多) | 启动快,几乎秒开 |
用户体验 | 黑屏/白屏阶段明显,启动动画完整显示 | 恢复速度快,直接进入上次状态 |
性能优化点 | Application 初始化、首帧渲染优化 | 恢复现场、后台保活等策略 |
常见触发方式 | 开机后首次打开 / 手动结束进程后 | 切后台再切回前台 |
总结:冷启动是指应用完全未运行时的首次启动,需要重新创建进程并初始化所有组件;热启动则是应用处于后台时重新进入前台,系统保留进程状态,启动更快。两者在生命周期触发、启动耗时和用户体验上有明显差异。
十三.有做过H5的测试吗
H5 就是嵌在 App 或浏览器中的“网页页面”,比如:
公众号打开的活动页
App 内的“会员中心”“登录页”(是个 WebView 页面)
微信小程序中打开的 web 页面
浏览器访问的网页
你做 H5 测试的时候,其实就要测:
页面在不同手机上加载快不快?排版乱不乱?能不能正常跳转?按钮好不好点?前后端数据是否一致?微信打开有没有问题?
十四.APP的某个功能失效了,如何排查是客户端还是服务端的问题
1.通俗易懂地解释:怎么判断问题到底出在客户端还是服务端?
你可以把客户端想成“手机App”,服务端想成“后台处理中心”。
比如你在 App 点了“提交订单”没反应,那你就要分析到底是:
手机 App 自己没发请求?(客户端问题)
请求发出去了,后台没响应或者报错?(服务端问题)
2.常用排查逻辑如下:
📍 第一步:看 App 有没有“报错提示”
❌ 什么都没弹?→ 客户端可能根本没发请求
⏳ 一直转圈?→ 有可能是等服务端没回应
📍 第二步:抓日志(logcat 或 Charles/Fiddler)
看有没有发送 HTTP 请求?请求成功了吗?状态码是多少?
状态码 200 → 说明服务端响应了,看返回数据对不对
状态码 5xx / 4xx → 多半是服务端异常(比如接口报错、鉴权失败)
根本没请求 → 多半是客户端逻辑问题(前端条件判断失败、按钮没响应)
📍 第三步:换网络/换手机/重新登录试试
如果换手机后功能正常,那很可能是客户端缓存问题或兼容问题
如果所有手机都不行,那可能是服务端宕机或接口变更
📍 第四步:对照接口文档、Postman 手动调接口
直接用 Postman 发同样的请求试试看服务端返回什么
如果 Postman 正常返回,那就是客户端请求方式有问题
如果 Postman 也失败,那就是服务端接口有问题
📍 第五步:问一下开发/联调日志
查看后端日志、API 网关日志,看请求有没有打到后端,有没有异常栈
3.面试术语总结
“遇到 APP 某个功能失效时,我通常会从客户端与服务端两方面排查:
① 首先查看客户端日志,确认是否发起了请求、状态码、返回内容等;
② 再抓包(如使用 Charles、Fiddler、Wireshark 等)验证是否正常请求并收到响应;
③ 同时用 Postman 等工具复现接口调用,验证服务端逻辑是否正常;
④ 如服务端返回正常,再定位客户端处理逻辑是否异常,如数据解析失败、UI未更新等;
⑤ 若接口也异常,则配合后端查看日志判断是否接口改动、部署失败或参数错误。”
举列子:之前我们遇到一个‘订单无法提交’的问题,初步以为是服务端故障。但通过 Charles 抓包发现,客户端并没有发出接口请求,最终定位是客户端逻辑判断失败未触发提交事件,修复条件判断后恢复正常。
十五.工作中都用到什么抓包工具的什么功能,分别在什么场景下使用的
“工作中常用的抓包工具主要包括 Charles、Fiddler 和 Wireshark。
其中 Charles 是使用最频繁的,主要用于抓取 App 的 HTTP/HTTPS 请求,调试请求参数、响应数据;结合 Rewrite 和 Map Local 功能,我们可以模拟服务端返回不同场景,便于客户端功能验证和异常处理测试;
在弱网场景测试中,我们会使用 Charles 的 Throttle 功能模拟带宽延迟;
而 Wireshark 多用于底层网络问题排查,比如分析音视频传输、DNS 解析失败等。
对于自动化场景,我们也使用过 Mitmproxy 结合脚本分析请求是否达标。”