设计稿视觉回归验收：从截图差异定位真实布局问题

设计稿视觉回归验收要回答的是“这次改动是否破坏了原本正确的页面”，而不是“新截图和旧截图是否每个像素都相同”。可靠的基线必须同时固定页面、状态、视口、字体和数据；比较结果还要区分动态内容、可接受的响应式变化、字体加载差异和真正的布局回归。只有把这些变量写清，设计、开发和测试才会共享同一份证据。

先选定回归基线

基线不是随手截的一张首页图，而是带有页面路径、用户状态、组件状态和数据快照的记录。登录页要注明未登录或已登录，列表页要注明有数据、空数据和错误，弹窗要注明打开方式。Playwright 的视觉比较文档将截图基线、差异阈值和环境稳定性放在一起讨论，设计团队可以借此建立自己的最小基线集合。

在 组件规格与开发验收的尺寸标注之外，再记录基线生成时间、字体版本、浏览器、视口和数据来源。不要把“当前线上截图”当成永远正确的设计依据；确认基线本身经过评审后，再允许后续版本更新。可以给每条基线一个可定位的名称，如 orders-empty__390x844__zh-CN__v3，记录页面为订单列表、状态为空、视口为 390×844、语言为 zh-CN、数据版本为 v3。对应截图的浏览器版本、操作系统和字体随记录保存；名称相同但环境不同，仍然不能直接作为同一组基线比较。

固定视口、字体和数据

同一页面在 375、768 和 1440 宽度下可能有不同布局，回归集合应覆盖产品真正支持的断点，而不是只测一个桌面宽度。字体加载失败会改变字宽和换行，真实数据中的长标题、极大数字和多行错误也会暴露平时看不到的问题。测试数据要有版本或快照标识，避免每次截图内容都在变化。

响应式断点应结合 响应式网格断点的设计规则定义，不能从单张截图反推所有设备。CSS Media Queries 规范适合核对媒体条件语义，实际支持的设备范围仍由产品和研发共同确认。

订单按钮错位，先排除字体和数据差异

截图差异可以先分为四类：数据变化、字体/渲染变化、响应式预期变化、布局或交互回归。数据变化通常不应阻塞样式判断，但要确认数据容器没有溢出；字体差异要追查加载和字形；断点变化要判断是否落在设计约定范围；布局回归则记录元素位移、裁切、重叠和焦点可见性。

阈值不是越小越好。过于严格会把抗锯齿、阴影和系统渲染差异都变成噪声，过于宽松又会漏掉按钮错位和文字被裁切。先按区域定义检查重点：文本和按钮关注位置与可读性，照片和渐变允许一定像素差，表格和导航则要求结构稳定。

沿用订单列表的 390×844 空状态：如果新版标题换成了长文案，先换回同一份数据再比较；如果按钮和标题都变宽，先确认字体是否加载；若数据与字体一致，只有右侧“筛选”按钮越过容器边界，就记录为该状态的布局问题。修复目标是让按钮和焦点环完整可见，而不是让整张截图的差异百分比变成零。

真实数据比占位符更能发现问题

视觉回归至少准备四种数据：正常长度、最长标题、空列表和错误/权限状态。对表格加入长用户名、极大金额、负数和缺失值，对卡片加入多行描述和无图片状态。占位符只证明骨架能显示，不能证明真实任务不会溢出。

无障碍回归也要包含在同一批证据中。可以用 WCAG 视觉检查复核对比度、焦点环、错误提示和文字缩放，避免只比较颜色像素而漏掉用户无法读取或操作的变化。

把差异写成可修复的问题

在 设计评审问题闭环中继续记录负责人、修复版本和复验结果。这个订单页面可以建立问题 VR-017：390×844、空列表、字体已加载时，筛选按钮右边缘超出容器。把设计基线、研发提供的实现截图和修复目标并排放在 Pixso 画布中，在被裁切的位置标出同一问题编号；评审意见就能落到明确的控件边界。

需要整理手头的验收稿时，可以在 Pixso 中建立这组三状态画板。设计稿保存应有的边界，测试截图保留实际运行结果，修复后再以相同环境复验。

基线更新也要有理由和回滚点

当设计或产品确认了有意改版，旧截图不能直接被新截图覆盖。先在记录中写明改变了什么、影响哪些页面和状态、为什么这次变化符合需求，再生成新的基线。保留旧基线和变更编号，便于后续回归出现问题时回滚或比较。对于只改文案、图标或数据的提交，可以单独更新相关状态，避免整套页面基线一起失去历史。

如果差异来自字体、浏览器或渲染环境，先修正测试环境再决定是否更新基线。将环境变更和产品变更分开记录，能减少“为了让测试通过而更新截图”的误操作。对视觉阈值的调整也要附上具体区域和原因，不能把全局阈值调大来掩盖单个组件的问题。

让设计状态、实现版本和问题编号对得上

设计师提供页面、状态、视口和字体假设，开发提供实现版本和可复现路径，测试提供基线、当前截图和差异区域。三方记录应使用同一编号，问题描述要落到元素、位置、状态和影响上。例如“375px 的筛选按钮在错误状态下被裁切，无法聚焦”，比“移动端样式有问题”更容易修复和复验。

如果差异是预期的，应补一条可验证的理由和对应设计状态；如果差异是回归，应说明修复后必须重新覆盖哪些视口和数据。Pixso 可作为设计基线和状态画板的协作入口，最终截图、测试结果和发布版本仍要留在团队已有的验证记录中。这样做能把视觉回归从一次性的审美争论，变成可重复的工程流程。

不要让自动截图替代人的判断

视觉比较工具擅长找出位置和像素变化，却不知道变化是否符合需求。一个经过确认的文案换行可能是预期，按钮移到屏幕外则是回归；自动化只能把差异标出来，最终仍需要设计、开发或测试判断。审查时先看影响任务的结构差异，再看阴影、抗锯齿和细微颜色差异，避免把时间耗在低价值噪声上。

对于有动画、时间或随机内容的页面，要在截图前冻结时间、关闭动画或等待稳定状态。头像、广告和实时消息不能直接混入基线，否则差异会持续变化。若无法冻结，应把这类区域排除在像素比较之外，同时增加布局和可见性检查，确保排除区域没有溢出或遮挡。

基线文件和设计稿也要互相链接。设计稿记录意图、状态和断点，截图记录实现结果和环境。两者之间出现差异时，先确认是不是同一版本、同一状态，再建立问题单。这样既避免测试拿错设计稿，也避免设计拿一张旧截图要求开发回退。

把回归结果转成下一轮基线

一次回归结束后，除了关闭问题，还要更新基线说明：哪些差异被接受、哪些差异被修复、哪些环境仍未覆盖。把接受原因写进记录，下一次审查就不会重复争论同一像素变化。对于暂时无法稳定截图的区域，记录排除原因和替代检查方式，等环境稳定后再纳入完整基线。

如果同一组件在多个页面反复出现差异，应上升为组件级问题，而不是逐页修改截图。关联对应的设计状态、实现版本和测试用例，修复后复验所有受影响页面。这样回归数据能反过来改善组件规范，也能帮助产品发现某个断点或字体组合长期不稳定。

回归用例还应覆盖断点临界位置。若布局约定在某个宽度切换，就在该宽度两侧各选一个相邻值，检查导航是否意外消失或重复显示、列数是否突变、按钮是否被挤出。不要把设计稿中的三种宽度当成唯一可用宽度。对滚动容器，再加入首屏、中间位置和底部状态，确认固定操作栏不会覆盖最后一行。验收这些边界时仍使用稳定的数据和字体，发现问题后补到基线集合中，让这类错位进入下一轮回归检查。

参考资料

• Playwright Test：Visual comparisons，用于截图基线和差异比较。
• W3C CSS Media Queries Level 5，用于响应式媒体条件语义。
• W3C CSS Fonts Level 4，用于字体加载和字形差异边界。