可重现环境：每次执行时完全相同的软件配置——相同的操作系统、相同的库、相同的字体、相同的渲染引擎——确保测试结果不因运行机器的不同而变化。——自动化测试工程的基本原则。
你已经搭建了视觉回归测试。你在比较截图。测试在本地通过了。但当它们在 CI 上运行时，你得到 47 个标记差异——没有一个对应真正的 bug。
这个场景是做视觉回归测试的绝大多数团队都经历过的。而大多数团队得出了错误的结论："视觉回归测试噪音太多，不靠谱。"
视觉回归测试运行得很好。不好用的是你的环境。
在 macOS 上用 Apple 字体拍的截图永远不会与在 Ubuntu 上用 FreeType 字体拍的截图像素级相同。在 1920x1080 分辨率、100% 缩放下运行的浏览器与在 1920x1080 分辨率、125% 缩放下运行的浏览器不会产生相同的渲染。抗锯齿、字体微调、子像素平滑——一切都不同。
Docker 解决了这个问题。如果你在不使用 Docker 的情况下做视觉回归测试，你就是在浪费时间。
为什么截图在不同机器间有差异
字体渲染：头号元凶
字体渲染是截图之间差异的首要来源。每个操作系统使用自己的字体渲染引擎。macOS 使用 Core Text，优先保证对字体设计的忠实度。Windows 使用 DirectWrite，优先保证像素网格对齐。Linux 使用 FreeType，其行为取决于 fontconfig 配置。
结果就是：相同的文本、相同的字体、相同的大小、相同的页面，在不同操作系统上不会产生相同的像素。差异有时肉眼不可见——一个像素的偏移、略微不同的平滑度。但像素级比较工具能检测到它们并将它们标记为回归。
而且这还不是全部。可用字体因系统而异。如果你的 CSS 指定了一个未安装在 CI 机器上的字体，浏览器会使用回退字体。这种替换可能改变字距、行高、字符宽度——从而改变整个布局。
浏览器渲染引擎
即使使用相同的浏览器（例如 Chrome），渲染引擎的确切版本也会影响结果。Chrome 120 与 Chrome 122 对某些 CSS 属性的渲染不完全相同。
分辨率和缩放
你的显示器 DPI 影响渲染。Retina 屏幕（2x）产生的截图分辨率与标准屏幕（1x）不同。CI 服务器通常没有物理屏幕。它们使用虚拟帧缓冲区（Linux 上的 Xvfb），其 DPI 配置可能与你的开发工作站不同。
Docker：每次都是相同的环境
Docker 通过将整个测试环境封装在容器中来解决这些问题。相同的操作系统、相同的字体、相同的浏览器、相同的版本、相同的渲染配置——无论容器运行在你的 macOS 工作站、GitHub Actions Linux runner 还是 EC2 实例上。
容器必须包含什么
用于视觉回归测试的 Docker 容器必须包括：你的应用使用的所有字体（本地安装，而非即时下载）、固定版本的浏览器、显式的渲染配置（fontconfig、虚拟帧缓冲区 DPI、抗锯齿设置）、无头浏览器所需的系统依赖。
基础镜像：不要重新发明轮子
Playwright 的官方镜像包含了锁定版本的浏览器和依赖。从一个可用的镜像开始。添加你的字体和特定配置。除非有充分理由，否则不要从头构建。
Dockerfile 作为活文档
你的 Dockerfile 是测试环境的全面、可执行的描述。当新团队成员加入时，他们不需要猜测要安装哪些字体或使用哪个 Chrome 版本。他们启动容器，获得与所有人相同的环境。
Docker 化你的视觉回归测试设置：关键步骤
步骤 1：固定版本
列出参与页面渲染的所有内容。将每个都固定到精确版本。不用"latest"，不用语义化范围。在视觉回归测试中，"随便什么都行"等同于"误报"。
步骤 2：构建镜像
从包含固定版本浏览器的基础镜像开始。添加字体、fontconfig 配置和必要的工具。按变更频率从低到高排列指令（操作系统、浏览器、字体 → 应用代码、测试文件），以优化构建缓存。
步骤 3：验证可重现性
构建镜像。运行视觉回归测试。再次构建。再次运行。结果必须完全相同。在两台不同机器上验证。
步骤 4：集成到 CI/CD 流水线
将镜像推送到注册表并在 CI 配置中引用。更新镜像时，重新生成基线截图。
步骤 5：管理更新
建立每月更新节奏。更新 Dockerfile 中的浏览器版本，重新构建，重新运行测试，检查差异，为预期变化更新基线。
超越可重现性的好处
并行化
Docker 容器在几秒内启动。启动 10 个、20 个、50 个容器并行运行，同时测试多个页面。顺序执行需要 30 分钟的测试，并行执行只需 3 分钟。
测试隔离
每个容器从干净状态启动。没有持久的浏览器缓存，没有残留的 cookie。每个测试都在全新环境中开始，消除了一整类误报。
Delta-QA 在这个方案中的定位
Delta-QA 大大简化了 Docker 方程式。它的结构分析本质上对环境间的渲染差异不太敏感。像素级比较工具会因为字体渲染标记每个子像素差异，而 Delta-QA 分析计算后的 CSS 属性——margin、padding、尺寸、定位——这些无论渲染环境如何都相同。
这不意味着使用 Delta-QA 就不需要 Docker。可重现环境仍然是最佳实践。但对环境差异的容忍度不可同日而语。对于无法或不愿投资构建专用 Docker 镜像的团队来说，这是一个决定性优势。Delta-QA 即使在不完美的环境中也能提供可靠的结果。
常见错误
使用"latest"作为镜像标签
这是 Docker 环境中测试不稳定的首要原因。固定精确版本并可控地更新。
忘记安装字体
如果你的应用使用 Inter、Roboto 和自定义字体，在容器中安装它们。不要依赖从 Google Fonts 即时下载。
忽略视口大小
1920x1080 的虚拟屏幕不等于 1920x1080 的视口。在你的视觉回归测试工具中显式配置视口。
不对镜像进行版本管理
将镜像推送到注册表，用哈希或日期标记，并在 CI 流水线中引用确切的标签。
常见问题
Docker 是视觉回归测试的必须项吗？
不是，但没有 Docker（或等效的可重现环境机制），你会花大量时间管理因机器间渲染差异导致的误报。
推荐哪个基础 Docker 镜像？
Playwright 的官方镜像（mcr.microsoft.com/playwright）是一个绝佳的起点。
Docker 会减慢视觉回归测试吗？
容器启动增加几秒。作为回报，Docker 实现大规模并行化，通常总体时间更优。
如何在 Docker 容器中处理 Google Fonts？
下载字体文件并通过 Dockerfile 在容器中本地安装。不要依赖从 Google 服务器即时下载。
Docker Desktop 可以用于本地视觉回归测试吗？
可以，在开发期间推荐这样做。你在开发工作站上运行与 CI 相同的容器。
Delta-QA 需要 Docker 才能工作吗？
不需要。Delta-QA 凭借其结构分析方法无需 Docker 即可工作，该方法本质上对渲染差异不太敏感。Docker 仍然是最大可重现性的最佳实践，但不是 Delta-QA 获得可靠结果的前提条件。
延伸阅读
从一台机器到另一台机器会变化的截图不是测试。是噪音。Docker 将你的截图转化为可靠、可重现的证据。