可重现环境：每次执行时完全相同的软件配置——相同的操作系统、相同的库、相同的字体、相同的渲染引擎——确保测试结果不因运行机器的不同而变化。——自动化测试工程的基本原则。
你已经搭建了视觉回归测试。你在比较截图。测试在本地通过了。但当它们在 CI 上运行时，你得到 47 个标记差异——没有一个对应真正的 bug。
这个场景是做视觉回归测试的绝大多数团队都经历过的。而大多数团队得出了错误的结论："视觉回归测试噪音太多，不靠谱。"
视觉回归测试运行得很好。不好用的是你的环境。
在 macOS 上用 Apple 字体拍的截图永远不会与在 Ubuntu 上用 FreeType 字体拍的截图像素级相同。在 1920x1080 分辨率、100% 缩放下运行的浏览器与在 1920x1080 分辨率、125% 缩放下运行的浏览器不会产生相同的渲染。抗锯齿、字体微调、子像素平滑——一切都不同。
Docker 解决了这个问题。如果你在不使用 Docker 的情况下做视觉回归测试，你就是在浪费时间。
CI 上标记出 47 个差异，却没有一个是真正的 bug？ 用 Delta-QA，你可以在本地、在自己的机器上捕获并比对渲染结果，无需依赖远程服务，也无需注册。免费使用 Delta-QA →
为什么截图在不同机器间有差异
字体渲染：头号元凶
字体渲染是截图之间差异的首要来源。每个操作系统使用自己的字体渲染引擎。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 镜像？ Delta-QA 的引擎以人类感知为基准校准，即使在不完美的环境中也能在本地、无需注册地为你提供可靠的结果。免费使用 Delta-QA →
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 区分真实回归与渲染噪声，超越单纯的逐像素对比——只标记人眼会注意到的差异，无论渲染环境如何。
这不意味着使用 Delta-QA 就不需要 Docker。可重现环境仍然是最佳实践。但对环境差异的容忍度不可同日而语。对于无法或不愿投资构建专用 Docker 镜像的团队来说，这是一个决定性优势。Delta-QA 即使在不完美的环境中也能提供可靠的结果。
常见错误
使用"latest"作为镜像标签
这是 Docker 环境中测试不稳定的首要原因。固定精确版本并可控地更新。
忘记安装字体
如果你的应用使用 Inter、Roboto 和自定义字体，在容器中安装它们。不要依赖从 Google Fonts 即时下载。
忽略视口大小
1920x1080 的虚拟屏幕不等于 1920x1080 的视口。在你的视觉回归测试工具中显式配置视口。
不对镜像进行版本管理
将镜像推送到注册表，用哈希或日期标记，并在 CI 流水线中引用确切的标签。
准备好告别"在我机器上能跑，CI 上却挂了"了吗？ 用 Delta-QA 启动你的第一次比对，即使没有完美的环境也能获得可靠的结果，免费且无需注册。免费使用 Delta-QA →
常见问题
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 获得可靠结果的前提条件。