约 7 分钟5 张卡

兼容性测试

兼容性测试检查产品在承诺支持的平台、配置及协作版本中，是否仍能完成规定行为。一个页面在开发者电脑上能提交，不代表在支持的浏览器、触屏设备和另一种语言中都能正常使用。

兼容性准备先要回答“支持哪些条件”，再决定怎样选择组合和判断结果。单纯列出设备名称，无法说明覆盖范围；要求运行所有可能组合，也会让测试失去可执行的边界。

1. 面试核心

先记住这几条，再读正文

兼容性范围来自产品承诺、用户分布和变更风险，需要明确支持、有限支持与不支持的条件。卡 · 支持范围与测试矩阵
测试矩阵要保留重要组合，再按机制差异和交互风险选代表项；成对覆盖不能保证所有高阶组合都正确。卡 · 组合选择与风险
模拟视口、触摸和语言有助于快速检查页面，但不能证明真实设备的系统、输入法和硬件行为。卡 · 模拟配置与真实设备
多语言检查需要已确认的目标文本与展示规则，不能把所有英文都判为漏翻译，也不能只检查字符串是否存在。卡 · 多语言与地区设置
版本兼容要明确谁生产、谁消费数据，以及新旧版本如何共存；代码能回退不等于数据也能回退。卡 · 升级、共存与回退

2. 支持范围与测试矩阵

卡 · 兼容性测试需要考虑哪些维度，范围怎样确定？

兼容性矩阵将需要支持的条件及其组合写成可执行范围。每个维度都应能解释它可能改变什么行为。

维度	示例	需要关注的差异
浏览器与引擎	承诺支持的浏览器及版本范围	API、布局、存储、媒体能力
操作系统与设备	桌面、手机、平板及系统版本	权限、系统控件、输入与资源限制
屏幕与输入	窄屏、横屏、缩放、键盘和触摸	遮挡、截断、焦点、悬停依赖
语言与地区	文本语言、数字日期格式、时区	文案长度、排序、方向、时间边界
应用与协议版本	旧客户端、新服务端、迁移前后数据	字段含义、默认值、废弃能力
外部组件	数据库或 SDK 的支持版本	接口行为、序列化和部署约束

支持范围不是从工具的设备列表直接复制而来。工具能启动某个配置，不代表产品承诺支持它；产品承诺支持的真实设备，也不一定能被工具完整模拟。

每一行测试还要有结果依据。例如“窄屏兼容”应进一步说明主要按钮是否可见可达、正文是否被截断、表单是否可操作、放大后是否仍可完成任务。只拍一张页面截图不能覆盖完整行为。

对于已停止支持的平台，应记录产品预期：明确阻止、提示升级，还是允许使用但不保证全部能力。不要把所有失败都直接归为兼容性缺陷。

3. 组合选择与风险

卡 · 组合数量太多时，怎样减少兼容性测试用例？

全量组合很快会膨胀。假设有 3 类浏览器、3 个屏幕范围、2 种输入方式和 4 种语言，就有 3 × 3 × 2 × 4 = 72 种组合；其中还可能存在无法运行的组合。

可以按以下顺序缩小范围：

删除产品不支持或现实中不存在的组合，保留删除依据。
明确必须运行的关键组合，例如主要用户环境、支持范围边缘和此次变更直接影响的平台。
按不同执行机制选代表配置，避免只因为名称不同就重复相同覆盖。
对其余维度使用组合测试，补足所需交互覆盖。
保留已知缺陷触发条件和高风险业务组合，不让它们被优化过程删掉。

例如页面改动只涉及窄屏浮层，除了主要浏览器，还应明确检查“窄屏、触摸、较长文案”共同出现的情况。即使两两组合都覆盖，这三个条件一起出现时仍可能让确认按钮落在不可操作区域。

矩阵还需跟随产品变化更新。新版本增加 API、用户分布变化或曾经漏测的问题，都可能改变代表项。报告应说明实际执行了哪些组合及哪些未覆盖，不能只给“兼容性通过”四个字。

4. 模拟配置与真实设备

卡 · 浏览器模拟手机通过后，为什么还需要真实设备测试？

浏览器工具可以设置视口、设备像素比、用户代理、触摸、语言和时区等参数。它适合快速检查响应式布局和依赖这些配置的页面分支。

但修改用户代理不会把桌面操作系统变成手机系统，缩小视口也不会产生真实设备的 CPU、内存、键盘、权限弹窗和图形驱动。模拟条件通过，只能支持对应模拟范围内的结论。

因此可以先用模拟矩阵进行较广的自动化检查，再在关键真实设备上补充系统交互、输入法、手势和性能等证据。移动应用生命周期、权限及平台控件需要按具体平台机制设计，不能从 Web 页面测试结果直接推断。

失败定位同样要保留实际条件：浏览器与系统版本、设备型号、方向、缩放、输入方式、语言和时区。仅说“手机上失败”不足以重建问题。浏览器操作与追踪方式见 Web UI 自动化测试。

5. 多语言与地区设置

卡 · 已提供标准译文时，怎样自动检查手机页面的多语言显示？

多语言测试既检查内容是否正确，也检查内容变化后能否使用。英语、中文、较长译文和从右到左书写的语言，可能对长度、换行、方向和控件排列提出不同要求。

如果已经提供标准文本，可以把资源标识、目标语言和预期译文建立对应关系，再按页面状态提取实际文案进行核对。动态用户名、金额和日期应按规则分别比较，不应把整页所有文本拼成一个字符串后直接判等。

检查对象	可判定的规则
固定文案	对应资源和语言下与批准文本一致
动态占位符	必要值出现且位置、转义和数量正确
回退文案	缺少翻译时按规定回退，并可追踪未覆盖项
布局	文案变长后没有遮挡关键操作或丢失必要信息
地区格式	数字、货币、日期和时区符合明确约定
文字方向	段落和控件按目标语言规则呈现，混合内容仍可识别

“发现英文就判定漏翻译”并不可靠：品牌名、代码和产品明确保留的术语可能本来就应该使用英文。缺陷依据应来自资源映射、允许列表和目标语言规则，而不是某种字符是否出现。

语言、地区和时区也不是同一个条件。用户可以使用中文界面、查看另一时区的订单时间；文本语言声明也不自动把数字和日期转换成正确格式。测试矩阵需要分别定义相关设置及组合。

6. 升级、共存与回退

卡 · 新版本能够上线，是否说明它也能够安全回退？

版本兼容首先要说清方向。例如新服务端能接受旧客户端请求，和旧客户端能理解新服务端响应，是两个独立判断。口头说“向后兼容”容易遗漏生产方、消费方和实际数据方向，应直接列出组合。

组合	主要验证
旧客户端 → 新服务端	旧字段、默认值和业务语义是否仍成立
新服务端 → 旧客户端	新响应是否破坏旧解析与展示
新旧实例共同运行	共享数据、消息及配置是否都能被正确处理
旧数据 → 新版本	迁移、读取、约束及缺失字段处理
新版本写入后回退	旧代码是否还能读取数据，是否需要独立恢复方案

增加一个可选字段有时能够兼容旧调用方，但不能仅凭“可选”下结论。严格拒绝未知字段的旧解析器、改变含义的默认值或新增枚举值，都可能使原流程失败。

回退尤其需要检查已经产生的副作用。应用镜像可以切回旧版本，但已删除的列、已经转换的数据和已发送的消息不会随代码自动恢复。验证时应包含升级前数据、升级后写入、版本共存及回退后的读写行为，并明确无法无损回退的条件。