测试环境搭建：虚拟机、模拟器、真机、云真机池与 Docker
做兼容测试这么多年，我最怕听到的一句话就是：「这功能在我机器上没问题啊。」你想想看，问题往往就出在环境不一样。环境搭不对，后面的测试全是白费力气。今天我就把这四种主流方案——虚拟机、模拟器、真机、云真机池，以及 Docker 怎么用，一次给你理清楚。
环境方案的对比：谁该上场？
先上一张表，把四种方案的核心差异列出来。我习惯把这个表贴在工位上，每次选方案前瞄一眼，基本不会跑偏。
| 方案 | 真实度 | 成本 | 并发能力 | 自动化友好度 | 适合场景 |
|---|---|---|---|---|---|
| 虚拟机 | ⭐⭐⭐（半虚拟化） | 低（一台宿主机可跑多台） | 中（受宿主机资源限制） | 高（SSH/Agent 可控） | 桌面浏览器兼容、旧 OS 环境 |
| 模拟器 | ⭐⭐（模拟指令集） | 低（免费） | 高（单机可开多个实例） | 中（需 ADB / HAXM 配合） | 移动端功能测试、快速回归 |
| 真机 | ⭐⭐⭐⭐⭐ | 高（设备采购+维护） | 低（物理连接有限） | 中（依赖 USB/WiFi 连接稳定性） | 关键用户路径、硬件相关测试 |
| 云真机池 | ⭐⭐⭐⭐（远端真机） | 中（按需付费） | 极高（多租户海量设备） | 高（平台 API 原生态支持） | 大规模并行兼容测试、碎片覆盖 |
虚拟机配置：别让你的宿主机「爆炸」
虚拟机是桌面兼容测试的老牌选手。我个人的习惯是：每台虚拟机分配 2 核 CPU + 4GB 内存，磁盘用动态分配。别贪心，一次性给太多资源，反而会让宿主机 IO 争抢严重。
举个例子：测 Windows 7 + Chrome 88 的组合，你只需要一个最基本的 Windows 7 镜像，装好指定浏览器，其他服务能关就关。我见过有人把 VS Studio、SQL Server 全塞进虚拟机里，结果启动一次要 10 分钟——这不叫环境，叫「包袱」。
避坑指南：我曾经在 VMware 里装 macOS 做 Safari 测试，折腾了两天没跑起来。后来才知道， macOS 的 EULA 协议限制非 Apple 硬件上运行，性能也差得一塌糊涂。真机或者云真机池才是正解。
模拟器调优：快≠稳
模拟器的优势是快。开一个 Android 模拟器实例，带上 x86 镜像和 HAXM 加速，十几秒就启动了。但你注意，模拟器默认的 RAM 只有 256MB。我建议至少拉到 1GB，否则跑稍微复杂一点的 App，直接卡死给你看。
还有个坑：模拟器的 GPS 定位、电量、网络信号强度都是「捏造」的。我曾经用模拟器测了一个页面加载策略，以为很快，结果在真机上发现因为弱信号网络，页面白屏了 3 秒。所以模拟器适合做功能回归，不适合做性能或网络条件测试。
真机采购与维护：成本的大头
真机没啥取巧的——一台设备就是一个独立的测试环境。我的建议是：优先覆盖 Top 10 市占率机型，然后根据你的用户画像补长尾型号。记得留两到三台「钉子户」设备（比如还跑着 Android 6 的低端机），很多线上问题就是在这些老爷机上爆出来的。
说到真机维护，最常见的问题是 USB 连接不稳定。我早期做 iOS 测试，每天都要拔插 USB 线，后来换了 Mac + 雷电口扩展坞，才消停点。如果你团队超过 5 人，真机池还是得上云方案。
云真机池：解放双手的利器
云真机池说白了就是把你本地的真机资源搬到云端，按需分配。主流平台都提供 REST API，直接集成到 CI 流水线里。我当前项目每天跑 200+ 次兼容测试，靠云真机池，一次能并行跑 30 台设备，半小时出全量报告。
不过云真机也有坑：网络延时。远程设备和你脚本之间的 ADB 连接可能慢 1-2 秒，所以超时时间要设得宽松一点。我曾经遇到过因为默认超时 5 秒，云设备回传截图慢了 200ms，整条用例被判 fail……后来把超时改成 10 秒，问题解决。
Docker 在兼容测试中的应用：轻量、可复现
Docker 并不是替代上面四种方案的，它是用来「打包环境」的。你想想看，如果有 10 个测试人员，每个人本地的 Node 版本、Chrome 驱动版本都不一样，那么同样的测试脚本，跑出来的结果可能完全不一样。
Docker 的做法很简单：把测试环境写成 Dockerfile，里面固定好 OS、浏览器版本、驱动程序、测试框架。然后每个人只要 docker run，就获得一模一样的沙箱环境。
举个例子，我要测 Chrome 90 和 Firefox 88 的兼容性，可以这样写 Docker 编排：
# docker-compose.yml
version: '3'
services:
chrome90:
image: selenium/node-chrome:90.0
environment:
- SE_EVENT_BUS_HOST=selenium-hub
firefox88:
image: selenium/node-firefox:88.0
environment:
- SE_EVENT_BUS_HOST=selenium-hub
selenium-hub:
image: selenium/hub:3.141
跑起来之后，测试代码连上这个 hub，就能同时往两个浏览器发指令。我在项目中用过这套，把环境准备时间从 15 分钟缩短到 30 秒，而且再也没有「我这边能过你那边报错」的扯皮了。
一张图看懂环境搭建决策
下面这张 SVG 总结了我刚才说的所有逻辑。每次开始一个新兼容测试项目，我都会照着这个流程图走一遍，基本不会漏掉关键考虑点。
小结
环境搭建没有银弹。虚拟机、模拟器、真机、云真机池、Docker 各有各的适用边界。我的经验是：先搞清楚你的测试目标，再选方案，不要一上来就买一堆真机或者全上云。用对了工具，兼容测试的效率能翻倍；用错了，光环境调试就能浪费一整天。嗯，记住上方那个流程图，基本够用了。