设计系统的视觉测试是一种自动化验证实践，针对每个 UI 组件——按钮、表单、卡片、模态框——同时在隔离环境（Storybook 或同类工具）和真实上下文（应用页面内）中进行外观验证，以便在每次变更时检测视觉回归。
设计系统已成为前端团队的标准。如需了解相关主题，请参阅我们的视觉回归测试指南和视觉测试入门指南。一组可复用、有文档、有版本管理的组件。整洁。可维护。然而，视觉 bug 仍会漏过。原因如下。
完美隔离组件的陷阱
你在设计系统中有一个 "Card" 组件。你在 Storybook 中测试它，它很完美：边距正确，颜色符合品牌规范，排版合规。一切都是绿色的。
你将它集成到一个三栏网格、带侧边栏和页头的页面中。然后，Card 越出了它的列。文本与相邻组件重叠。操作按钮被页脚部分遮挡。
组件是完美的。页面是坏的。隔离测试无法检测到这一点。
这是根本陷阱：组件从不孤立存在。它与邻居、父布局、真实内容相互作用。在隔离环境中测试，就是在生产中不存在的真空中测试。
为什么两个层次都必要
隔离组件测试回答一个问题："组件本身在所有状态下都正确显示吗？"。激活按钮、未激活、悬停、聚焦。带短标题的 Card、长标题的、无图像的。打开的模态框、关闭的。这些测试将设计系统作为库来保护。
完整页面测试回答另一个问题："组件在应用的真实上下文中协同工作吗？"。布局是否成立？组件之间是否避免重叠？当 5 个组件共享同一空间时，响应式是否有效？
两个问题都是合理的。任何一个单独都不能覆盖完整谱系。
每个层次的工具
对于隔离组件，Chromatic（与 Storybook 集成）是参考标准。每个 story 自动成为一个视觉测试。它能有效地保护组件库。
对于完整页面，需要一个测试真实页面和真实用户路径的工具。这是 Delta-QA（无代码）、Playwright（有代码）或 Percy（SaaS）的领域。如需 Playwright 教程，请参阅我们的完整指南。
许多团队遇到的问题是：他们大量投资于通过 Chromatic 进行的组件测试，而忽视完整页面测试。结果：库受到保护，但应用没有。如需主要工具的对比，请参阅我们的 2026 排名。
只有完整页面才能检测到的回归
相邻组件之间的布局冲突。两个在隔离中完美工作的组件，但在共享 CSS 网格时发生重叠。
CSS 级联效应。父组件上的样式更改影响其所有子组件的渲染。在隔离中，子组件没有父组件——bug 不可见。
真实上下文中的响应式问题。在隔离中响应式（适应其容器宽度）的组件，但当容器本身根据视口变化大小时就会崩溃。
真实内容 vs 演示内容。Storybook 中的 stories 使用干净、校准过的演示数据。在生产中，用户输入 200 字符的标题、纵向图片代替横向、阿拉伯语文本反转方向。最后这种情况在跨浏览器中尤其棘手：详情请参阅我们的跨浏览器视觉测试指南。
页面间一致性。你的"立即购买"按钮在一个页面看起来完美，在另一个页面由于继承的 padding、容器宽度或主题覆盖而略有不同。只有页面级别的测试能捕捉这种漂移。
推荐策略
使用 Chromatic（或同类工具）保护你的组件库。每个组件、每个状态、每个变体。这是第一道安全网。
使用完整页面测试工具保护应用本身。关键页面、主要用户路径、复杂布局。这是第二道网。
任何一个单独都不够。两者结合，才能覆盖完整谱系。
如何确定测试优先级
你不能测试所有内容。根据影响和变更频率来决定。
在组件级别，专注于：
- 在超过 5 个页面上使用的组件（Button、Input、Card、Modal、Table）
- 状态多的组件（表单字段、toggle、dropdown）
- 频繁变化的组件（每次发布都引入新变体）
在页面级别，专注于：
- 转化页面（结账、注册、定价）
- 高流量页面（首页、仪表板、搜索结果）
- 多个设计系统组件交互的复杂布局页面
- 回归代价高昂的页面（商业上或运营上）
仅在内部管理页面上使用一次的组件，不需要与到处使用的 Button 相同的审查。
Storybook + 页面级工具：制胜组合
我们见过的最有效的设计系统 QA 配置明确地结合了两层：
- Storybook 与 Chromatic 在每个触及
packages/design-system/*的 PR 上运行。组件级别的回归在 PR 进入 main 之前阻止它。 - 页面级测试工具 在每个触及应用代码的 PR 上运行。页面回归在 PR 部署之前阻止它。
两个系统共享相同的比较哲学（结构性或感知性，取决于工具），但在不同的抽象层运行。逃过组件层的 bug 在页面层被捕获。隔离中不可见的 bug 在重要的地方显现：在上下文中。
那测试维护呢？
最常见的反对意见是："两层意味着双倍维护"。
实际上，不是。每一层捕获不同的 bug。如果你只有组件层，你会用页面级别的手动 QA 来弥补——更慢、更不可靠。如果你只有页面层，每个组件变体都需要自己的页面测试——数量爆炸。
两层，配置得当，比单层试图同时完成两项工作产生更少的误报，需要更少的维护。
常见问题
如果我们使用 Storybook，Chromatic 就足够了吗？
为了保护组件库，是的。为了保护完整应用，不是。布局 bug、CSS 级联问题和真实内容问题只在页面级别可见。
需要对所有组件进行视觉测试吗？
专注于共享组件（Button、Input、Card、Modal、Table）和那些状态多的组件。简单且很少修改的组件可以排除。在影响和变更频率最高的地方进行测试。
如何无代码地测试完整页面？
使用像 Delta-QA 这样的工具。你导航到页面，工具捕获状态，并在后续运行中自动比较。不需要 Storybook 或代码。
组件测试能检测主题问题吗？
可以，如果你有每个主题（明亮/暗色）的 stories。但它不能检测上下文中的主题问题——例如，嵌套在另一个组件中时主题切换错误的组件。
组件测试应该阻止部署吗？
对于在整个设计系统中使用的共享组件：是的。Button 上的回归会影响每个页面。对于在单个功能中使用的一次性组件：视情况而定。阻止那些在生产中回滚代价高昂的内容。
如何为新团队引入这种两层方法？
从页面层开始。它立即捕获影响最大的回归并展示价值。当 Storybook 已经建立且贡献者熟悉创建 stories 后，再添加组件层。相反顺序很少奏效——首先采用组件测试的团队经常跳过页面层，因为他们感到"已被覆盖"。
设计系统保护一致性。视觉测试保护现实。在隔离中测试组件就是验证砖头是否合格。测试完整页面就是验证房屋是否屹立。