3、传统兼容测试流程：手动测试、测试矩阵的构建与维护
聊兼容测试，咱们得先看看“传统玩法”是什么样的。
不是所有团队一开始就能上自动化、上 CI/CD。大部分项目，尤其是早期或资源有限的时候，兼容测试基本都是手动测的。这个流程，说白了就是“人肉矩阵”的玩法。
我个人习惯把这个阶段叫做“石器时代”。不是说它不好，而是它有明显的天花板。
3.1 手动测试：最原始，也最直接
手动测试兼容性，场景通常是什么样的？
- 开发说“这个版本 ok 了，测一下兼容性吧”。
- 测试同学拿着一张清单，打开一堆设备，开始点点点。
- 发现布局乱了，截个图，记个 bug，丢给开发。
- 开发改完，再测一遍。
嗯，听起来很简单。但我在项目中遇到过这样的情况：一个功能，在 10 台设备上手动跑一遍，就要花掉整整一个下午。如果中间发现了一个严重问题，整个流程就得重来。
手动测试的核心痛点：
- 耗时极长：一次完整的兼容回归，可能需要几天甚至几周。
- 极易遗漏：人总会累，总会看漏。有些偶发性的 UI 错位，手动测的时候不一定能每次都触发。
- 难以复现：“唉？我刚才明明看到它闪了一下，现在怎么没了？”——这种话我听过太多次了。
- 结果不可靠：不同测试人员的操作习惯不同，主观判断标准也不一样。
你想想看，如果一个 Bug 只在 Android 10、6寸屏幕、深色模式 下出现，手动测试能保证每次都覆盖到这个组合吗？很难。
我曾经就因为这，被一个只在“某品牌某型号的暗光环境下”才出现的字体渲染问题坑过一次。那一次，排查了整整两天。
3.2 测试矩阵：把“混乱”变成“清单”
为了解决手动测试的“无序”问题，聪明的前辈们发明了——测试矩阵。
说白了，就是把所有要测的环境变量组合起来，列成一个表格。你对着表格打勾，测完一个划掉一个。
一个典型的兼容测试矩阵长什么样？
| 设备/操作系统 | 浏览器版本 | 屏幕分辨率 | 核心功能A | 核心功能B | UI 布局 |
|---|---|---|---|---|---|
| iPhone 14 / iOS 16 | Safari 16 | 2532x1170 | ✅ | ✅ | ✅ |
| Pixel 7 / Android 13 | Chrome 110 | 2400x1080 | ✅ | ❌ | ⚠️ |
| iPad Pro / iPadOS 16 | Safari 16 | 2732x2048 | ✅ | ✅ | ✅ |
| Redmi Note 11 / Android 12 | MIUI 浏览器 | 2400x1080 | ✅ | ✅ | ❌ ( 底部按钮被遮挡 ) |
矩阵的好处很明显：
- 可追踪：哪个设备、哪个版本、哪个功能，测没测过，一目了然。
- 易规划：老板问“这版本兼容性怎么样？”，你直接甩一个矩阵过去就行。
- 标准化：新人来了，照着矩阵测，不会跑偏。
我的建议：构建矩阵时，别贪多。你先抓住“TOP 20%”的设备和浏览器。比如，你们的用户画像里，iPhone 14 的用户占 30%，那就必须测它。千万别想着“把全世界的设备都覆盖了”，那是做不到的。
3.3 构建测试矩阵：你该考虑哪些维度？
构建矩阵不是瞎列。我个人习惯从这 5 个核心维度入手：
- 操作系统及版本： 这是最基础的。Android 10/11/12/13/14、iOS 15/16/17、Windows 10/11、macOS Ventura/Sonoma……
- 浏览器及核心版本： Chrome、Safari、Firefox、Edge，还有那些“套壳浏览器”，比如微信内置浏览器、QQ 浏览器、UC 浏览器。
- 屏幕尺寸与分辨率： 小屏手机（5.5寸以下）、常规屏（6寸左右）、大屏手机/平板（7寸以上）、带鱼屏显示器（21:9）。
- 硬件性能： 低端机（2GB RAM）、中端机（4-6GB RAM）、高端机（8GB+）。老设备跑新功能，卡顿是常态。
- 系统特性设置： 深色模式、字体大小（特大字体）、无障碍模式（TalkBack/旁白）、语言（从右到左如阿拉伯语）。
你可能会问：“维度这么多，我该选哪些组合？”
答案很简单：看你的用户数据。从后台拉一下用户设备分布，按占比从高到低排，前 80% 的设备就是你矩阵里的“必修课”。
3.4 维护测试矩阵：一场永无止境的战斗
矩阵建好了，是不是就完事了？天真。
兼容测试矩阵最大的坑，不是构建，而是维护。
我曾经... 就踩过这个坑：一个大版本上线前，我们拿着三个月前建的矩阵去测。结果发现，矩阵里有 3 款设备已经停产，系统版本也升级了两轮。最关键的是，用户数据告诉我们，新用户的主力机型根本不是当初列的那几款。这意味着，我们耗尽人力测了一堆“废组合”。
从那以后，我定了一条规矩：测试矩阵必须每两个 Sprint 更新一次，且与线上用户数据对齐。
维护矩阵你需要注意哪些事？
- 定期清理“僵尸设备”： 如果某款设备在过去一个季度里，用户占比低于 0.5%，并且没有重大项目依赖，果断砍掉。
- 及时补充新热点： 比如新发布的 iPhone 15、某款爆火的折叠屏手机、最新的 Chrome 版本。这些要马上加进去。
- 关联 Bug 库： 矩阵里的每一项，最好都能关联到对应设备上的已知 Bug。这样下次再测，你能快速知道“这设备有没有历史遗留问题”。
说回手动测试，它虽然原始，但不可替代。尤其是那些需要主观判断的测试，比如“这个动画流畅吗？”“这个字体看起来舒服吗？”“这个交互手势符合直觉吗？”——这些，机器很难帮你判断。
但问题在于，传统的手动测试 + 矩阵维护模式，效率太低了。它只适合小项目、低频发布的场景。一旦你的迭代节奏加快到每周甚至每天发布，这种模式根本跑不动。
这也引出了我们为什么要做兼容测试的自动化，以及为什么要把它们集成到 CI/CD 里。传统流程是“地基”，但想盖高楼，你得找新的工具和方法。
本章核心回顾：
- 传统手动测试的瓶颈：耗时、易遗漏、难复现。
- 测试矩阵是解决“测什么”的利器，但需要结构化设计。
- 矩阵的 5 大维度：OS、浏览器、分辨率、硬件、系统设置。
- 维护矩阵比构建矩阵更重要，需定时与用户数据对齐。