视觉测试中的 Baseline 管理：决定成败的最佳实践
Baseline（视觉测试）：在某个时间点捕获的界面参考图像或参考状态，被视为预期标准。此后的每次捕获都会与此 baseline 进行比较，以检测视觉回归——即外观的非预期变化。
坦白说：大多数放弃视觉测试工具的团队，并不是因为工具不好。而是因为他们的 baseline 管理做得太差。
Baseline 是所有视觉回归测试系统的核心。没有 baseline，就无法进行比较。管理不善的 baseline 会让每次测试都产生误报，每次更新都变成噩梦，团队最终会选择忽略警报——这等同于完全没有测试。
这不是一个令人兴奋的话题。没有人会在技术大会上做关于 baseline 管理的演讲。但这恰恰是区分"从视觉测试中获得真正价值的团队"和"试了就放弃的团队"的关键所在。
本文为扎实的 baseline 管理奠定基础。没有抽象理论——只有具体实践、最常见的错误，以及帮助你决定何时以及如何更新参考基准的决策框架。
目录
- 什么是 baseline，为什么它至关重要
- Baseline 的生命周期
- 最佳管理实践
- 扼杀采用的常见错误
- 何时以及如何更新 baseline
- Baseline 与团队工作流
- 常见问题
什么是 Baseline，为什么它至关重要
在视觉测试的语境中，baseline 是界面应该呈现样子的参考截图。它是你的事实基准（ground truth）。当你运行视觉测试时，工具会将页面的当前截图与此 baseline 进行比较。如果匹配，测试通过。如果不同，工具会标记潜在的回归。
这里的关键词是"潜在的"。并非每个差异都是 bug。有时差异是有意为之——你故意修改了某个组件。在这种情况下，baseline 必须更新以反映新的预期状态。
正是这一机制——与 baseline 比较、人工决策（是 bug 还是有意变更？）、必要时更新 baseline——构成了视觉测试的核心。而这一机制的质量决定了你的视觉测试工具是在帮助你还是在拖慢你。
**为什么至关重要：**过时的 baseline 会让每次测试都变成噪音。如果你的 baseline 不再匹配界面当前的预期状态，每次测试运行都会标记出并非 bug 的"差异"。团队学会忽略这些警报。而当真正的回归出现时，它会淹没在噪音中，被忽视。
这是经典的"狼来了"场景。也是团队放弃视觉测试工具的首要原因。
Baseline 的生命周期
Baseline 不是创建一次就忘记的静态产物。它有一个需要主动管理的生命周期。
初始创建
Baseline 在首次运行视觉测试时创建。工具捕获界面状态并将其存储为参考。这个时刻至关重要：初始 baseline 必须代表一个经过验证的界面状态。如果你在一个已经存在视觉 bug 的环境上捕获 baseline，这些 bug 就会变成标准，永远不会被检测到。
最佳实践：在稳定的环境上创建 baseline，经过人工验证视觉状态之后。不要在正在开发的环境上运行首次捕获。
持续比较
每次测试运行时，当前截图都会与 baseline 进行比较。工具生成差异报告，理想情况下包含每个检测到的变化的影响评分。这个报告就是决策点。
决策：Bug 还是有意变更？
这是许多团队草率处理的步骤。当视觉测试失败时，必须有人查看差异并做出决定：这是 bug（baseline 是正确的，新的渲染有误）还是有意变更（设计已演进，baseline 需要更新）？
这个决策必须是明确的、可追溯的，并且由合适的人做出。前端开发人员可以决定组件变更。设计师应该参与设计变更。QA 可以裁决模糊的情况。
Baseline 更新
如果变更是有意的，baseline 会用新的截图进行更新。这个更新必须被版本化、注释和审查——就像代码修改一样。
归档
旧的 baseline 不应该消失。它应该被归档，并附带历史记录，以便追溯界面随时间的演变。如果客户在三个月后报告了一个视觉 bug，你必须能够找到那个日期活跃的 baseline。
最佳管理实践
1. 将 baseline 与代码一起版本化
这是第一条规则，不可妥协。你的 baseline 必须和源代码存放在同一个仓库中，使用 Git（或你使用的任何 VCS）进行版本控制。
为什么？因为 baseline 与代码有内在关联。首页的 baseline 对应于该页面 HTML/CSS 代码的特定版本。如果你修改了代码，baseline 必须随之演进。如果它们没有一起版本化，就不可避免地会失去同步。
实际操作：将 baseline 存储在仓库的专用文件夹中，例如 /tests/visual/baselines/。当开发人员修改组件并更新对应的 baseline 时，两个更改在同一个 commit 中。审查者在同一个 merge request 中看到代码更改和 baseline 更改。
一些团队因为文件大小而犹豫是否在 Git 中版本化图像。这是个伪问题。Git LFS（Large File Storage）可以完美处理大型二进制文件。仓库大小不是牺牲 baseline 可追溯性的有效理由。
2. 每个上下文一个 baseline
同一页面可能因 viewport（桌面、平板、移动）、浏览器（Chrome、Firefox、Safari）、主题（亮色、暗色）或语言（FR、EN）而有不同的渲染。每个相关组合都应该有自己的 baseline。
诱惑是为了"覆盖一切"而增加组合。要克制。每个 baseline 都是一个维护承诺。10 个页面乘以 3 个 viewport 乘以 3 个浏览器就是 90 个 baseline 需要管理。加上 2 个主题和 2 种语言，就是 360 个。
瞄准对你的用户重要的组合。查看分析数据以确定主要的浏览器和分辨率。先测试这些组合。你随时可以扩展。
3. 智能命名你的 baseline
当你有数十或数百个 baseline 时，清晰的命名约定至关重要。名称应包含足够的信息，使人无需打开就能理解 baseline 代表什么。
好的格式：页面-viewport-浏览器-主题。例如：homepage-1920x1080-chrome-light 或 pricing-375x812-safari-dark。精确的格式不如一致性重要。
避免像 screenshot-1.png 或 test-baseline.png 这样的通用名称。三个月后，没人会知道它们代表什么。
4. 按分支分离 baseline
当你的团队同时在多个 feature 分支上工作时，每个分支可能修改不同的视觉组件。如果所有分支共享相同的 baseline，冲突是必然的。
正确的方法：每个 feature 分支可以修改其影响页面的 baseline。当分支合并到主分支时，更新的 baseline 随之合并。流程与代码管理相同。
Baseline 冲突（两个分支修改同一页面的 baseline）以与代码冲突相同的方式解决：有人必须查看并决定哪个版本正确——或在合并两个分支后重新捕获一个新的 baseline。
5. 将 baseline 审查纳入你的审查流程
Baseline 更新必须以与代码更改同样的严格程度进行审查。当开发人员更新 baseline 时，审查者必须验证视觉变化符合代码更改的意图。
实际操作中，merge request 应该并排显示旧的和新的 baseline。审查者检查：视觉变化是有意的吗？它与用户故事或工单匹配吗？修改区域之外是否有意外的视觉变化？
正是这个审查步骤将 baseline 更新从一个形式化动作转变为真正的质量控制。
扼杀采用的常见错误
从不更新的 baseline
这是最具破坏性的错误。界面在演进，但 baseline 保持不变。每次测试都产生差异。团队最终不加查看就将所有测试标记为"预期"。视觉测试不再检测任何东西——它变成了噪音。
原因通常是组织性的：没人负责更新 baseline。它不在工作流中，不在完成定义中，不在审查清单中。解决方案不是技术性的——而是流程问题。
在不稳定环境中捕获的 baseline
如果你的测试环境有动态元素——横幅、日期、广告内容、动画——你的 baseline 会包含这些可变元素。每次测试都会标记出并非回归的差异。
解决方案：稳定你的测试环境。使用固定数据（fixtures），禁用动态元素，屏蔽可变内容区域（将其排除在比较之外），并在可重复的条件下捕获 baseline。
太多 baseline
baseline 越多，维护工作越多。500 个涵盖所有可能组合的 baseline 在纸面上看起来很厉害。实际上，当设计改版涉及全局组件时，就是 500 个需要验证的 baseline。
从小处开始。20-30 个 baseline 覆盖你的关键页面和主要 viewport。当流程成熟后再添加更多覆盖。30 个管理良好的 baseline 胜过 500 个被忽视的。
团队冲突
当两个开发人员在修改相同页面的分支上工作时，baseline 在合并时会产生冲突。如果解决流程不明确，就会造成挫败感和时间浪费。
预防措施：沟通受影响的页面，在工单中使用标记或标签来标识视觉变更，并建立明确的 baseline 冲突解决规则（通常是：合并后重新捕获新的 baseline）。
混淆"接受"和"验证"
"接受"baseline 差异意味着"是的，我看到了差异，它是预期的"。许多团队不加查看就点击"接受"——尤其是当有很多差异需要处理时。这恰恰是你想避免的场景。每次接受都应该是一个有意识且可追溯的行为。
何时以及如何更新 Baseline
更新决策是视觉测试工作流中的关键时刻。这是一个清晰的决策框架。
在以下情况更新 baseline：
视觉变更是有意的——它对应一个工单、用户故事或文档化的设计决策。你可以解释为什么渲染发生了变化以及为什么新的渲染是正确的。
变更已被验证——设计师或 QA 已确认新的渲染符合预期。不应该仅由开发人员来判断新的渲染"看起来不错"。
变更已被记录——baseline 更新附带说明变更原因的注释。三个月后，某人必须能够理解为什么这个 baseline 在这个日期发生了变化。
在以下情况不要更新 baseline：
你不理解差异的原因。如果测试失败而你不知道原因，先调查。不要通过更新 baseline 来"修复"测试——你可能在掩盖一个真正的 bug。
变更看起来像是伪影。亚像素渲染差异、字体平滑差异、由于环境导致的细微变化——这些差异应该通过工具中的容差阈值来处理，而不是通过 baseline 更新。
时间压力迫使你"让测试通过"。这是更新 baseline 最糟糕的时机。在做决定之前，花时间理解差异。
Baseline 与团队工作流
Baseline 管理不能是某个人的责任。这是需要清晰工作流的团队协作。
推荐的工作流
在 sprint 开始时：确定将被视觉修改的页面和组件。准备好团队：这些页面的 baseline 需要更新。
在开发过程中：开发人员修改代码，必要时在同一个 commit 中更新对应的 baseline。这是需要养成的习惯，就像随代码编写单元测试一样。
在 merge request 时：审查者检查 baseline 变更。旧的和新的 baseline 进行视觉比较。审查者验证变更是否符合意图。
合并后：如果出现了 baseline 冲突，在主分支上执行新的重新捕获。新的 baseline 被提交并成为新的参考。
持续进行：自动化视觉测试将每个新截图与参考 baseline 进行比较。偏差立即被标记。真正的回归被修复。有意的变更触发 baseline 更新。
工具的角色
好的视觉测试工具不仅仅比较图像。它简化 baseline 管理：验证界面、修改历史、容差阈值管理、与 merge request 工作流的集成。
Delta-QA 秉持这一理念。作为 no-code 工具，它让视觉比较对整个团队都可用——不仅限于开发人员。设计师可以验证 baseline。产品负责人可以验证页面是否符合规格。QA 可以探索差异而无需理解代码。
这种可及性是采用的关键因素。如果只有开发人员能使用视觉测试工具，baseline 审查就完全落在他们身上。如果整个团队都能贡献，工作量就会分散，决策质量也会提高。
Baseline 与信任之间的联系
超越技术层面，baseline 管理从根本上是一个信任问题。
对测试的信任：当 baseline 保持更新且管理良好时，通过的测试确实意味着界面是合规的。失败的测试确实意味着有问题需要调查。没有误报干扰信号。
对部署的信任：当你的 CI/CD pipeline 包含使用可靠 baseline 的视觉测试时，你带着视觉回归已被检测到的保证进行部署。你不再祈祷什么都没坏。
对团队的信任：当 baseline 审查流程清晰且共享时，每个视觉变更都是一个有意识且经过验证的行为。不再有"肯定是有人没通知就改了"。
正是这种信任决定了视觉测试工具是长期被采用还是三个月后被放弃。而这种信任完全建立在 baseline 管理的质量之上。
常见问题
中型网站应该管理多少个 baseline？
对于 20-50 页的网站，从 10-15 个最关键的页面（首页、转化页面、高流量页面）开始，使用 2-3 个 viewport（至少桌面和移动端）。这会产生 20-45 个 baseline。这是一个可管理的数量，提供有意义的覆盖。当流程成熟后可以逐步增加。
Baseline 应该存储在 Git 还是外部服务中？
存在 Git 中，大文件使用 Git LFS。原因是：可追溯性。你的 baseline 必须与其对应的代码一起版本化。外部服务会在代码和其 baseline 之间造成不同步，这是 baseline 过时的主要来源。
如何处理动态内容造成的误报？
三种互补方法：首先，用固定数据（fixtures）稳定测试环境。其次，在视觉测试工具中配置排除区域以忽略动态元素（日期、横幅、广告）。第三，使用忽略亚像素变化的容差阈值——这些微小差异永远不是真正的回归。
谁应该负责 baseline 的验证？
这是共同责任。开发人员在修改代码时更新 baseline。审查者检查代码变更和 baseline 变更之间的一致性。设计师或产品负责人验证视觉结果是否符合预期。这些人中没有谁应该独自承担责任。
应该多久从头重新创建所有 baseline？
很少，而且只在特定情况下：捕获浏览器迁移（Chrome 主版本变更）、网站大规模重新设计，或捕获配置的重大变更（viewport、DPI）。在正常运行中，baseline 随修改逐步更新，逐页进行。完全重新创建表明增量流程已经失败。
容差阈值和 baseline 更新有什么区别？
容差阈值自动忽略细微变化（亚像素、antialiasing）以防止误报。这是工具设置。Baseline 更新是人工决策，表示"新的渲染是正确的，它成为新的参考"。两者都是必要的：阈值处理技术噪音，更新处理功能演进。
结论
Baseline 管理不是一个光鲜的话题。它不是那种你会在简历上突出或在技术聚会上展示的技能。但它是你的视觉测试策略成功或失败的决定性因素。
在视觉测试上取得成功的团队不是拥有最好工具的团队。而是那些版本化他们的 baseline、像审查代码一样审查它们、有意识地更新它们、永远不让噪音积累的团队。
从小处开始。20 个管理良好的 baseline 胜过 500 个被忽视的。将 baseline 更新纳入你的完成定义。让整个团队参与审查。最重要的是，永远不要让过时的 baseline 留在原处——这是放弃工具的第一步。