Netlify deploy previews 上的视觉测试是指自动执行视觉对比——将 Netlify 部署的预览站点（为每个 pull request 或分支生成）与生产环境参考进行比较，以便在合并之前检测任何显示回归，利用唯一的预览 URL 作为测试表面。
Netlify 是 deploy preview 的先驱之一。早在这一功能成为行业标准之前，Netlify 就已经为每个 pull request 提供了预览 URL。这已经成为工作流程中如此自然的一部分，以至于大多数团队已经无法想象没有它的工作方式。
然而，这些团队中的绝大多数只是将 deploy previews 作为简单的查看工具。部署、快速看一眼、合并。这就像只看前方开车——你看到了要去的方向，但看不到身后留下了什么。
**我们的立场：没有自动化视觉测试的 Netlify deploy previews 就像没有后视镜的驾驶。**你面前有道路（功能正常运行），但你完全看不到你的更改在网站其他部分造成的潜在损害。你寄希望于什么都没变。希望不是质量策略。
目录
- Netlify Deploy Previews：未充分利用的潜力
- 手动验证的真实成本
- 如何在 Deploy Previews 上自动化视觉测试
- 通过 Webhook 或通知触发
- 在 Netlify Preview URL 上捕获
- 与生产环境或参考基准比较
- 集成到 Pull Request 的报告
- Netlify 在视觉测试方面的独特优势
- 视觉测试挽救局面的场景
- Netlify 的 No-Code 方法
- 常见问题
- 结论
Netlify Deploy Previews：未充分利用的潜力
Netlify deploy previews 是一项出色的功能。每个 pull request、每个分支都会自动生成一个完整的站点，部署在类似 deploy-preview-42--your-site.netlify.app 的唯一 URL 上。
这不是本地开发服务器。这是完整的部署，在 Netlify 基础设施上，包含 CDN、重定向、headers、表单、serverless functions——一切。预览站点在功能上与生产环境完全一致。
Netlify 还通过预览专属功能更进一步。
**Deploy contexts。**Netlify 允许根据部署上下文（production、deploy-preview、branch-deploy）配置不同的行为。你的环境变量、重定向和 headers 可以在生产和预览之间有所不同。这很强大，但也是潜在的视觉差异来源，只有自动化测试才能检测到。
**部署通知。**Netlify 提供通知系统（webhooks、Slack、email），在每个部署阶段触发。视觉测试可以挂接到这些通知上，在预览准备好后自动启动。
**Deploy locking。**Netlify 允许锁定部署以防止自动更新。这对于在视觉测试运行时冻结参考版本非常有用。
所有这些功能都服务于流畅可靠的视觉测试工作流程。但今天，大多数团队只将它们用于手动查看。
手动验证的真实成本
让我们分析手动验证 deploy previews 的真实成本。
**时间成本。**假设一个项目有二十个关键页面，在两个视口（桌面和移动端）上测试。手动验证每个页面在每个视口上平均需要一分钟——这还是乐观估计。每个 PR 需要四十分钟的验证时间。在每天五个 PR 的项目中，每天超过三小时用于视觉验证。实际上没人这样做。检查两三个页面就继续了。
**可靠性成本。**手动验证受到疲劳、认知偏差和截止日期压力的影响。"明天发布吧，视觉审查看起来没问题，似乎是正确的。"这句话造成的生产环境视觉回归比所有 CSS bug 加起来还多。
**响应速度成本。**在生产环境中手动发现的视觉回归需要完整的修复周期：找到问题 commit、创建 hotfix、测试、部署。如果同样的回归在 deploy preview 上被自动检测到，它会在合并前、在正常开发流程中被修复。修复成本降低十倍。
**信任成本。**一个经常将视觉回归发布到生产环境的团队会失去用户、客户和管理层的信任。自动化视觉测试不仅仅是技术工具。它是声誉保护机制。
如何在 Deploy Previews 上自动化视觉测试
自动化遵循四步流程，每一步都利用 Netlify 的原生能力。
通过 Webhook 或通知触发
Netlify 允许配置在特定事件上触发的 webhooks：deploy started、deploy succeeded、deploy failed。"deploy succeeded"webhook 是我们感兴趣的。它表示预览已准备好且可访问。
Webhook payload 包含所有必要信息：deploy preview URL、分支名称、commit SHA、部署上下文。视觉测试服务接收此 webhook 并启动捕获会话。
Webhook 的替代方案是使用 Netlify API 轮询部署状态。但 webhook 更可取：它是事件驱动的、即时的，不会在主动等待中消耗资源。
在 Netlify Preview URL 上捕获
一旦收到 webhook，headless 浏览器会导航到 Netlify preview URL 上的每个配置页面。捕获遵循视觉测试的常规最佳实践。
**等待完全加载。**部署在 Netlify 上的站点通常使用异步提供资源的 CDN。必须等待所有资源（图片、字体、脚本）加载完毕后再捕获。
**稳定渲染。**禁用 CSS 动画，隐藏动态元素（时间戳、计数器、个性化内容），冻结轮播图和滑块。
**在多个视口捕获。**桌面、平板、移动端。部署在 Netlify 上的站点通常是 JAMstack 站点或具有响应式设计的静态应用。响应式回归频繁且影响重大。
**处理单页应用（SPA）。**如果你的站点是 SPA，页面间导航在客户端发生。Headless 浏览器必须模拟此导航并等待每个路由完全渲染后再捕获。
与生产环境或参考基准比较
Deploy preview 的截图与基准进行比较。有两种参考策略。
**与实时生产环境比较。**视觉测试同时捕获生产站点（your-site.netlify.app 或你的自定义域名）和 deploy preview，然后比较两组截图。优点是参考始终是最新的。缺点是有意的更改总是被标记为差异。
**与已验证的参考比较。**视觉测试将 deploy preview 截图与团队验证的参考捕获集进行比较。优点是只标记非预期的更改。缺点是在合并有意更改时需要更新参考。
实际上，第二种方法更适合活跃开发中的项目。第一种适用于维护模式的站点，其中每个视觉变化都必须被审查。
集成到 Pull Request 的报告
结果通过自动评论和状态检查报告在 pull request 中。
评论包含清晰的摘要：已验证的页面数、有差异的页面数、最显著差异的预览以及完整报告的链接。
状态检查（绿色或红色）决定是否可以合并。如果存在未批准的差异，合并将被阻止。开发人员必须审查差异、验证或修复，然后重新运行测试。
这个流程是自然的。它融入现有的工作节奏，不会增加显著的摩擦。
Netlify 在视觉测试方面的独特优势
Netlify 具有使其特别适合自动化视觉测试的特征。
Deploy preview 的稳定性
Netlify deploy previews 是不可变的。一旦部署，preview 不会改变——即使向分支推送了新 commit（而是创建新的 preview）。这种不可变性对视觉测试至关重要：你可以保证站点在捕获开始和结束之间不会发生变化。
CDN 和性能
Deploy previews 通过 Netlify CDN 提供服务，与生产环境完全相同。加载时间是真实的，图片经过优化，资源经过压缩。捕获的截图代表了实际的渲染效果。
表单和 serverless functions
Netlify 甚至在 deploy previews 中也处理表单和 serverless functions。如果你的站点有联系表单或由 function 驱动的购物车，它们在预览中也能正常工作。视觉测试捕获的是完整渲染，而不是降级版本。
Split testing（A/B testing）
Netlify 提供原生 split testing。如果你正在测试页面的两个变体，视觉测试可以捕获两个变体并将其与各自的参考进行比较。这是很少有视觉测试工作流程能达到的覆盖水平。
Headers 和重定向管理
Deploy previews 遵守在 netlify.toml 或 _headers 文件中定义的 headers 和重定向配置。这意味着视觉测试以与生产环境相同的缓存、CSP 和重定向规则捕获站点。
视觉测试挽救局面的场景
静态站点生成器更新
Gatsby、Hugo、Eleventy、Astro——每次框架的重大更新都可能以微妙的方式修改渲染。Markdown 解析器的变化、图像处理的更新、生成 HTML 的修改。Deploy preview 就在那里。视觉测试验证渲染是否一致。如果页面受到影响，你在合并更新之前就会知道。
CDN 或 Netlify 配置变更
修改 netlify.toml 配置（重定向、headers、构建命令）可能产生意想不到的视觉效果。配置错误的重定向可能提供错误的页面。过于严格的 CSP header 可能阻止 web 字体加载。视觉测试检测这些视觉后果。
非开发人员添加内容
如果你的站点使用通过构建 webhook 连接到 Netlify 的 headless CMS（Contentful、Sanity、Strapi），编辑者添加内容会触发新的构建和新的 deploy preview。视觉测试验证新内容是否正确显示、图片尺寸是否正确、文本是否没有溢出容器。
迁移到新的设计系统
用 Tailwind 替换 Bootstrap、从 CSS Modules 迁移到 styled-components、或采用新的 design system——这些迁移是视觉回归的雷区。每个 deploy preview 上的视觉测试将令人焦虑的迁移转变为可控的迁移，逐页面、逐组件进行。
外部贡献（open source）
如果你的站点是 open source 并接受外部贡献，deploy previews 结合视觉测试是不可或缺的保护层。外部贡献者可能引入无意的视觉变化。视觉测试自动标记它们，维护者无需手动检查每个页面。
Netlify 的 No-Code 方法
在 Netlify 上实现完整的视觉测试工作流程——webhooks、headless 浏览器、比较、报告——如果从零开始，工作量相当大。这正是像 Delta-QA 这样的 no-code 工具所消除的复杂性。
设置只需几个步骤。将你的 Netlify 站点连接到 Delta-QA。在可视化界面中选择要监控的页面。配置视口。Delta-QA 自动注册为你 Netlify 站点上的 webhook。
从那时起，每个 deploy preview 自动触发视觉测试会话。结果出现在你的 pull request 中。差异清晰且可操作。有意更改的批准只需一次点击。
**目标是让视觉测试像 deploy preview 本身一样无形和自动。**在 Netlify 上打开 PR 时你不会想到部署——它自动发生。视觉测试应该以同样的方式工作。不需要维护脚本。不需要调整配置。只有结果，在每个 PR 上，自动地。
常见问题
Netlify deploy previews 对视觉测试工具是否可访问？
默认情况下是的。Netlify deploy previews 通过其唯一 URL 公开访问。但是，如果你启用了密码保护（Netlify 设置中的 Site protection），视觉测试工具将需要进行身份验证。使用 Delta-QA，你只需配置一次凭据，每次捕获时身份验证自动处理。
Netlify 可以同时存在多少个 deploy previews？
Netlify 不限制活跃 deploy previews 的数量。每个 PR 和每个分支都会生成自己的预览。这对视觉测试来说是有利的，因为这意味着每个更改都可以独立测试。但是，如果你有很多打开的 PR，请确保你的视觉测试工具能正确处理并发捕获会话。
视觉测试是否适用于使用 serverless functions 的 Netlify 站点？
是的。Serverless functions（Netlify Functions）在 deploy previews 中是活跃的。如果你的站点使用 functions 进行动态渲染、API 或个性化，deploy preview 反映这种行为。视觉测试捕获用户所见的最终结果，包括 functions 生成的内容。
如何处理 deploy contexts 之间的差异（production vs deploy-preview）？
如果你的 netlify.toml 为 deploy-preview 上下文定义了不同的环境变量或配置，预览渲染可能与生产略有不同。例如，"Preview"横幅或禁用的分析。配置你的视觉测试工具以隐藏这些预期的差异，或为 deploy-preview 上下文创建特定的参考。
视觉测试能否检测与 Netlify 表单相关的问题？
视觉测试检测表单显示问题：位置不正确的字段、不可见的按钮、与 input 重叠的标签。但是，它不测试表单的功能行为（提交、服务端验证）。为此，需要补充功能测试。视觉测试和功能测试是两个独立且互补的层。
除了 deploy previews 外，能否在 branch deploys 上使用视觉测试？
当然可以。Netlify 区分 deploy previews（关联到 PR）和 branch deploys（关联到没有 PR 的分支）。视觉测试可以在两者上运行。Branch deploys 对于长期分支（develop、staging）特别有用，这些分支不一定与 pull requests 关联。通过视觉监控来检测累积的偏差。
结论
Netlify deploy previews 是太多团队浪费的礼物。你免费拥有每次修改在合并前的完整且可访问的部署。这是通向你网站未来的一扇敞开的窗户。而大多数时候，没有人系统性地从这扇窗户向外看。
自动化视觉测试将这扇窗户变成了哨兵。每个 deploy preview 被捕获、比较、分析。回归在到达生产环境之前被标记。有意的更改被记录和批准。你网站的视觉历史自动构建。
没有后视镜开车意味着靠运气不出事故。没有视觉测试的部署意味着靠运气不破坏网站外观。两种情况下，运气总会用完。
像 Delta-QA 这样的工具让安装这面后视镜变得简单。几分钟的配置，每个 Netlify deploy preview 就会自动进行视觉验证。你的网站受到保护。你的用户看到他们应该看到的内容。你可以放心地合并。
是时候安装那面后视镜了。