移动端测试核心

• 弱网三要素（延迟、丢包、抖动）的模拟方法
• 网络代理类工具（Charles、Fiddler、Network Link Conditioner）与设备级工具（Android 控制台、iOS Network Link Conditioner）
• 弱网条件在自动化测试中的集成与用例设计

弱网模拟通常分为设备级与代理级两类。Android 可通过 adb shell 的 tc netem 命令直接对网络栈注入延迟、丢包与抖动；iOS 可通过 Xcode 的 Network Link Conditioner 或开发者菜单模拟。代理工具（Charles、Fiddler、Whistle）通过设置 proxy 批量注入弱网 profile，并支持脚本化切换。自动化测试层面，可借助 Appium 的 networkSpeed、networkConnection Desired Capabilities 或第三方框架（如 Clumsy、ATC——Facebook 的 Augmented Traffic Control）在 CI 中动态切换弱网条件；更进阶的做法是自定义 WebDriverAgent 扩展或使用 Charles 的 .throttle 配置与 JMeter 结合做链路级弱网压测。测试用例应覆盖三类弱网：弱信号（高延迟）、丢包、抖动，并验证超时、重试、加载态与降级策略。

弱网测试的核心是"可控且可重复"，需要把网络质量参数化并可在测试中途切换，才能真正验证客户端的容错逻辑。设备级工具更贴近真实物理链路，代理工具更易脚本化与批量化，两者应结合使用。

• 超时策略（连接超时 vs 读超时）的验证
• 重试次数、重试间隔与退避（backoff）算法
• 幂等性（idempotency）设计：重试是否造成重复提交或数据不一致

验证弱网下的超时、重试与幂等，需要先确定客户端对每个请求是否设置了连接超时与读超时，且超时值是否合理（通常小于服务端超时，避免雪崩）。测试时通过弱网代理人为制造超时，观察客户端是否有超时提示、是否进入重试逻辑、重试次数与间隔是否符合退避策略。幂等性的验证需要构造"请求已发出但响应丢失"的场景，重试后服务端不应产生重复订单、重复扣款等副作用；可通过服务端提供幂等键（idempotency key）或客户端生成唯一请求 ID 来实现。测试手段包括：用 Charles 的断点（breakpoint）拦截响应制造超时、用 Mock 服务端返回特定错误码（如 503/超时）触发重试，以及核对重试后数据库记录数未重复。

超时是"客户端怎么感知"，重试是"客户端如何补救"，幂等是"补救后服务端如何兜底"，三者是同一个链路，必须联动验证。重点在于验证"重试不产生副作用"，这是弱网测试最易遗漏的点。

• WebView 与原生页面的边界与交互（JS Bridge）
• 不同 WebView 内核（Android 系统 WebView/X5/Chromium、iOS WKWebView/UIWebView）的兼容差异
• 样式、字体、JS 引擎、导航与返回键的兼容

混合页面兼容性测试要先确认 WebView 内核版本与渲染引擎，Android 上系统 WebView 与厂商内核（X5 等）存在渲染差异，iOS 上 WKWebView 替代 UIWebView 后内存与 Cookie 行为不同。测试要点包括：页面在不同内核下的渲染一致性、JS 执行与 CSS 兼容（如 flexbox、sticky 定位）、字体缩放与深色模式的适配、JS Bridge 调用是否正常、原生返回键与 WebView 历史栈的交互、Cookie/登录态的跨端共享。自动化测试可通过 Appium 的 context 切换（NATIVE_APP ↔ WEBVIEW）在 WebView 内用 WebDriver 协议定位元素，iOS 需开启 Safari 自动 Web 检查，Android 需开启 WebView 调试。兼容性测试还要覆盖不同 OS 版本、不同 WebView 内核、不同屏幕尺寸下的滚动与点击事件穿透。

混合页面的最大风险是"同一套 Web 代码在不同内核上表现不一致"，因此测试矩阵必须包含内核版本维度，而不只是系统版本。关注 JS Bridge 与返回键这类原生-Web 交互点，是混合页面的特有风险。

• 环境依赖差异（浏览器 vs 设备/系统）
• 系统交互差异（App 与系统 API、权限、生命周期）
• 性能关注点差异（加载/渲染 vs 功耗/内存/启动）

Web 与 App 测试的核心差异源于运行载体：Web 运行在浏览器，依赖浏览器内核与网络，升级即时生效；App 运行在操作系统，需安装、有版本与生命周期。维度对比：环境上，Web 关注浏览器版本与分辨率，App 关注 OS 版本、机型、屏幕、内存；系统交互上，App 需测试权限、通知、后台、生命周期、推送、深链等系统能力，Web 基本无此诉求；性能上，Web 关注首屏加载、LCP/CLS、白屏，App 关注冷启动耗时、内存占用、功耗、卡顿 ANR、帧率；发布上，Web 可 CDN 持续发布灰度，App 需过应用商店审核、覆盖安装、灰度与回滚；专项测试上，App 有弱网、中断、安装卸载升级、真机兼容、热修复等专项，Web 则更侧重跨浏览器兼容。因此 App 测试的复杂度与测试面更广，需引入设备矩阵与专项工具。

该题考察对两类测试本质差异的理解。回答要抓住"载体不同"这一根本点，逐维度展开，并强调 App 独有的系统交互与专项测试，体现测试设计的系统性。

• 机型/版本影响因子分析（市场占有率、用户画像、活跃设备）
• 按风险等级分级（重点机型、代表机型、长尾机型）
• 矩阵裁剪方法（正交、等价、风险驱动）

兼容性矩阵裁剪的核心是"以风险与市场份额驱动，而非全量覆盖"。首先基于埋点数据统计活跃设备分布，按市场份额、系统版本、厂商、屏幕尺寸、内存等级排序，形成 Pareto 重点（通常 20% 机型覆盖 80% 用户）。策略上分为三层：核心层（市场份额最高的几款机型 + 最新/主流两个系统版本，用真机严测）；代表层（覆盖不同厂商、屏幕比例、内存档位的代表性机型，用云真机并行跑）；长尾层（低份额机型，仅做冒烟或选择性回归）。同时用正交试验或 pairwise 方法缩减组合爆炸，避免全组合。真机用于关键交互与专项，模拟器用于快速回归与开发阶段，云真机平台用于批量覆盖。矩阵需随季度用户数据动态调整。

全量机型测试不现实，关键是建立"优先级的量化依据"。用市场份额数据做 Pareto 分级，配合正交/pairwise 减少组合，是行业通用做法，体现工程化与成本意识。

• 折叠屏的展开/折叠状态、尺寸变化与适配
• 刘海/挖孔屏的安全区（safe area）适配
• 高刷屏的帧率与流畅度

布局兼容性测试需针对不同屏幕形态专门设计。折叠屏：需测试展开态与折叠态两种尺寸下的布局自适应、Activity 因 OpenGL 尺寸变化导致的 onConfigurationChanged 处理、边缘区域是否被遮挡，以及分屏时布局重建。刘海/挖孔屏：需验证内容是否避开安全区（safe area），导航栏、状态栏、全屏视频与图片是否被遮挡，可通过 android:windowLayoutInDisplayCutoutMode 与 iOS 的 safe area insets 验证。高刷屏：关注 90/120Hz 下动画是否流畅、是否掉帧、帧率是否与刷新率匹配。此外还需用不同 DPI、宽高比（如 19.5:9）与字体缩放组合验证布局不溢出、不遮挡、可滚动。测试手段包括开发者模拟器、厂商折叠屏真机、SDK 的 safe-area 工具与视觉回归截图对比。

屏幕形态多样化的本质是"布局要在不同尺寸、不同安全区、不同刷新率下都正确"。回答要分形态逐一说明重点，并强调用真机 + 视觉回归验证，避免只靠模拟器。

• 不同机型内存分配上限（32 位/64 位、Android memory class）差异
• 大内存占用场景（图片、列表、视频）的边界测试
• 低内存机型（Low-memory）的降级与 OOM 验证

内存边界测试要先摸清目标机型的内存 profile：Android 上可通过 getMemoryClass()/getLargeMemoryClass() 获取每进程堆上限，32 位 vs 64 位进程的地址空间上限也不同。测试时构造大内存场景（加载超大大图、长列表、多页面堆叠、视频流），观察是否触发 OOM 或 ANR。低内存机型要验证系统在内存紧张时的降级行为：onLowMemory/onTrimMemory 回调、后台回收、以及是否能通过 activity.isFinishing 等恢复。方法上可用 adb shell am 注入大内存压力、在设备端用 Memory Profiler 监控堆增长、用 Monkey 制造内存压力，并配合 dumpsys meminfo 统计 PSS。最佳实践是建立"内存上限阈值表"，按机型档位设定测试边界，并对长列表分页、图片压缩、缓存淘汰策略做针对性验证。

碎片化使"统一的内存标准"不可行，必须按机型内存档位分级。回答要体现对 Android 内存模型（memory class、LowMemory、PSS）的理解，并给出压测与验证手段。

• 深色模式（Dark Mode）的颜色适配与资源切换
• 系统字体缩放（Font Scale）下的布局适配与防截断
• 深色模式与第三方控件/WebView 的兼容

深色模式测试要点：验证 UI 是否随系统深色模式正确切换，颜色是否符合设计规范（不出现刺眼高对比、图片与文字对比度足够），是否支持"跟随系统/手动/每日定时"三种模式，以及自定义主题资源（如 Theme.Material 的 day/night 资源）是否正确加载；同时验证 WebView 与第三方 SDK 在深色模式下的表现，避免白底黑字反转为黑底黑字。字体缩放测试要点：验证系统字体调大（如最大 200%）后布局是否溢出、文字是否被截断、按钮是否被遮挡、是否支持自适应换行；需覆盖无障碍大字体场景阅读。测试方法包括切换系统设置、遍历所有页面、用截图对比与视觉回归工具，以及检查对比度（WCAG）。

深色与字体缩放都是"系统级配置影响 UI 渲染"的典型场景，测试要覆盖资源切换、布局自适应与对比度可读性三个层面，并注意与第三方组件/WebView 的联动。

• 各权限的拒绝/允许/仅在使用期间允许三态
• 权限拒绝后的功能降级与引导
• 权限变更（授权后撤销）的运行时处理

权限拒绝场景的核心是"应用在权限不可用时仍能优雅运行"。测试需覆盖：首次拒绝、拒绝后再次请求、授权后到设置里撤销、选择"仅使用时允许"等三态；拒绝定位后，地图/天气/附近推荐应降级为定位失败提示而非崩溃；拒绝相机后，扫码/拍照应引导去设置开启或给出替代方案；拒绝通知后，推送不再到达、红点不应误导、相关设置页应体现权限状态。还要验证运行时权限请求的时机（是否在用户需要时请求而非启动即弹）、一次请求 vs 多次请求的策略，以及权限被撤销后正在运行的功能是否立即响应。测试手段包括在系统设置中手动切换权限、用 adb 命令 pm grant/pm revoke 动态控制权限、并结合自动化遍历各权限组合。

权限拒绝是移动端最高频的异常路径之一。回答要体现对"权限三态 + 运行时变更"的理解，并强调"拒绝后降级而非崩溃"这一健壮性核心。

• 各厂商推送通道（华为 HCM、小米 MiPush、OPPO、vivo）与厂商 Push 的差异
• 厂商后台限制（自启动、省电策略、后台冻结）对 App 运行的影响
• 推送到达率与真机验证

ROM 差异主要体现在推送通道与后台进程限制上。测试需在华为、小米、OPPO、vivo 等真机上分别验证：推送消息经厂商通道（而非仅应用内长连接）能否在 App 被杀后仍到达；后台限制（如小米的后台省电、华为的自启动管理、内存清理）是否会导致 App 被系统冻结、定时任务与推送失效。测试要点包括：App 被划掉后推送是否可达、被系统省电优化后后台任务是否被延迟、用户在系统设置中关闭自启动后功能是否降级。同时验证"厂商通道与主动长连接"的切换与回退逻辑，以及推送到达率在该厂商下的表现。由于 ROM 行为由厂商掌控，同类测试各厂商需分开执行，并记录厂商系统版本与省电策略设置。

答案是"厂商真机 + 厂商通道"，因为模拟器与普通设备无法复现厂商的 ROM 限制。回答要体现对厂商推送通道与后台限制机制的了解，并强调真机验证的必要性。

• JS Bridge 的调用协议与返回值处理
• 原生返回键与 WebView 历史栈的交互
• 分享能力（原生分享面板）的调用与结果

H5 与原生交互测试要覆盖：JS Bridge 调用——验证 H5 调用原生能力的参数传递、回调返回值、同步/异步调用、异常与超时处理，以及 Bridge 注入时机（页面加载前/后）、未注册方法是否被安全拦截；原生返回键——验证用户按返回键时是退出 WebView 页面还是返回上一级 H5 历史，需与 WebView 的 canGoBack() 栈配合，避免误退 App；分享能力——验证 H5 触发原生分享面板后分享内容、图片、链接是否正确，分享成功/取消的回调是否到位，以及分享面板在深色模式与不同系统下的表现。测试方法包括用 Appium 切换 context 操作 H5、用 Charles 拦截 Bridge 请求、以及真机验证。异常路径需验证：WebView 加载失败时返回键行为、Bridge 调用无响应时的兜底提示。

交互测试的关键是"原生与 Web 的边界职责"。返回键、JS Bridge、分享都是典型的跨边界点，需明确每一侧的职责并验证异常路径。

• 各类中断事件（来电、短信、闹钟、低电量、蓝牙、耳机）对 App 生命周期的影响
• App 在前台/后台/锁定态下的中断表现
• 中断前/中/后的状态恢复与数据一致性

中断测试的核心是"事件打断前台 App 后，App 能否正确保存状态并恢复"。需覆盖：来电/通知——验证 App 是否被暂停、来电结束后是否恢复到原页面、正在进行的操作（输入、播放、支付）是否完好；闹钟/低电量——验证弹窗打断后功能是否正常、是否触发系统降级；锁屏/切后台——验证复用时状态是否保留。系统性做法是建中断矩阵：横轴为中断类型（来电、短信、闹钟、低电量、蓝牙、充电、锁屏、分屏），纵轴为 App 当前状态（页面、输入框、播放中、支付中、加载中），逐一组合验证。还要考虑多重中断（如来电时又收到短信）与中断后进程被杀等极端场景。工具上可用 Android 的 adb shell am broadcast 模拟通知、用系统设置模拟低电量、真机拨号模拟来电。

中断场景是 App 特有的高频真实场景。回答要体现"矩阵化组合"的工程思维，并按中断前后状态、数据一致性两条主线组织，避免单一场景。

• 多语言（i18n/l10n）与文案/布局适配
• 时区切换与时间显示（跨时区、夏令时）
• 时间边界（跨年、闰秒、午夜）下的业务逻辑

语言与时区边界测试的关键是"系统配置变化后，App 的展示与逻辑是否一致"。语言测试：覆盖多语言文案、右到左（RTL）语言布局、字符超长溢出、翻译缺失时的回退、以及本地化数字/货币/日期格式。时区测试：切换时区后，时间显示、倒计时、签到、订单时间戳是否按本地时区正确换算，跨时区（如东八区↔西八区）与夏令时切换是否导致时间偏移。时间边界测试：跨年（12 月 31 日 23:59 到 1 月 1 日）、午夜归零、闰秒（6 月 30 日 23:59:60）瞬间，业务逻辑是否异常，如签到日期、账单日、统计数据是否算错。测试方法包括在系统设置中切换语言/时区、用 adb shell settings put global time_zone 修改时区、Mock 系统时间，以及在真机+模拟器上验证。

这类边界测试容易被忽略，但数据一致性风险高。回答要体现对"展示层本地化 + 逻辑层时间换算"两个层面的区分，并给出可执行的边界用例。

• WiFi↔蜂窝切换时的连接中断与重连
• 切换过程中的请求、下载、上传、播放的连续性
• 切换后网络状态感知与界面提示

网络切换测试关注"切换瞬间的请求与体验是否受影响"。需验证：WiFi 切到蜂窝（或反之）时，正在进行的请求/下载/上传是否中断、是否自动重连、播放是否卡顿或续播；切换后 App 是否正确感知新网络（如提示"当前为移动网络"、视频清晰度降级）；缓存与断点续传是否正确。典型场景包括：播放视频时切换网络是否续播、上传大文件切换后是否重传、长连接（WebSocket/推送）切换后是否重连。测试方法包括真机手动切换、用 adb shell svc wifi enable/disable 与 svc data enable/disable 自动化切换、结合弱网工具模拟切换瞬间。还要覆盖"无网→有网"的恢复与"有网→无网"的即时提示。

网络切换本质上是一种"瞬时中断 + 恢复"场景，重点在于验证连接的自动恢复与状态一致性。回答要聚焦请求连续性、感知提示与断点续传三方面。

• 真机与模拟器的差异（系统行为、性能、传感器、网络、厂商 ROM）
• 适用场景（开发调试、快速回归 vs 专项、兼容）
• 云真机平台的作用

真机与模拟器的核心差异在于"真实度"。模拟器优势：启动快、可克隆、易并入 CI、可模拟内存/网络/时区、成本低，适合开发调试、快速功能回归、自动化冒烟与性能基线；真机优势：能复现真实系统行为（厂商 ROM、传感器、摄像头、GPS、推送、后台限制、来电中断、真实网络）、性能与耗电真实，适合兼容性、专项（弱网、中断、功耗、稳定性）、机型相关测试。选择策略：按测试目标分层——逻辑与功能回归优先模拟器（快而省），兼容与专项必须真机，云真机平台（BrowserStack、Firebase Test Lab 等）用于批量覆盖真机矩阵。需注意模拟器无法复现厂商 ROM 限制（如华为/小米后台）、部分传感器与真实 GPU 性能。

回答要体现"按测试目标选载体"而非一刀切。模拟器快但不真实，真机真实但慢，合理分工并用云真机放大覆盖是工程化答案。

• Chrome DevTools（Android 调试）与 Safari Web Inspector（iOS 调试）的配置
• WebView 调试开关与 setWebContentsDebuggingEnabled
• 局限：内核版本、调试端口、WiFi/数据线、厂商 ROM

WebView 远程调试分别针对 Android 与 iOS。Android：需在 WebView 上开启调试（WebView.setWebContentsDebuggingEnabled(true)，仅 debug 构建），通过 USB 连接后用 Chrome 打开 chrome://inspect，即可像调试网页一样审查 DOM、断点、网络与 Console。iOS：需在设置中开启"网页检查器"，用 Safari 的"开发"菜单连接真机（需 USB 或同一局域网）进行 Web Inspector 调试。局限包括：iOS 远程调试需 Safari 与 Xcode 工具链、WiFi 调试需同网段；Android 上系统 WebView 内核版本决定 JS/CSS 能力，且需开启调试开关，发布包若关闭则无法调试；厂商 ROM 可能限制 WebView 调试；真机调试需授权信任。除远程调试外，还可通过注入 JS、抓包工具（Charles）与 alert 模拟辅助定位。

调试是 WebView 混合页面测试的基础能力。回答要分别给出 Android/iOS 的配置步骤，并坦诚指出内核版本、调试开关、厂商限制等局限，体现实操经验。

• Activity 生命周期（onSaveInstanceState/onRestoreInstanceState）与 ViewController 生命周期
• 进程被杀后的状态保存与恢复（Bundle、SavedState）
• 多任务切换的临时状态丢失

状态恢复测试的核心是"进程在任意时刻被系统回收后，用户回到 App 时状态不丢失、不崩溃"。Android 需覆盖 Activity 的 onSaveInstanceState 保存 UI 状态（输入、滚动、表单）、onRestoreInstanceState 恢复，以及进程被杀后通过 savedInstanceState 重建；iOS 需覆盖 ViewController 的 viewWillDisappear/viewDidDisappear 与状态保存、以及 App 被杀后从初始流程恢复。测试要点：多任务切换（切后台再切回）后输入内容、页面位置、登录态是否保留；通过 adb shell am kill <package> 强制杀进程后冷启动，验证是否恢复到原页面或合理回到首页；低内存触发系统回收；以及切后台过久被系统回收的场景。自动化可用 adb 命令（am kill、am task）、am start 恢复，配合 Monkey 随机触发生命周期事件。

生命周期异常路径是 App 崩溃的高发区。回答要体现对 onSaveInstanceState/进程被杀/多任务切换的理解，并强调"可恢复性 + 不崩溃"双重标准。