当前位置: 首页 > news >正文

学习软件测试的第十四天(移动端)

一.常用的abd命令有哪些

1.什么是 ADB?

通俗解释:
ADB 就像一个桥梁,让电脑能控制连接的手机,比如安装APP、抓日志、重启设备等。

专业术语总结:
ADB(Android 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 常用于:

  • 稳定性回归测试

  • 发现 ANR(Application Not Responding)

  • 崩溃(Crash)

  • 看门狗错误(Watchdog)

  • 内存泄漏相关的问题

3. 用 Monkey 发现过哪些问题

以前跑 Monkey,APP 被乱点几千次之后就崩了,后来发现是某个页面的按钮点太快会导致空指针异常。

还发现过页面卡死,点来点去卡在 loading 页面一直转圈,发现是网络请求超时没做兜底。

 4.面试总结

用过 Monkey 工具,它是 Android 自带的随机事件测试工具,主要用于稳定性测试。我曾用它对项目进行过 10,000 次事件压力测试,发现过由于按钮快速重复点击导致的空指针崩溃,也遇到过因网络请求未限流导致界面卡死的问题。通过 logcat 和 crash 报告进行分析后修复,增强了 APP 的稳定性。

三.APP崩溃/闪退,一般是什么原因造成的?

“APP 崩溃或闪退的常见原因主要包括以下几类:

  1. 空指针引用(NullPointerException):未初始化对象即调用方法。

  2. 数组越界或集合下标异常(IndexOutOfBoundsException)

  3. 主线程阻塞:如网络请求或 I/O 操作未异步处理,导致 ANR 或 watchdog 杀死进程。

  4. 内存溢出(OOM):例如加载大图、频繁创建对象未释放。

  5. 权限缺失:如未申请相机、定位权限直接调用 API,系统拦截后崩溃。

  6. 系统兼容性问题:Android/iOS 系统升级导致某些 API 或行为变化。

  7. 第三方 SDK 异常:集成不当或版本不兼容引发崩溃。

  8. 并发访问异常:如多线程同时访问同一资源未加锁,出现 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 可以用 adbsystraceperfetto,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. 使用专业弱网模拟工具(功能最强)

工具名称平台功能简介
CharlesWin/Mac抓包 + 弱网模拟(限速、丢包、断连)
Network Link ConditionerMac / iOS苹果官方网络模拟器(延迟、丢包、带宽)
ClumsyWindows模拟丢包、延迟、限速等
NetEm(Linux)Linux命令行模拟网络质量,非常灵活
腾讯 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 是否均可安装
不同 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 只是“退到后台”,你再切回来,就像是“把它从后台唤醒”

 举个例子:

  1. 你刚开机,点微信 → 冷启动

  2. 微信退到后台没关 → 你再点回来 → 热启动

  3. 你把微信从后台滑掉(彻底杀死)再点开 → 冷启动

对比项冷启动(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 结合脚本分析请求是否达标。”

 

http://www.dtcms.com/a/273037.html

相关文章:

  • pyqt-3(QSS、读取带qrc的ui、信号与槽函数)
  • CMake指令:add_custom_command和add_custom_target详解
  • Vue响应式原理五:响应式-自动收集依赖
  • OKHttp 核心知识点详解
  • 页面html,当鼠标点击图标,移开图标,颜色方块消失
  • 【牛客刷题】跳台阶(三种解法深度分析)
  • doker以及网站案例
  • 快速上手ASP .NET Core 8与MongoDB整合
  • 200W 以内的伺服电机 典型应用场景
  • C语言顺序表:从零开始,解锁数据结构之门!
  • YOLO系列pt导出不同onnx方法
  • Renren框架DistributeLock排他锁实现详解
  • 企业内网系统:从传统开发到智能赋能的进化之路
  • 安达发|医疗器械行业APS自动排单:智能化生产管理的未来之路
  • useRef跨渲染周期存储
  • 数据结构 --- 队列
  • 10.Docker安装mysql
  • chatgpt是怎么诞生的,详解GPT1到GPT4的演化之路及相关背景知识
  • dexie 前端数据库封装
  • 使用快捷键迅速校准多个通道 | IPEmotion
  • 软件技术:柯里化
  • 《PyQt6-3D应用开发技术文档》
  • 仿豆包智能输入框实现
  • python基础25_某大网校(下)处理json数据以及保存题库
  • 安全访问云端内部应用:用frp的stcp功能解决SSH转发的痛点
  • Linux驱动开发(platform 设备驱动)
  • 老题新解|矩阵转置
  • AI驱动的业务系统智能化转型:从非结构化到结构化的智能转换
  • 【STM32 学习笔记】FLASH闪存
  • pytorch学习-12循环神经网络(基础篇)