岳阳网站推广,WordPress 秒开,设计经典网站,服装网站建设环境分析一.常用的abd命令有哪些1.什么是 ADB#xff1f;通俗解释#xff1a;
ADB 就像一个桥梁#xff0c;让电脑能控制连接的手机#xff0c;比如安装APP、抓日志、重启设备等。专业术语总结#xff1a;
ADB#xff08;Android Debug Bridge#xff09;是 Android SDK 提供的命…一.常用的abd命令有哪些1.什么是 ADB通俗解释
ADB 就像一个桥梁让电脑能控制连接的手机比如安装APP、抓日志、重启设备等。专业术语总结
ADBAndroid Debug Bridge是 Android SDK 提供的命令行工具允许开发者通过 USB 或网络方式与 Android 设备交互执行调试、安装、日志查看等操作。2.常用 ADB 命令通俗讲解 专业术语编号命令通俗解释面试术语总结1adb devices查看连接到电脑的手机查看当前已连接并授权调试的设备列表2adb install xxx.apk把 APK 装到手机上向设备推送并安装指定 APK 应用3adb uninstall 包名卸载 APP从设备中卸载指定包名的应用4adb shell进入手机命令行模式启动与设备交互的 Linux shell 环境5adb logcat看手机日志实时输出系统或应用日志信息6adb pull /sdcard/xxx.txt把手机文件拷到电脑从设备复制文件到本地电脑7adb push local.txt /sdcard/把电脑文件拷到手机从本地电脑复制文件到设备8adb reboot让手机重启重启设备9adb reboot recovery进 recovery 模式重启设备并进入恢复模式10adb logcat log.txt把日志保存到文件将日志输出保存到本地文件便于分析11adb shell pm list packages查看手机装了哪些包列出设备中安装的所有应用包名12adb shell am start -n 包名/类名启动一个 App 页面通过 ActivityManager 启动指定组件13adb shell input tap x y模拟点击屏幕通过坐标模拟用户点击事件14adb shell input text hello输入文本模拟用户输入字符15adb shell screencap /sdcard/screen.png手机截图在设备端截图并保存到指定路径16adb shell screenrecord /sdcard/demo.mp4录制屏幕在设备端录制屏幕内容为视频17adb shell dumpsys获取系统信息超详细调用系统服务获取当前状态、配置、性能等信息常用于ANR、内存分析18adb 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 常用于稳定性回归测试发现 ANRApplication Not Responding崩溃Crash看门狗错误Watchdog内存泄漏相关的问题3. 用 Monkey 发现过哪些问题以前跑 MonkeyAPP 被乱点几千次之后就崩了后来发现是某个页面的按钮点太快会导致空指针异常。还发现过页面卡死点来点去卡在 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。遇到这类问题我会第一时间查看 logcatAndroid或 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、perfettoiOS 可以用 Instruments。2.常见性能测试维度测试维度说明启动时间冷启动、热启动时间是否满足业务要求3sCPU 使用率高负载是否造成手机发热、卡顿内存使用RAM是否存在内存泄漏、频繁 GC 等问题帧率FPS页面滑动或动画是否流畅安卓应 ≥60fps电量消耗后台/前台运行是否耗电异常网络性能请求延迟、丢包率、上传/下载速度等磁盘读写是否频繁或大量读写导致系统卡顿Crash/ANR 概率高并发/高操作是否导致崩溃或无响应3.测试方法 方法举例手动测试 真机监控使用开发者工具查看内存、CPU、帧率等借助工具监控Android 使用 adb、systrace、Android ProfileriOS 使用 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. 使用专业弱网模拟工具功能最强工具名称平台功能简介CharlesWin/Mac抓包 弱网模拟限速、丢包、断连Network Link ConditionerMac / iOS苹果官方网络模拟器延迟、丢包、带宽ClumsyWindows模拟丢包、延迟、限速等NetEmLinuxLinux命令行模拟网络质量非常灵活腾讯 GT / PerfDogAndroid性能 网络模拟一体工具
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 是否均可安装不同 ROMMIUI/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 StartAPP 只是“退到后台”你再切回来就像是“把它从后台唤醒” 举个例子你刚开机点微信 → 冷启动微信退到后台没关 → 你再点回来 → 热启动你把微信从后台滑掉彻底杀死再点开 → 冷启动对比项冷启动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 结合脚本分析请求是否达标。”
