小程序与跨端（H5/RN/Flutter）测试

• 小程序与 App 的运行载体差异（宿主 App vs 系统）
• 入口、安装、环境差异
• 性能关注点差异

小程序与 App 测试的核心差异源于运行载体：小程序运行在宿主 App（微信/支付宝）内，App 运行在操作系统。维度对比：入口——小程序多入口（扫码、搜索、分享卡片、聊天内打开、历史记录），App 从桌面图标进入；安装——小程序免安装、扫码即用，App 需下载安装；环境——小程序依赖宿主版本与基础库版本，App 依赖系统版本与机型；性能——小程序关注首屏渲染、分包加载、基础库性能，App 关注冷启动、内存、功耗、帧率；审核与发布——小程序需过平台的代码审核与类目审核、可灰度发布，App 需过应用商店审核；生命周期——小程序有独立的生命周期（onLaunch/onShow/onHide）与宿主 App 生命周期交互。因此小程序测试需额外覆盖多入口、宿主兼容、基础库兼容、审核规范等 App 不涉及的维度。

该题考察对小程序本质的理解。回答要抓住"宿主 App 承载"这一根本点，逐维度对比，并点出小程序特有的多入口与审核维度。

• 多入口的触发与落地页
• 分享卡片的参数与落地页还原
• 各入口的登录态处理

小程序入口与分享链路测试需覆盖：扫码（扫小程序码落地到指定页面）、搜索（关键词搜索进入）、分享卡片（分享给好友/群，点击还原到分享时页面）、聊天内打开（消息链接跳转）、历史记录（最近使用再次进入）。每个入口验证：1) 落地页是否正确——携带的路径与参数（scene、query、分享参数）能否还原到目标页面；2) 登录态——新用户/未登录进入是否先登录、登录后是否回跳原页面；已登录用户进入是否直接展示正确数据；3) 分享单向性——分享卡片在他人打开时参数是否正确、被分享者落地页与数据是否隔离；4) 边界——小程序码过期、参数缺失、分享到不同环境（群/单聊）的差异。测试方法：真实扫码、构造分享 payload、模拟搜索等入口，验证落地页与登录态，结合自动化（miniprogram-automator）覆盖多入口。

多入口测试的核心是"入口→落地页+登录态"的还原正确性。回答要体现各入口、参数传递、登录态分支与异常边界。

• 支付唤起与下单流程
• 支付成功/失败/取消的回调
• 退款流程与对账

小程序支付测试设计用例需覆盖：1) 唤起——调用支付时正确唤起微信/支付宝支付、参数（订单号、金额、签名）正确；2) 状态回调——支付成功、失败、取消、异常中断四种结果，客户端回调与后台校验是否一致，支付成功以服务端通知为准（防客户端伪造）；3) 幂等——同一订单重复支付/重复回调不重复扣款、不重复发货；4) 退款——退款申请、退款状态（处理中/成功/失败）、退款金额与渠道、退款后的订单状态；5) 对账——支付订单、退款记录与后台/财务对账一致（金额、订单号、渠道）；6) 异常——网络中断、支付超时、弱网下支付状态、重复点击。测试方法：用沙箱/测试号支付、Mock 支付回调、构造不同状态节点、自动化脚本验证支付全链路与对账。支付是资金敏感链路，需重点验证幂等与对账一致性。

支付测试是资金级高风险。回答要体现唤起、回调（以服务端为准）、幂等、退款与对账五个核心，并强调异常与防重复。

• 各类授权（登录、手机号、定位、摄像头）的同意/拒绝
• 授权撤回与再次请求
• 拒绝后的降级与引导

小程序授权测试需覆盖：微信登录（同意授权后获取用户信息、拒绝后无法登录或降级）、手机号（同意后获取手机号、拒绝后无法绑定）、定位（同意后获取位置、拒绝后相关功能降级）、摄像头（同意后扫码/拍照、拒绝后功能不可用）。测试要点：1) 同意/拒绝两种分支——同意后功能正常、拒绝后功能降级且不崩溃；2) 撤回——用户在小程序设置中撤回授权后，再次请求时的行为（重新弹授权、引导开启）；3) 再次请求——拒绝后再次触发授权请求的时机与策略；4) 引导——拒绝后是否引导用户去设置开启（openSetting）；5) 边界——授权弹窗的时机（是否在需要时请求）、以及不同基础库/宿主版本下授权 API 的差异。测试方法：真机/模拟器手动切换授权状态、用自动化逐个触发授权并验证分支、用 wx.authorize/getSetting 验证权限状态。授权测试需覆盖"同意-拒绝-撤回-拒绝后引导"全分支。

授权是小程序高频交互。回答要体现同意/拒绝/撤回/再次请求/引导的完整分支，并强调拒绝后降级不崩溃。

• 开发者工具/体验版/正式版的差异
• 基础库版本兼容
• 不同宿主版本与平台差异

小程序有三类环境：开发者工具（开发调试，可模拟）、体验版（真机预览，供测试/体验）、正式版（发布后用户使用）。差异：环境域名校验、调试能力、真机 vs 模拟器、数据隔离。测试需在体验版真机覆盖（开发者工具无法完全复现真机行为），并验证正式版发布后的行为。基础库版本兼容：小程序 API 依赖基础库版本，不同版本 API 能力不同，需验证在不支持新 API 的旧基础库上功能的降级（wx.canIUse 判断）、以及不同宿主（微信/支付宝/QQ）与版本下的兼容。测试方法：在开发者工具选不同基础库版本、体验版真机多版本验证、用 wx.getSystemInfo 检查基础库、针对旧基础库做 API 兼容与降级测试。环境切换测试：开发/体验/正式版的数据、域名、开关是否正确隔离。需建立"环境-基础库-宿主"兼容矩阵。

环境与基础库兼容是小程序特有风险。回答要体现三环境差异、基础库版本降级、宿主兼容与兼容矩阵。

• 分包加载与主包/分包路径
• 首屏渲染与包体积上限
• 分包预下载

小程序分包与性能测试需验证：1) 分包配置——主包与分包结构正确，分包加载路径（loadSubpackage）正确，分包不干扰主包；2) 包体积上限——小程序主包/分包有体积限制（如主包 2M、总包 30M（服务商代开发为 20M）），需验证未超限、超限时打包报错；3) 首屏渲染——首屏渲染耗时（onLoad→onReady→首屏数据）、启动性能、分包资源加载是否影响首屏；4) 分包预下载——preloadRule 预下载分包是否生效、预下载时机与成功率；5) 加载失败降级——分包加载失败、网络异常、资源缺失时是否有降级提示而非白屏。测试方法：用开发者工具/真机性能面板测量首屏与分包加载耗时、验证分包体积、模拟弱网/加载失败验证降级。性能指标需纳入基线，关注分包下载对首屏的影响。分包加载是小程序性能优化核心，需结合弱网与真机验证。

分包与性能是小程序核心质量项。回答要体现分包结构、体积上限、首屏渲染、预下载与异常降级，突出性能与稳定性。

• Storage 容量上限与溢出处理
• 缓存清理策略
• 版本升级后的数据兼容

小程序本地存储（Storage）测试需验证：1) 容量上限——小程序 Storage 有上限（如 10MB），写入超过上限时 wx.setStorageSync 是否报错、是否有降级处理，需测试大数据量写入；2) 清理策略——缓存过期、容量满时的清理策略（LRU、手动清理、设置页清理），验证清理后功能正常；3) 版本升级数据兼容——新版本读取旧版本存储的数据结构是否兼容（字段新增/变更、版本号迁移），避免解析崩溃；4) 读写一致性——Storage 读写、同步/异步 API、跨页面共享数据的一致性；5) 隔离——不同小程序/宿主间存储隔离。测试方法：写入边界数据量触发溢出、构造旧版本数据结构升级新版本验证、自动化校验读写一致。缓存数据兼容是升级崩溃的高发点，需重点验证。

存储测试的核心是"容量边界 + 数据兼容"。回答要体现容量上限、清理策略、升级兼容与读写一致性，强调升级兼容风险。

• open-type 跳转（公众号/App/网页）
• App 唤起与回跳
• 网页授权与登录态

小程序与外部跳转交互测试需覆盖：1) open-type 跳转——wx.navigateToMiniProgram/open-type 跳公众号、App、网页，验证跳转成功、目标正确、返回是否能回到小程序；2) App 唤起——小程序通过 wx.openBusinessView/wx.navigateToMiniProgram 唤起关联 App，验证 App 安装/未安装两种行为（未安装提示或跳下载）、唤醒后页面与数据、以及回跳到小程序；3) 网页授权——跳转 H5 网页时的 OAuth 授权、登录态传递，验证授权成功/失败、回跳参数（code、token）能否正确带回小程序；4) 回跳参数——从外部跳回时的参数还原（页面、参数、数据）与登录态。测试方法：真机验证各跳转链路、构造授权回跳参数、验证登录态与页面还原。需覆盖环境差异（开发者工具 vs 真机、不同宿主）与异常（未安装、授权失败、参数缺失）。

跳转交互的核心是"跳转-回跳-参数还原"。回答要体现 open-type、App 唤起、网页授权与回跳参数处理，并覆盖异常分支。

• 平台审核条款与类目资质
• 隐私协议与敏感权限
• 提审前检查清单

小程序提审前需预检合规项：1) 审核条款——平台审核规范（微信/支付宝）要求的功能可用、内容合规、无诱导分享、无违规支付；2) 类目资质——小程序选择类目需匹配资质（如电商需营业执照、医疗需资质），类目与功能不符会被拒；3) 隐私协议——需有隐私政策并说明数据收集，授权（手机号、定位）需在需要时申请并说明用途；4) 敏感权限——涉及敏感权限（位置、摄像头、通讯录）需合理、最小化，且在不支持时降级；5) 提审前检查——功能完整性、审核账号可用（测试账号、可登录）、无灰度残留、无违规内容。预检方法：建立提审 checklist、扫描代码中的敏感 API 与权限、真机验证审核环境（体验版+审核账号）、核对类目与资质。被拒常见原因：类目不符、隐私缺失、功能不可用、诱导行为，需针对性预检。提审前预检纳入发布流程，减少打回。

提审预检是"合规前置"。回答要体现审核条款、类目资质、隐私权限的预检与 checklist，并覆盖被拒常见原因。

• iOS/Android 宿主差异
• 不同微信/宿主版本差异
• 低端机与弱网下的行为

小程序兼容性测试需覆盖：1) iOS/Android 宿主差异——渲染引擎（iOS 用 WKWebView、Android 用 XWeb/kernel）、字体、键盘、浏览器行为差异，需两端分别验证；2) 微信版本差异——小程序依赖微信宿主，不同微信版本（含极端老旧版本）基础库与 API 能力不同，需验证核心功能在主流及老旧微信用版本的兼容与降级；3) 低端机——低内存/低性能设备上首屏渲染、滚动、内存、卡顿表现，避免低端机崩溃或卡死；4) 弱网——首屏加载、分包下载、接口请求在弱网下是否超时、失败重试、降级提示。测试方法：真机矩阵（iOS/Android、多微信版本、多档位机型）、云真机平台扩大覆盖、弱网工具模拟。兼容性矩阵按宿主×微信版本×机型分层，重点覆盖主流组合与长尾。兼容差异是"一次开发多端异常"的高发点，需系统性验证。

小程序兼容性是多维度（宿主/微信版本/机型/网络）的交叉。回答要体现各维度差异与基于矩阵的分层验证。

• miniprogram-automator 的能力与局限
• 三方框架（如 Appium、自研）的对比
• 自动化稳定性（等待、元素定位）

小程序自动化方案主要有：1) miniprogram-automator——微信官方小程序自动化工具，可模拟用户操作小程序、获取页面结构、调用小程序 API，能力包括元素操作、页面跳转、事件触发，但需配合开发者工具运行、网络切换与真实设备覆盖有限、对部分系统行为（弹窗、授权）处理弱；2) 三方框架——Appium 理论上可驱动宿主（微信），但定位小程序内部元素/页面困难；自研/基于 miniprogram-automator 封装更贴合小程序。能力边界：miniprogram-automator 能操作小程序页面，但无法直接处理宿主级弹窗（如微信授权、扫码）、真机预览与多端覆盖有限；稳定性：依赖元素定位（可加 ID/data-testid）、显式等待、以及页面加载同步。选型：以 miniprogram-automator 为基础封装，用于核心业务流回归；结合体验版/真机冒烟；对宿主级交互用人工或辅助。稳定性要点：等待小程序页面就绪、元素唯一标识、避免硬编码等待。

小程序自动化处于"官方工具 + 有限覆盖"的阶段。回答要体现 miniprogram-automator 的能力与局限、三方对比、稳定性与选型。

• JS Bridge 调用与返回值
• URL Scheme 与 Universal Link 的唤起
• 返回值异常（超时、失败、数据格式）处理

H5 与原生交互测试需覆盖：1) JS Bridge 调用——H5 调用原生能力（登录、支付、分享、相机）的参数传递、回调返回值、成功/失败/超时处理，以及 Bridge 注入时机与方法注册；2) URL Scheme——H5 通过 scheme 唤起原生 App 或跳转，验证 scheme 注册、参数、在 App 内外环境的行为；3) Universal Link——H5 通过 https 链接唤起 App，验证关联域名配置、唤起时机、未安装时的兜底；4) 返回值异常——Bridge 返回异常（超时、失败、数据格式错误、未注册方法）时 H5 是否有兜底提示而非报错；5) 安全——Bridge 参数校验、防注入、防伪造。测试方法：混合自动化（Appium 切 context）操作 H5 与原生、Charles 拦截 Bridge 请求、构造异常返回值验证降级。交互一致性需覆盖 iOS/Android 两端。H5 与原生交互是混合应用的核心风险点，需重点验证异常与安全。

H5 与原生交互的核心是"调用链路 + 异常处理 + 安全"。回答要覆盖 Bridge、scheme、Universal Link 与返回值异常兜底。

• RN/Flutter 的渲染与跨端一致性
• 原生模块桥接（Bridge/MethodChannel）的测试
• 热更新（CodePush/热更新）的测试

跨端应用（RN/Flutter）测试需关注：1) 渲染一致性——同一套代码在 iOS/Android 渲染的布局、样式、字体、滚轮差异，需用视觉回归与双端对比验证；2) 原生模块桥接——RN 的 Bridge（NativeModules）、Flutter 的 MethodChannel 调用原生能力的参数、返回值、异常处理，验证跨端调用原生功能（相机、支付、推送）的正确性；3) 热更新——RN 的 CodePush、Flutter 的 patch 热更新，验证更新包下发、版本兼容、更新失败回滚、不破坏现有功能；4) 跨端差异——性能（JS 引擎/渲染线程）、平台 API 差异、iOS/Android 特有行为。测试方法：双端自动化（Detox/Flutter 集成测试）+ 视觉回归对比双端渲染、Mock 原生模块验证桥接、热更新专项验证包与回滚。跨端应用的核心是"一次开发多端一致"，需在双端均验证渲染、桥接与更新。

跨端测试的核心是"双端一致性 + 桥接 + 热更新"。回答要体现渲染对比、原生桥接、热更新回滚与跨端差异专项。

• 静默登录（wx.login 换取 code→token）
• token 过期与自动刷新
• 多端互踢（多设备登录）

小程序登录态测试需设计：1) 静默登录——wx.login 获取 code 换取 openid/token，验证登录成功、token 生成与存储、无需用户交互的静默登录流程；2) token 过期刷新——token 过期后接口返回 401，客户端自动刷新 token 并重放请求，验证刷新成功、重放正确、刷新失败时引导重新登录；3) 多端互踢——同一账号在多端登录时的互踢或会话管理，验证被踢后旧端会话失效、提示、数据隔离；4) 冷启动恢复——关闭小程序后重新打开，登录态是否保留（token 有效期内免登录）、过期后是否重新登录。用例设计：覆盖 token 有效/过期/刷新失败、多端并发、冷启动不同容器、网络异常下的登录态。测试方法：构造 token 过期、Mock 登录接口、多端并发、冷启动验证，结合自动化覆盖登录态分支。登录态是会话安全核心，需重点验证刷新与互踢。

登录态测试的核心是"token 生命周期 + 多端会话"。回答要体现静默登录、过期刷新、多端互踢与冷启动恢复，突出安全与一致性。

• 订阅消息授权（一次性/长期）
• 多次/多次触发订阅
• 拒绝后的引导

小程序订阅消息测试需覆盖：1) 订阅授权——wx.requestSubscribeMessage 申请订阅，分一次性订阅与长期订阅，验证授权弹窗、同意/拒绝、授权次数限制；2) 多次触发——同一用户多次订阅同一模板的授权叠加、每次授权确认次数、超限后的处理；3) 拒绝后引导——用户拒绝订阅后，业务是否降级（不推送）、是否有引导（设置页开启/再次申请）；4) 模板消息触达——订阅成功后，模板消息（订单、提醒）能否正确下发、点击跳转到对应页面、参数与数据正确；5) 边界——订阅授权次数用尽、模板失效、用户取消授权。测试方法：真机触发订阅授权、构造订阅与触达场景、验证多次订阅与拒绝引导、点击模板验证跳转。订阅消息是触达手段，需验证授权与触达闭环，避免过度骚扰或漏发。

订阅消息测试的核心是"授权-触达-引导"闭环。回答要体现一次性/长期订阅、多次触发、拒绝引导与模板触达跳转。

• 多端视觉回归（截图对比）
• 设计规范校验（颜色、间距、字体）
• 跨端渲染差异处理

跨端 UI 一致性测试需落地：1) 多端视觉回归——对 iOS/Android（及小程序/H5）各自截图，与基线对比（Applitools/Percy/自研），发现双端渲染差异与回归；2) 设计规范校验——用代码/配置校验颜色、间距、字体、圆角等是否符合设计规范（如主题 token、设计变量），避免两端样式漂移；3) 跨端渲染差异处理——不同字体渲染、屏幕 DPI、布局引擎差异导致的像素差异，需设置忽略区域与容差，建多端基线；4) 工具——视觉回归平台提供基线管理、智能忽略、跨端对比。落地要点：统一设计 token（颜色/间距/字体）作为双端一致的基础，用视觉回归做保障，关键页面双端对比；处理动画/时间导致的误报。视觉回归与设计规范结合，能有效防止"一次开发两端不一致"。

跨端 UI 一致性的关键在"设计 token 统一 + 视觉回归双端对比"。回答要体现多端截图对比、设计规范校验与差异处理。

• JS 引擎与渲染线程性能
• 内存占用与启动耗时
• 跨端（RN/Flutter/原生）的分端度量

跨端应用性能测试需分端度量：1) JS 引擎——RN 的 JS 执行耗时、JS 线程阻塞、Flutter 的 Dart 执行，用 Profile/DevTools 度量 JS/Dart 线程的耗时与卡顿；2) 渲染线程——RN 的 UI 线程、Flutter 的渲染线程（rasterizer）的帧率与掉帧，用滚动/动画场景测帧耗时；3) 内存占用——JS 堆、原生内存、Flutter 的 Dart 堆与原生内存，用 Instruments/Perfetto/DevTools 度量，观察泄漏；4) 启动耗时——冷启动分阶段（JS bundle 加载、首帧渲染、可交互），RN 关注 bundle 加载、Flutter 关注引擎启动，需分端对比。度量方法：各端用对应工具（RN 用 React Native 性能监控/Perfetto、Flutter 用 DevTools/Flutter Performance、原生用系统工具），建立分端性能基线并回归。跨端性能差异在于 JS/渲染架构不同，需分别定位瓶颈（如 RN 的桥接开销、Flutter 的栅格化）。

跨端性能的核心是"分端（JS/渲染/内存/启动）度量与定位"。回答要体现各引擎与线程的度量工具、指标与基线。

• 小程序灰度发布策略
• 版本回退
• 崩溃监控与投诉反馈

小程序灰度发布与监控需形成闭环：1) 灰度发布——平台支持版本灰度（按比例/按用户），分阶段放量，观察核心指标；2) 版本回退——灰度或全量后发现问题，能快速回退到上一稳定版本，验证回退后功能正常、无数据残留；3) 崩溃监控——监控小程序崩溃率、JS 错误、页面异常，实时告警，按版本/基础库/机型分级；4) 投诉反馈——收集用户投诉与反馈（客服、评价、反馈入口），与监控数据关联，识别版本问题；5) 闭环——监控/投诉发现问题→定位（堆栈、日志、版本）→修复→灰度验证→回退或全量→回归监控。测试侧配合：发布前预检、灰度期监控指标、问题快速定位与回退预案。依托小程序平台的数据统计与监控能力，将"灰度-监控-回退-投诉"串联，形成版本质量闭环。

小程序发布闭环的核心是"灰度-监控-回退-投诉"联动。回答要体现灰度放量、快速回退、崩溃监控与投诉反馈的闭环处理。

• 跨端状态管理的机制（Redux/Provider/桥接）
• 登录态、购物车等状态的同步
• 跨端与原生模块的状态一致性

跨端状态管理一致性测试需验证：1) 状态机制——RN 的 Redux/MobX、Flutter 的 Provider/Bloc 管理全局状态，验证状态树正确、派发/更新一致；2) 登录态同步——跨端登录态（token、用户信息）在 RN/Flutter 与原生模块之间同步，如原生登录后跨端状态更新、退出登录后各端状态清空；3) 购物车等业务状态——购物车、收藏、设置等状态在页面切换、跨端调用原生（如支付后更新购物车）时保持一致，不漂移；4) 跨端与原生模块状态一致性——原生模块（如推送、支付）回调后，跨端状态是否同步更新；5) 异常——状态更新失败、并发修改、冷启动恢复时状态一致性。测试方法：跨端自动化操作触发状态变更，验证 UI 与状态同步；Mock 原生模块回调验证状态更新；验证登录/登出/购物车在多端一致。状态一致性是跨端应用的常见 bug 源，需重点验证同步与漂移。

跨端状态一致性的核心是"状态树到 UI 的同步 + 跨端模块联动"。回答要体现状态机制、登录态/购物车同步与异常处理。