移动端发布与运营

• 热修复的原理（补丁下发、动态加载）
• 补丁生效的验证（修复后的行为、覆盖范围）
• 补丁失败与回滚机制

热修复不做发版即可修复线上问题，其测试需验证：1) 补丁生效——下发补丁后，目标 bug 是否被修复、覆盖到的用户/版本是否正确、修复代码是否真正执行（而非仅加载）；2) 补丁兼容——补丁与当前版本代码、资源、SO 是否兼容，不引发新崩溃；3) 失败回滚——补丁加载失败、校验失败、与新版本冲突时，能否自动回滚到原逻辑而不崩溃、不篡改；4) 下发与生效链路——补丁包下发、下载、校验（签名/哈希）、加载、生效时机（重启/热生效）、失效策略。测试方法：构造线上 bug 场景，下发补丁验证修复；模拟补丁损坏/校验失败验证回滚；验证补丁在异常网络、灰度与全量下的行为。还需验证热修复框架本身（如 Tinker、Robolectric）与厂商 ROM/系统版本的兼容性。补丁测试需在"测试环境模拟线上"下进行，并配套回滚预案。

热修复是线上应急手段，测试重点是"生效 + 回滚"双保险。回答要体现补丁链路（下发-校验-加载-生效）与失败兜底，并强调与版本兼容。

• 远程配置（开关）变更的机制
• 配置变更引发崩溃的成因（类型空值、非法值、缺失字段）
• 配置防护与兜底（默认值、校验、容错）

远程配置（如 feature flag、参数下发）变更后 App 即时生效，若配置值非法（类型错误、空值、超范围、字段缺失）会导致逻辑异常甚至崩溃。防护测试需覆盖：1) 配置值校验——所有配置读取处加默认值与类型校验，缺失/非法值走兜底而不崩溃；2) 异常配置注入——下发空值、错类型、超范围、极端值，验证 App 不崩溃、功能降级合理；3) 配置变更时机——运行中变更（热更新）时刷新的健壮性、页面重建；4) 灰度与回滚——配置变更先灰度、随时可回滚，并验证回滚后恢复正常；5) 配置与版本兼容——同配置在不同版本语义不同时的处理。测试方法：用配置平台下发异常与边界值，自动化验证崩溃/ANR；用 Mock 配置服务注入非法 payload；验证默认值兜底与告警。需建立"配置即代码"的测试与监控，配置变更纳入发布门禁。

远程配置是"线上可变的代码"，是崩溃风险源。回答要体现"非法值不崩溃 + 兜底 + 灰度回滚 + 异常注入测试"的防护体系。

• 前后端发布顺序与兼容协调
• 推送与版本、活动的联动
• 全链路（App+服务端+推送）的端到端验证

全链路发布协调测试需确保 App 新版本、后端新接口、推送活动三者协同发布时整体可用。要点：1) 发布顺序——确定后端先行还是 App 先行，验证不同版本组合（旧 App+新后端、新 App+旧后端）的兼容，避免接口不匹配；2) 推送联动——推送消息与 App 新版本功能/活动对齐，验证推送到达、点击跳转到新版本页面、旧版本收到推送时的降级；3) 端到端验证——从 App 发起请求到后端再到推送的全链路冒烟，覆盖核心链路（注册、下单、收通知）；4) 发布窗口——前后端发布时间差、推送与活动对齐的窗口内，App 行为是否一致；5) 回滚协调——发布出错时前后端与推送的协同回滚。测试方法：构造多版本矩阵、预发布环境端到端验证、推送与版本联动用例、以及发布窗口的演练（灰度→全量→验证）。需建立发布 checklist 与回滚预案。

全链路协调的本质是"多组件版本组合的兼容与联动"。回答要体现发布顺序兼容、推送联动、端到端冒烟与回滚协调，体现发布工程意识。

• 灰度分阶段放量（canary/小流量/半步）
• 核心指标（崩溃率、ANR、留存、关键转化）监控
• 灰度决策门禁（达标放量、超标回滚）

灰度发布需分阶段放量（如 5%→20%→50%→100%），并实时监控核心指标做放量/回滚决策。监控指标：崩溃率（crash-free）、ANR 率、启动失败、主流程转化、留存、关键业务错误率。决策逻辑：每个灰度阶段用"指标达标门禁"判断——新版本崩溃率/ANR 不高于基线（如相对旧版本不劣化、低于阈值），关键转化不掉点，即放量；若指标超标（崩溃率突增、ANR 上升、留存下滑）则暂停或回滚。需与对照基线（旧版本同口径）对比，排除自然波动。同时监控分维度（机型、系统、渠道）的指标，避免局部劣化。灰度决策要自动化：指标实时采集、阈值告警、自动暂停/回滚触发。测试侧配合：灰度期间的线上验证、问题定位与回滚预案。

灰度决策的核心是"指标驱动 + 分阶段门禁"。回答要体现放量节奏、核心指标、基线对比、自动回滚决策，体现数据化运营。

• A/B 分流的实现（分桶、参数、分层）
• 分流正确性（覆盖、互斥、均匀性、稳定性）
• 分流参数的获取与上报

A/B 实验分流正确性验证需覆盖：1) 分桶正确性——用户按规则（如 hash 取模）稳定分到 A/B 组，同一用户多次进入命中间组（稳定性）、组间覆盖完整、无遗漏；2) 互斥与分层——实验间互斥关系正确，避免同时命中多个冲突实验；3) 参数传递——实验参数（组别、实验名）正确下发并随请求上报，后端能正确归纳；4) 均匀性——分桶比例符合配置（如 50/50），避免倾斜；5) 无效流量——老用户、测试用户、非目标用户被正确排除，避免污染数据。测试方法：构造大量用户 ID 验证分桶分布与稳定性、验证参数上报链路、用埋点核对实验命中、检查互斥与白名单。关键点：分流逻辑与上报链路一致，分桶结果可复现，数据口径统一。

分流正确性是实验可信的前提。回答要体现分桶稳定性、互相斥、参数上报与均匀性校验，并强调防污染。

• 应用商店审核要求（Google Play/App Store）
• 隐私与合规预检（权限、隐私标签、SDK）
• 审核预检的自动化检查

应用商店审核预检需纳入测试，避免发布后被拒。检查项：1) 权限声明——申请的权限是否与功能匹配、是否最小化（如无需定位却申请定位会被拒）；2) 隐私标签/隐私政策——数据中心、隐私政策链接、数据收集声明是否完整一致；3) SDK 合规——第三方 SDK 是否有违规收集（如 IM 未授权、设备指纹）；4) 内容合规——是否含违规内容、诱导分享、敏感信息；5) 元数据——App 名称、描述、截图、类目是否符合规范。预检方法：静态检查（扫描 Manifest/Info.plist 权限、SDK 列表、Privacy 标签）、动态检查（抓包确认数据收集）、UI 检查（隐私弹窗、授权时机）。可建立"审核预检 checklist"与自动化脚本，在发布前自动扫描并输出风险报告。被拒常见原因：权限滥用、隐私政策缺失、数据收集违规、内容违规，预检应针对性覆盖。

审核预检是"合规前置"的测试。回答要体现权限/隐私/SDK/元数据四类检查，并给出静态+动态+UI 的预检方法。

• 渠道包差异（渠道号、SDK、配置、功能）
• 多方渠道的打包与分发
• 渠道差异的测试（埋点、推送、更新）

多渠道包指同 App 针对不同渠道（应用商店、官网、三方市场）打包，差异在渠道号、SDK（如渠道统计、推送）、配置与功能开关。测试需覆盖：1) 渠道号正确——各渠道包写入的渠道标识正确，埋点上报的渠道字段正确；2) 渠道 SDK 差异——不同渠道集成的统计/推送/广告 SDK 是否正常，不影响主功能；3) 渠道专属功能——某渠道的专属活动、更新提示、下载链接是否生效；4) 更新与下载——各渠道包的版本更新、升级、下载地址是否正确；5) 一致性——核心功能与体验在各渠道包一致，不因渠道差异引入 bug。测试方法：对每个渠道包做核心功能冒烟 + 渠道特有项验证；用渠道号断言埋点、用抓包核对渠道参数；建立多渠道打包流水线并自动化校验。注意渠道包与基础包的功能一致性是重点，防止渠道化引入回归。

渠道包测试的关键是"渠道差异项 + 核心功能一致性"。回答要体现渠道号、渠道 SDK、专属功能与一致性的验证，并强调自动化。

• 新系统早期版本与 Beta 的适配
• 系统 API 变更、权限、行为差异
• 适配测试的时机与策略

新系统适配需提前介入，避免发布后崩溃。测试策略：1) 尽早跟进——在新系统 Beta/开发者预览版发布时即开始适配测试，用模拟器/开发者设备先行验证；2) 重点覆盖——系统 API 变更（如 Android 权限模型、后台限制、iOS 新通知权限）、行为差异（生命周期、深色模式、字体）、新特性（如 Android 12+ 剪贴板提示、iOS 隐私标签）对 App 的影响；3) 兼容性回归——对核心功能与关键流程在新系统上全量回归，验证崩溃、ANR、布局、权限；4) 目标 SDK 升级——按新系统要求提升 targetSdkVersion，并验证随之而来的行为变化；5) 缺陷跟踪——Beta 期间发现的适配问题及时反馈给开发。测试方法：新系统模拟器/真机 + 云真机新系统机型、系统 API 兼容性扫描工具、适配专项 checklist。需在正式发布前完成适配回归，避免新系统发布后集中崩溃。

新系统适配是"时间前置"的预防性测试。回答要体现早期跟进、API 变更重点、全量回归与 targetSdk 升级，体现前瞻性。

• 卸载时本地数据（缓存、数据库、文件）的清理
• 重装后的数据状态（全新/残留）
• 卸载重装的数据一致性（登录态、缓存）

卸载重装测试验证本地数据清理的一致性。要点：1) 卸载清理——卸载后本地缓存、数据库、SharedPreferences、文件是否被彻底清除（Android 卸载通常清 data 目录，但可能残留外部存储文件）；2) 重装状态——重装后是否为全新状态（无旧登录态、无旧缓存、无旧数据），避免残留导致数据混乱或安全风险；3) 数据一致性——重装后功能正常、无旧数据污染（如会员、设置残留）；4) 与升级差异——升级（覆盖安装）保数据，卸载重装清数据，两者行为需区分。测试方法：使用 App 产生数据后卸载，检查文件系统是否残留（adb shell 检查 data 目录、外部存储）；重装后验证无旧登录态、无旧缓存、功能从头可用；对比卸载重装与覆盖升级的数据差异。注意 Android 自动备份（Auto Backup）可能导致重装后恢复数据，需验证其行为是否符合预期。

卸载重装的核心是"清理一致性"。回答要体现"卸载清干净、重装全新态、与升级区分"三层，并注意系统备份机制。

• 版本检查与升级策略（强更/弱更）
• 强制升级弹窗与不可跳过
• 弱更的跳过升级与提醒

强更/弱更测试需覆盖：1) 版本检查——启动时向服务端查询版本，正确判断当前版本是否需升级；2) 强更——弹强制升级弹窗、不可跳过、无升级入口时无法继续使用（或只能退出），需验证"升级后功能正常"；3) 弱更——弹非强制升级提示，可跳过、可稍后提醒，验证跳过后继续使用旧版本功能正常；4) 跳过升级——弱更时"跳过"后是否仍可正常使用、是否在适当时机再次提醒；5) 降级兼容——旧版本客户端与新后端（或新接口）下是否兼容，是否降级/提示，避免崩溃；6) 版本边界——最低支持版本、超低版本被强制升级或不支持。测试方法：Mock 服务端下发不同版本号与升级策略配置，验证各版本客户端的弹窗与行为；用不同版本 App 组合新后端验证兼容。需建立版本策略矩阵并纳入发布回归。

强更/弱更的核心是"版本策略的分支覆盖"。回答要体现版本检查、强更不可跳过、弱更可跳过、降级兼容与版本边界，体现策略测试。

• 后端回滚对客户端的影响
• 旧版本客户端与新/旧接口的兼容
• 数据一致性（字段、结构、状态）

后端回滚（如新接口异常回退到旧接口）需保证旧版本客户端兼容性与数据一致性。要点：1) 接口兼容——后端回滚后，客户端正在调用的接口参数、返回结构是否匹配，避免字段缺失/类型变化导致解析崩溃；2) 版本兼容——线上同时存在多个客户端版本，回滚后各版本都能正常调用后端；3) 数据一致性——回滚后客户端展示的数据、状态与后端一致（如订单状态、缓存字段），不因回滚出现脏数据；4) 降级路径——接口不可用时客户端是否有降级提示而非崩溃。测试方法：构造"新客户端+回滚后端"、"旧客户端+回滚后端"等多版本组合，验证接口兼容与数据解析；用 Mock 后端模拟回滚后的字段变化，验证客户端容错；建立回滚预案测试——回滚后全链路冒烟。关键：接口契约设计与字段向前兼容，可避免大部分回滚问题。

回滚兼容的核心是"接口契约的前向兼容"。回答要体现多版本组合、字段解析容错、数据一致性校验与回滚预案演练。

• 埋点事件触发时机与参数完整性
• 埋点的去重与重试（重复上报、丢失）
• 埋点数据链路验证（客户端→上报→服务端）

埋点正确性测试：1) 触发时机——关键事件（启动、点击、下单、支付、页面停留）是否在正确时机触发，不提前不遗漏；2) 参数完整性——事件携带的参数（用户 ID、商品 ID、渠道、金额、时间）是否齐全、类型正确、无缺失；3) 去重与重试——同一事件是否重复上报（网络重试、多次点击）、丢失后是否补传，需验证上报幂等且不重复；4) 链路一致性——客户端上报到服务端的数据与埋点定义一致，服务端能正确解析汇总。测试方法：埋点校验工具（Charles 抓包核对 payload、埋点 SDK 的调试模式、埋点日志）、自动化脚本触发事件并断言参数、用 Mock 上报服务验证去重与重试。埋点错误影响：埋点缺失/错误会导致运营数据失真，影响转化率、留存、渠道效果等决策，污染 A/B 与报表，因此埋点正确性是数据质量基础，需纳入测试。

埋点测试是数据质量的基础。回答要体现触发时机、参数完整性、去重重试与链路核对，并强调其对运营决策的影响。

• 推送到达率与点击归因
• 静默推送与厂商通道回退
• 消息丢失与重复的监控

推送运营验证需覆盖：1) 到达率——推送消息在 App 前台/后台/被杀、不同厂商通道下的到达率，验证消息是否真正到达设备；2) 点击归因——用户点击推送后，归因到正确的推送活动/消息，参数（campaign、消息 ID）正确传递并上报；3) 静默推送——静默（无通知栏）推送用于数据更新/业务触发，验证其到达与触发是否正常；4) 厂商通道回退——App 被杀时经厂商通道（FCM/APNs/厂商 Push），App 活着时用长连接，验证通道切换与回退正确；5) 丢失与重复——监控消息丢失（未到达）与重复（同一消息多次下发），通过消息 ID 去重，验证幂等。测试方法：真实推送 + 各厂商/通道验证到达；抓包核对点击上报参数；用消息 ID 和日志监控重复/丢失；建立推送链路监控（到达率、点击率）与告警，对比各渠道。推送正确性影响运营触达与转化，需端到端验证。

推送运营验证是链路质量与归因可信度。回答要体现到达率、点击归因、静默推送、通道回退与去重监控，强调端到端。

• Beta 渠道（内测/公测）的反馈收集
• 反馈归类与缺陷跟踪
• 反馈到修复的闭环

Beta 渠道反馈闭环需建立"收集-归类-跟踪-修复-验证-上线"的完整链路。1) 收集——通过内测渠道（TestFlight、应用内反馈、Bug 上报、用户群）收集用户反馈与崩溃信息；2) 归类——反馈按严重度（崩溃/功能/体验）与模块归类，Bug 上报附堆栈、日志、机型、复现步骤；3) 跟踪——用缺陷管理工具（Jira/需求平台）建 Issue，关联版本与责任人，设定优先级与解决时限；4) 修复与验证——复现修复后在 Beta 最新版验证，确认修复未被回归；5) 上线衔接——确认稳定的 Beta 版本正式发布，Beta 反馈转化为发布前回归项。关键：反馈需有元数据（版本、机型、日志）便于定位，闭环要有时效（Beta 期及时修复），并将高频问题纳入正式回归。同时监控 Beta 用户活跃与反馈量，作为版本质量信号。

Beta 闭环是"质量前置"的运营。回答要体现收集-归类-跟踪-修复-验证-上线的闭环，并强调元数据与时效。

• 崩溃相关指标（崩溃率、crash-free）
• 留存指标（日/周/月留、留存曲线）
• 转化指标（漏斗、转化率）

移动端运营数据需联动理解：1) 崩溃——崩溃率、crash-free 用户占比、Top 崩溃，反映稳定性，崩溃过高会直接影响留存与转化；2) 留存——次日/7 日/30 日留存、留存曲线，反映用户粘性与产品价值，受版本质量（崩溃、卡顿）影响；3) 转化——激活→注册→付费等漏斗转化率，反映商业效果，受体验与稳定性影响。三者联动：崩溃率上升会带动留存下滑、转化下降；反之体验提升带动留存转化。测试与运营侧需建立指标看板，监控版本间变化，用数据分析定位问题（如某版本崩溃集中导致留存下降）。测试侧通过质量指标（崩溃、ANR、卡顿）支撑运营指标，两者对齐形成"质量→体验→商业"的因果链。运营决策基于这些数据，测试需保证数据采集的准确与完整。

该题考察运营指标体系的理解。回答要界定崩溃、留存、转化三类指标及联动关系，并体现测试与运营指标的对接。

• 前后端发布时间差的窗口验证
• 推送与活动对齐的时机
• 发布窗口内新旧版本行为

发布窗口协调测试验证发布时间差与活动对齐下的兼容性。场景：1) 前后端发布时间差——若后端先发布、App 后发布（或反之），在窗口期（后端新/App 旧 或 后端旧/App 新）内，App 是否兼容、不崩溃、不产生错误数据；2) 推送与活动对齐——推送消息与活动开始时间、App 功能上线时间对齐，验证推送到达时 App 功能是否可用、活动页是否可进入；3) 窗口内行为——发布窗口内新旧版本用户交集下的行为一致性。测试方法：构造多版本组合矩阵，在预发布环境模拟时间差窗口，验证兼容与降级；用时间控制（Mock 时间/活动开关）验证推送-活动-功能对齐；发布窗口演练（灰度-全量-回滚）验证协同。发布窗口协调需有 checklist 与回滚预案，确保窗口内无故障。

发布窗口协调的核心是"时间差下的版本兼容与活动联动"。回答要体现前后端版本组合、推送活动对齐与窗口演练。

• 发布后核心链路冒烟
• 崩溃/异常监控的实时性
• 灰度放量节奏与监控联动

发布后线上验证需建立"冒烟-监控-放量"联动机制。1) 核心链路冒烟——发布后立即对核心功能（启动、登录、首页、下单、支付、推送）做线上冒烟，验证基本可用；2) 崩溃监控——实时监控崩溃率、ANR、关键错误，设定阈值告警；3) 灰度放量联动——按灰度节奏（如 5%→20%→50%）放量，每阶段监控指标，达标才继续放量，异常则暂停/回滚；4) 问题处置——冒烟或监控发现异常时，快速定位（堆栈、日志、版本）、回滚或修复，并通知。联动机制：以监控指标为决策依据，放量节奏与监控联动，冒烟作为放量前置检查。测试侧配合：发布后保持一段线上验证期，监控新版本指标与基线对比，发现问题及时反馈。需建立发布后 check 清单与应急响应流程。

发布后验证的核心是"冒烟-监控-放量"的联动闭环。回答要体现三者联动、阈值决策与问题处置，突出自动化与应急。

• 包体积、启动耗时、崩溃率的版本基线
• 版本间对比与劣化判定
• 发布门禁的阈值与拦截

将包体积、启动耗时、崩溃率纳入发布门禁需建立"指标基线 + 版本对比 + 阈值门禁"。1) 建立基线——在受控环境测定各版本基线（包体积、冷启动耗时、崩溃率），形成历史基线库；2) 版本对比——新版本发布前，用相同口径重测，与基线对比计算劣化幅度；3) 门禁判定——设定阈值（如包体积增长超 5%、启动耗时劣化超 10%、崩溃率超阈值），超阈则阻断发布（可人工评审后放行）；4) 自动化——在 CI 中自动采集包体积、跑启动性能测试、汇总崩溃率，与基线比对生成门禁结果。包体积关注 APK/IPA 大小与增长来源（资源、依赖、SO），启动耗时关注冷启动与首屏，崩溃率关注线上稳定性。基线需随重大硬件/平台变化校准，避免误判。门禁使质量指标前置到发布前，防止劣化上线。

该题考察"质量门禁"的落地。回答要体现基线建立、口径一致的版本对比、阈值门禁与 CI 自动化，突出工程化。