Scrum 工作流中的视觉测试是指在 Sprint 的每个阶段——从开发到 Sprint Review——系统性地集成自动化用户界面检查，通过将截图与经过验证的参考进行对比来验证界面显示。
直说吧：大多数 Scrum 团队不进行视觉测试。他们有单元测试、集成测试，有时还有端到端测试。他们有 Product Owner 在 27 英寸显示器上的 Sprint Review 中验证 User Story。然后他们将视觉回归发布到生产环境——没人发现，因为没人去找。
这不是能力问题，是流程问题。视觉测试在 Scrum 工作流中没有明确的位置。它既不在验收标准中，也不在 Definition of Done 中，也不在各项仪式中。它漂浮在方法论的无主之地上，卡在"那是开发的事"和"QA 会处理的"之间。
结果：没人处理。当视觉 Bug 到达生产环境时，每个人都想知道它是怎么漏过去的。
本指南提出将视觉测试具体集成到 Sprint 的每个阶段。没有抽象理论，只有精确的行动、明确的责任划分和一个坚定的信念："视觉测试通过"必须出现在你的 Definition of Done 中。
为什么 Scrum 存在视觉盲区
Scrum 是一个以迭代方式交付价值的极其有效的框架。但它设计于一个用户界面不那么复杂、不那么动态、对用户最终质量感知不那么关键的时代。
Sprint 以功能为中心，而非外观
当你编写 User Story 时，你描述的是行为："作为一个用户，我希望按日期筛选结果。"验收标准聚焦于功能：筛选器有效、结果正确、边界情况已处理。
没人写："筛选器必须在移动端正确显示，不能偏移相邻内容，必须遵循设计系统，不能破坏侧边栏布局。"这是隐含的。而隐含的东西不会被测试。
Sprint Review 是一个视觉陷阱
Sprint Review 本应是团队展示已完成工作、Product Owner 验收的时刻。理论上，这是发现视觉问题的好时机。
实际上，这是检测视觉问题最糟糕的时刻。
演示发生在特定的环境、浏览器和分辨率上。PO 观看的是功能流程，而非视觉细节。团队展示的是能正常工作的部分，而不是他们没有触碰但可能受到副作用影响的页面。
Sprint Review 是一个功能过滤器，而非视觉过滤器。指望它来检测视觉回归，就像指望机场安检来检查你的行李质量。
经典自动化测试看不到用户看到的东西
你的 Cypress 或 Playwright 测试验证的是元素存在于 DOM 中且交互正常。它们不验证按钮是否可见、文字是否与图片重叠，或者 CSS 变量的变更是否在十个组件中传播了非预期的效果。
单元测试验证逻辑。集成测试验证连接。端到端测试验证路径。没有一个验证用户看到的东西。
何时进行视觉测试：视觉 Shift-Left
Shift-left 的概念——在开发生命周期中尽可能早地进行测试——完美适用于视觉测试。但"尽可能早"并不意味着"随便什么时候"。
开发期间：第一道防线
检测视觉回归的理想时机是当开发者还在修改上下文中时。他了解自己触碰的代码，知道哪些组件受到影响，可以立即修复。
视觉测试应该在每次推送到开发分支时自动触发。不是三天后的合并时间。不是 Sprint Review，当开发者已经转到其他任务时。就是现在，当他在写代码的时候。
具体来说，这意味着将视觉测试集成到你的 CI/CD 流水线中，使其在每个 pull request 或 merge request 上执行。开发者推送代码，视觉测试将分支的截图与已验证的参考进行比较，结果直接显示在 merge request 中。
如果检测到视觉差异，开发者会立即看到。他可以验证（这是有意的变更）或修复（这是回归）。修复成本接近于零，因为他仍在上下文中。
合并到主分支时：安全网
即使每个分支都有测试，合并到主分支仍可能产生视觉回归。两个各自正确的分支合并后可能产生不正确的视觉结果。
视觉测试也必须在每次合并到主分支后运行。这是你的安全网。如果一个回归通过了分支测试但在合并时出现，它在到达 staging 或生产环境之前就被检测到。
Sprint Review 之前：最终检查
Sprint Review 不应该是你发现视觉问题的时候。它应该是你确认一切就绪的时候。
在每次 Sprint Review 之前，在演示环境上运行完整的视觉测试套件。如果检测到差异，团队在 Review 之前处理它们。Product Owner 看到的是一个视觉上已验证的产品，而非草稿。
谁来执行视觉测试：明确的责任划分
大多数 Scrum 团队不做视觉测试的原因之一是没有人知道这该谁负责。我们来澄清。
开发者：第一责任人
开发者对他交付的质量负责。这包括视觉质量。当开发者完成一个 User Story 时，他必须确保自己的修改没有引入视觉回归。
通过将无代码视觉测试工具集成到流水线中，这项责任不需要额外的精力。测试自动运行。开发者在 merge request 中查看结果。如果有有意的视觉差异，他更新参考。如果是回归，他修复。
开发者不需要编写手动视觉测试或编写场景脚本。工具会处理这些。他的责任是查看结果并采取行动。
QA：流程守护者
QA 不是执行视觉测试的人——自动化会处理这些。QA 是确保流程正常运作的人。
他的角色是配置和维护视觉测试套件：测试哪些页面、哪些分辨率、哪些浏览器。他定义容差阈值（多大的视觉差异百分比是可接受的）。他分析模糊情况——检测到的视觉差异是真正的回归还是由动态内容引起的误报？
QA 是视觉测试策略的守护者，而非执行者。
Product Owner：最终验证者
Product Owner 在视觉测试中经常被低估的角色。他知道产品应该是什么样子。他有用户体验的愿景。他能判断一个视觉变更是否可接受。
当视觉测试检测到有意的变更时——组件重新设计、品牌指南变更——Product Owner 必须验证新的渲染是否符合他的期望。现代视觉测试工具通过简单的界面支持这种验证：PO 看到变更前后的对比，然后批准或拒绝。
这个工作流给了 Product Owner 以前从未有过的可见性。他不是在 Sprint Review 中（或更糟，在生产环境中）发现视觉变更，而是在 Sprint 过程中看到它们，以清晰可用的格式。
Definition of Done 中的视觉测试：我们的立场
Definition of Done（DoD）是你的 Scrum 团队的质量契约。它是 User Story 必须满足才能被视为完成的标准列表。如果一个标准不在 DoD 中，它就是可选的。而可选的东西会被遗忘。
为什么"视觉测试通过"必须出现在 DoD 中
问问自己：你会接受交付一个单元测试未通过的 User Story 吗？不会。你会接受交付一个破坏首页显示的 User Story 吗？也不会。那么为什么第二个标准不在你的 DoD 中？
Definition of Done 中的"视觉测试通过"意味着每个交付的 User Story 都经过了自动化的视觉验证。 不存在未验证的视觉回归。每个检测到的视觉差异要么已修复（是回归），要么已批准（是有意的变更）。
这是一个二元的、可衡量的、可自动化的标准。它不依赖于 Sprint Review 中匆忙的人类主观判断。它基于像素的客观比较。
如何在 DoD 中表述该标准
以下是我们推荐的措辞：
"视觉测试通过：在 User Story 影响的页面和组件上未检测到未批准的视觉回归。"
这个措辞很重要，原因有三。它明确了"未批准"，意味着有意的视觉变更是可接受的，前提是已经过明确验证。它明确了"受影响的页面和组件"，意味着测试不限于直接修改的页面，还包括可能受到副作用影响的页面。而且它是可衡量的：要么存在未批准的回归，要么不存在。
常见反对意见（以及为什么它们站不住脚）
"这会拖慢我们的 Sprint。" 不会。自动化视觉测试在 CI/CD 流水线中与你的其他测试并行运行。它不增加额外的仪式、会议或手动流程。拖慢你 Sprint 的是在生产环境中发现的视觉 Bug，它们需要紧急热修复。
"我们没有相关技能。" 像 Delta-QA 这样的无代码视觉测试工具不需要任何编程技能。你定义要测试的页面、目标分辨率，工具完成剩下的工作。如果你的团队会使用浏览器，就能使用无代码视觉测试工具。
"我们的设计师已经在验证渲染了。" 你的设计师验证的是初始渲染。他们不会在每次代码变更后审查每一个页面。自动化视觉测试在每次变更、所有已配置页面上持续检查。没有任何人能达到这种覆盖率。
"我们有太多误报。" 误报确实是一个问题，但它是配置问题，而非根本问题。动态内容（日期、广告、实时数据）必须在测试环境中被遮罩或稳定化。一个配置良好的工具产生的误报率低于 5%。
逐 Sprint 集成：完整工作流
以下是视觉测试如何具体集成到 Sprint 的各项仪式和活动中。
Sprint Planning
在 Sprint Planning 期间，当团队将 User Story 分解为任务时，识别视觉上受影响的页面和组件。这种识别不需要显著努力——它是技术分析的自然延伸。
如果一个 User Story 修改了导航组件，团队会注明所有使用该组件的页面都必须纳入视觉测试范围。此信息记录在 User Story 中。
日常开发
在开发过程中，视觉测试在每次推送时自动运行。开发者在 merge request 中查看结果。在每日站会中，如果有值得讨论的视觉差异（需要 PO 验证的有意变更，或需要帮助的复杂回归），开发者会提及它们。
视觉测试不创建新的工作流。它嵌入到现有的 merge request 和代码审查工作流中。
Sprint Review
Sprint Review 变得更加顺畅，因为视觉问题已经在 Sprint 期间被处理了。Product Owner 已经通过视觉测试工具验证了有意的视觉变更。演示是一个确认，而非发现。
管理有意的视觉变更
并非每个视觉变更都是回归。组件重新设计、设计系统中的颜色变更、新的页面布局——这些都是视觉测试会检测到的有意变更。
关键在于快速区分有意变更和无意的回归。现代视觉测试工具通过并排展示参考图像和新截图、清晰高亮差异来促进这种区分。
工作流很简单。视觉测试检测到变更。开发者或 QA 检查差异。如果有意，更新参考（新截图成为后续测试的参考）。如果是回归，修复代码。
在 Scrum 环境中，重大有意变更（页面重新设计、品牌指南变更）的验证应涉及 Product Owner。次要变更（间距调整、User Story 预期元素的添加）可以由开发者或 QA 验证。
明天从哪里开始
如果视觉测试尚未集成到你的 Scrum 工作流中，以下是如何在下一个 Sprint 中开始的方法。
步骤 1：提议加入 DoD。 在你的下次回顾会上，提议将"视觉测试通过"加入 Definition of Done。解释原因，分享本文，讨论实施方式。
步骤 2：配置无代码视觉测试工具。 选择一个集成到你的 CI/CD 流水线且不需要脚本的工具。例如 Delta-QA，允许在几分钟内配置视觉测试套件，无需一行代码。
步骤 3：从小处开始。 不要在第一个 Sprint 就测试所有页面。从五个最关键的页面开始（首页、产品页、转化漏斗、登录页、dashboard）。逐步添加其他页面。
步骤 4：迭代配置。 调整容差阈值以减少误报。遮罩动态内容。优化测试分辨率。像 Scrum 中的一切一样，视觉测试策略通过迭代改进。
步骤 5：测量并分享结果。 在两到三个 Sprint 后，汇总指标。检测到多少视觉回归？有多少本会到达生产环境？节省了多少时间？这些数字会自己说话。
常见问题
视觉测试能替代 Scrum 中的端到端测试吗？
不能。视觉测试和端到端测试是互补的。端到端测试验证功能路径是否正常工作（点击按钮触发正确的操作）。视觉测试验证界面是否正确显示（按钮可见、定位正确、可读）。两者都需要。
视觉测试为 Sprint 增加多少时间？
自动化视觉测试不会为 Sprint 增加显著时间。执行在 CI/CD 流水线中与其他测试并行进行。唯一的人工时间是审查检测到的差异，每个 merge request 只需几分钟。相反，通过避免生产环境中的视觉 Bug 节省的时间是可观的。
Scrum 中的视觉测试需要专职 QA 吗？
不需要。专职 QA 是加分项，但不是必需的。使用无代码工具，任何技术团队成员都可以处理初始配置。结果的日常审查是 merge request 流程的一部分，由开发者处理。QA 负责策略、阈值和复杂情况。
如何在不拖慢 Sprint 的情况下管理误报？
误报通过配置管理，而非人工努力。遮罩动态内容区域（日期、计数器、广告）。稳定测试数据。调整容差阈值以忽略微小的渲染差异（例如字体抗锯齿）。一个配置良好的工具产生的误报率低于 5%。
Product Owner 需要验证每一个检测到的视觉差异吗？
不需要。只有重大的视觉变更才需要 PO 验证：页面重新设计、主要组件变更、品牌指南修改。次要调整（间距、User Story 预期元素的添加）由开发者或 QA 验证。明确定义哪些需要上报给 PO，哪些由技术团队处理。
视觉测试适用于一周的短 Sprint 吗？
完全适用。短 Sprint 使视觉测试更加重要。手动测试的时间更少，视觉测试自动化变得不可或缺。Shift-left 在短 Sprint 中尤为关键：你无法承受在一周的 Sprint 最后一天发现视觉 Bug。
延伸阅读
没有视觉测试的 Definition of Done 是不完整的。视觉回归就是 Bug——和所有 Bug 一样，它们必须在到达生产环境之前被检测到。