一.常用的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 结合脚本分析请求是否达标。”
))
