关键要点
- Storybook 已成为以隔离方式记录、开发和测试 UI 组件的标准工具——这是名副其实的
- 集成 Storybook 的视觉测试工具（Chromatic、Loki、Percy）捕获的是隔离组件的截图，而不是组装好的页面
- 最危险的视觉回归发生在组件的组装中——布局、内容和真实场景之间的相互作用
- 一个完整的视觉测试策略将 Storybook 用于组件，再加上一款与框架无关的工具用于完整页面
视觉测试，按照 ISTQB（International Software Testing Qualifications Board）的定义，指的是*"通过将参考截图与应用程序当前状态进行比较，验证软件应用的用户界面是否按照预期视觉规范进行显示"*（ISTQB 词汇表，Visual Testing）。
Storybook 赢了。如果您在2026年开发 UI 组件，您大概率使用 Storybook——或至少考虑过它。在 GitHub 上有超过84,000 颗星，并官方支持 React、Vue、Angular、Svelte、Web Components 等等，Storybook 已经确立了自己作为隔离组件开发事实标准的地位。
很自然地，当团队寻找视觉测试方案时，他们会转向 Storybook 生态。Chromatic 由 Storybook 维护者亲自创建，是最显而易见的选择。Loki 提供了开源替代方案。Percy（BrowserStack Visual Reviews）也提供了 Storybook 集成。
这些工具能用。它们捕获您 story 的截图并检测构建之间的视觉变化。但它们都共享一个没人愿意听的根本性局限：它们测试的是隔离的组件，而不是您用户实际看到的页面。
本文将捍卫一个有些人可能觉得离经叛道的立场：Storybook 是一款出色的开发工具，但仅基于 Storybook 的视觉测试给人的是一种虚假的安全感。要获得真正的覆盖，您必须测试组装好的页面——而这恰恰是 Storybook 不做的。
Storybook：人人都用的工具（理由充分）
在批评通过 Storybook 做视觉测试的局限之前，让我们先给予它应得的认可。Storybook 解决了一个真实的问题，并且解决得很好。
隔离开发
在您应用上下文中开发 UI 组件意味着要在依赖的海洋中航行。您的 Button 组件在它所有变体（primary、secondary、danger、disabled）中都正确工作吗？要在您的应用中验证，您必须导航到使用它的页面，找到一个能展示您想测试变体的应用状态，并希望开发数据正好匹配您想验证的情况。
Storybook 斩断了这个戈尔迪之结。每个组件都有它的 story——带特定 props 的预定义实例——您可以即时查看，且不依赖应用的其余部分。您可以看到您的 Button 处于 primary、secondary、danger、disabled 模式，带短文本、长文本、带图标、不带图标——全在一个专用界面中。
活文档
Storybook 不仅是一款开发工具。它也是一款文档工具。您的 story 成为您设计系统的活文档。设计师可以验证组件是否与样稿一致。产品经理可以探索可用的变体。新开发者可以在不读源码的情况下理解现有组件。
这种文档价值是真实而宝贵的。没有任何静态 README 能取代每个组件附带可配置 props 的交互式实例。
Addon 与生态
Storybook 的生态非常丰富。a11y addon 检查您组件的无障碍性。viewport addon 在不同屏幕尺寸下测试组件。interactions addon 模拟用户交互。视觉测试 addon——Chromatic、Loki、Percy——则捕获截图以检测回归。
这个生态强化了 Storybook 的统治地位。集成的工具越多，采用它的理由就越多，而替代方案就越难以站得住脚。
Storybook 视觉测试工具：版图
让我们回顾通过 Storybook 进行视觉测试的主要选项，以及它们的优势和局限。
Chromatic：官方选择
Chromatic 是由 Storybook 维护者创建的云服务。其工作方式很直接：在每次构建时，Chromatic 在云端浏览器中捕获您所有 story 的截图，并与之前的捕获进行比较。差异在审查界面中呈现，您可以批准或拒绝每一项变化。
Chromatic 的优势是不可否认的。与 Storybook 的集成是原生的——无需复杂配置。基础设施由它管理：无需安装浏览器，无需维护捕获服务器。审查界面非常出色，提供并排比较、滑块以及高亮的差异。Composition 支持允许在单一审查中测试来自多个 Storybook 的组件。
Chromatic 的定价模型基于每月快照数。免费方案提供5,000张快照，对小项目够用。但对于一个有200个组件、3个 viewport、每个组件5种状态的中型设计系统，每次构建就会达到3,000张快照——不到两次构建就会耗尽配额。付费方案从每月149美元起，并随量级快速攀升。
Chromatic 的根本局限是：它测试的是您放进 Storybook 中的内容，而不是您用户在您应用中所看到的。如果您的 story 不反映真实的数据、真实的布局和真实的上下文，Chromatic 的捕获验证的就是您组件的一种虚构状态。
Loki：开源替代方案
Loki 是 Storybook 的开源视觉测试工具。它使用 headless Chrome 或 Docker 捕获您 story 的截图，并在本地比较图片。无云服务，无订阅费。
Loki 的成本优势：免费。但这种"免费"附带维护成本。您自己管理捕获基础设施：安装 headless Chrome、管理系统字体、配置 Docker 以确保可重现性。您本地机器与 CI 之间的渲染差异可能产生持续的误报。审查界面比 Chromatic 的简陋——没有内建的团队协作、没有变更评论、没有审批历史。
更关键的是，Loki 与 Chromatic 共享同样的局限：它测试的是 Storybook 中的组件，而不是您应用中的组件。
Percy（BrowserStack Visual Reviews）
Percy 现在已集成入 BrowserStack 成为 Visual Reviews，通过专门的包提供了 Storybook 集成。它在 BrowserStack 云端捕获 story，并提供带团队协作的审查界面。
Percy 带来了 BrowserStack 基础设施的力量：多浏览器测试（Chrome、Firefox、Safari）、多种分辨率，以及捕获环境的稳定性。CI/CD 集成已经成熟。
Percy 的定价与 Chromatic 类似：基于快照数，入门方案能支持小项目，但在规模化时会变贵。Team 方案从每月399美元起，提供25,000张快照。
和 Chromatic、Loki 一样，通过 Storybook 的 Percy 也是隔离测试组件。Percy 还有一个"页面"模式可以捕获完整页面，但这一功能与 Storybook 集成是分开的，并需要额外的配置脚本。
根本问题：组件与页面之间的鸿沟
这里事情就有趣起来了。我们刚描述的三款工具共享一个隐含假设：如果每个组件在隔离时正确渲染，那组装后的页面也会正确渲染。
这个假设是错的。这就是问题的核心。
组件不会孤立地存在
Storybook 中的组件存在于一个受控环境里。它有一个白色背景（或您 Storybook 配置的背景色）。它有固定的边距。它接收的是您手动定义的 props。它没有邻居推搡它、调整它的尺寸或与它重叠。
在您真实的应用中，同一个组件却生活在一个复杂的视觉生态中。它在一个 flex 或 grid 容器里，那容器对它施加尺寸约束。它紧挨着其他影响它定位的组件。它继承全局样式（CSS reset、变量、字体），而这些可能与 Storybook 中不同。它接收真实数据，而那些数据可能比您 story props 中更长、更短，或格式出乎意料。
组合回归
最阴险的视觉回归不发生在单个组件中。它们发生在组装中。
一个在 Storybook 中以30字符标题完美显示的 Card 组件，当它在真实页面中接收到120字符的标题时，可能会破坏布局。Storybook 永远不会向您展示这种情况，除非您专门为非常长的标题创建了一个 story——而在大多数设计系统中，这些"边缘情况"的 story 并不存在。
一个在 Storybook 中固定高度的 Header 组件，当被用在带有顶部通知横幅的布局中时，可能与主内容重叠。Storybook 不知道那个横幅，因为 Header 是被隔离测试的。
一个在 Storybook 中完美居中显示的 Modal 组件，在虚拟键盘打开、viewport 缩小时，在手机上可能被部分遮挡。Storybook 不模拟虚拟键盘。
一个在 Storybook 中宽度合适的 Sidebar，当与主内容都在 flex 布局中、且主内容包含固定宽度元素时，可能会挤压主内容。这个冲突在 Storybook 中不存在，因为 Sidebar 和主内容从未一起被测试。
渲染上下文
除了空间组合，渲染上下文在组件外观上扮演决定性角色。继承的样式、主题 CSS 变量、全局 media query、加载的字体、用户系统偏好（浅色/深色模式、文字大小、减弱动画）——所有这些都影响您组件的渲染。
Storybook 试图通过 decorator 和全局参数重现这些上下文。但这种重现很少能100%忠实。您开发机器上的系统字体与您用户浏览器中的字体并不相同。Storybook 的 CSS 变量并不一定与您应用的同步。Storybook 中的 media query 模拟 viewport 大小，但不模拟设备特性（像素密度、方向、色彩能力）。
结果：一个组件可能通过它在 Storybook 中所有的视觉测试，却在您实际应用中呈现出不同的视觉渲染——有时微妙，有时戏剧性。
正确的策略：组件 + 页面
本文捍卫的立场不是 Storybook 在视觉测试中没用。而是仅靠 Storybook 是不够的。正确的策略结合两个层级的视觉测试。
第一层：Storybook 中的组件
使用 Storybook 和 Chromatic 这类工具来在隔离条件下验证您设计系统的组件。这有以下几方面价值。
您在受控条件下验证每个组件的每个变体。您在基础组件——按钮、输入框、卡片、模态框——的回归传播到页面之前先检测到它们。您维护一份关于您设计系统的最新视觉文档。
这一层覆盖"微观"回归：按钮颜色变化、输入框 padding 修改、图标大小变更。
第二层：浏览器中的组装页面
使用一款与框架无关的视觉测试工具，例如 Delta-QA，在真实浏览器中捕获您真实的页面。这第二层覆盖"宏观"回归：布局崩坏、组件相互重叠、内容溢出、页面横向滚动、滚动时 header 消失。
这第二层不可替代。任何基于 Storybook 的工具都无法提供它，因为它需要在页面真实的上下文中、用真实的数据、真实的布局和组装好的组件来测试页面。
实践中的互补
具体而言，您的 CI/CD 流水线并行触发两个层级。Chromatic（或您选择的 Storybook 工具）捕获您的 story 并报告组件变化。Delta-QA 捕获您真实的页面并报告布局变化。
如果一处 CSS 变化影响了一个按钮，Chromatic 在按钮 story 中检测到它，Delta-QA 则在所有使用该按钮的页面上检测到它。您在组件级别和页面级别都看到问题。
如果一处布局变化在不修改任何单个组件的情况下影响了页面组合，Chromatic 什么也看不到——所有组件在隔离下都是相同的——但 Delta-QA 在组装好的页面中检测到这一变化。
这种互补就是构成完整视觉测试策略的关键。
Delta-QA：测试您用户实际看到的页面
Delta-QA 是一款无代码视觉测试工具，在真实浏览器中捕获您的页面，并比较版本之间的截图。它不取代 Storybook 或 Chromatic。它补充那些工具做不到的事情。
无需同步任何 story
Storybook 最大的隐藏成本是 story 的维护。每个新组件需要新的 story。每次 props 变化需要更新 story。每个新用例需要追加 story。如果 story 不更新，视觉测试验证的就是您组件的过时状态。
Delta-QA 没有这个问题。它捕获您真实的页面——那些已经存在的页面，带着它们当下的内容和布局。无需写 story，无需维护 mock 数据，无需在您的应用与一个独立测试环境之间做同步。
现实 vs 理想化
您 Storybook 的 story 在理想条件下展示您的组件：合理长度的标题、比例正确的图片、格式良好的数据。您真实的应用收到的是匆忙用户创建的200字符标题、4000×3000 像素上传的图片、带特殊字符和混合语言的数据。
Delta-QA 捕获这种现实。如果一个过长的标题在生产环境破坏您的布局，视觉测试会检测到它——即使 Title 组件用经过精心校准的 story 标题通过了所有 Chromatic 测试。
无需努力的覆盖
对于一个50页、3个 viewport 的网站，Delta-QA 每次部署产生150张视觉截图。要用 Storybook 达到同样的覆盖，就需要为每个页面创建 story——这等于在 Storybook 中重建您的应用，没有人会真的去做这件事。
大多数 Storybook 覆盖的是设计系统组件（按钮、表单、卡片、导航），而不是应用页面（首页、控制面板、个人资料、结账）。这是合乎逻辑的——Storybook 是为组件设计的。但对于视觉测试来说不够。
Chromatic vs Loki vs Percy vs Delta-QA：各自的强项
与其评出一个全能冠军，不如对每款工具的强项做一个诚实的分析。
Chromatic 在设计系统上出色
如果您维护一个跨多个应用共享的设计系统，Chromatic 大概是组件视觉测试的最佳选择。它原生的 Storybook 集成、composition 管理以及协作审查界面让它成为这个用例下最精细的工具。
代价：成本随量级快速上升，覆盖止步于 Storybook 中的组件。对于组装好的页面，您仍需要补充。
Loki 在预算有限时出色
如果您想要无服务费的组件视觉测试，Loki 就是答案。该工具免费，可在本地或您的 CI 中运行。您牺牲了审查界面的舒适度和基础设施的稳定性，但您没有月度订阅。
代价：基础设施维护（字体、浏览器、Docker）可能比云服务的费用消耗更多时间。和 Chromatic、Percy 一样，Loki 仅覆盖 Storybook 中的组件。
Percy 在多浏览器上出色
如果您需要跨 Chrome、Firefox 和 Safari 验证组件渲染，Percy（BrowserStack Visual Reviews）是最强的选择。BrowserStack 基础设施提供了对不同 OS 上真实浏览器的访问，超越了 Chromatic 的模拟。
代价：对中型团队定价偏高，Storybook 模式仍局限于隔离组件。
Delta-QA 在真实页面上出色
如果您想要验证您用户实际看到的内容——组装好的页面、带真实数据、在您应用真实的上下文中——Delta-QA 就是您视觉测试技术栈中缺失的工具。它无需 Storybook，无需脚本，无需框架特定配置。
理想的互补：用 Chromatic（或 Loki，或 Percy）测试您的组件，用 Delta-QA 测试您的页面。两个层级合在一起，构成完整的视觉测试覆盖。
仅靠 Storybook 真的不够的场景
某些场景让全页视觉测试不再是"锦上添花"，而是不容妥协的需求。
多租户应用
如果您的应用按租户调整外观（白标、自定义主题、客户 logo），您 Storybook 的 story 无法覆盖所有变体。Delta-QA 可以以不同的租户上下文捕获同一页面，验证每一种定制都能正确显示。
带 CMS 的应用
如果您的内容由 CMS 管理，由非技术团队创建和编辑内容，那 Storybook 数据永远无法反映真实内容。一篇带肖像图而非预期横向格式的文章、一个用更宽字符语言的标题、一段带嵌套表格的内容——这些真实情况可能破坏您的布局，而 Storybook 永远不会向您展示它们。
电商应用
产品页是关键的视觉测试场地。图片数量、描述长度、是否存在促销、产品变体、客户评价——每一种组合都可能影响布局。Storybook 可以模拟其中一些组合，但不是全部。而那些有问题的组合，往往是您没想到要写进 story 的那些。
框架或设计系统的迁移
当您把应用从一个设计系统迁移到另一个，或从一个框架主版本迁移到另一个时，视觉回归会非常多且常常微妙。全页视觉测试给您一个覆盖整个应用面的前后对比——而不仅是您记得在 Storybook 中更新的那些组件。
常见问题
如果我用 Delta-QA，是否应该放弃 Storybook？
不。Storybook 和 Delta-QA 是互补的，不是竞争的。Storybook 仍然是开发、记录和隔离测试您组件的出色工具。Delta-QA 添加了 Storybook 缺失的覆盖：在您真实应用中对组装好页面的视觉测试。推荐的方式是在 CI/CD 流水线中并行使用两者，同时覆盖单个组件和完整页面。
Chromatic 由 Storybook 团队制作——这不是最佳的集成吗？
Chromatic 与 Storybook 的集成确实出色。它是测试您 Storybook 中组件的最佳工具。但"最佳的 Storybook 集成"并不意味着"最佳的视觉测试覆盖"。Chromatic 测试 Storybook 展示的内容，而不是您应用所显示的。对于发生在组件组装、页面上下文或真实数据中的回归，您需要一款测试真实页面的工具。
全页视觉测试会产生大量误报吗？
在合适的设置下，不会。Delta-QA 让您能够为动态内容（日期、计数器、实时数据）配置排除区、禁用 CSS 动画，并在捕获前等待字体完全加载。对于以静态或可预测内容为主的网站，误报很少。对于有大量动态内容的应用，配置排除区的工作是一项最初投入，长期来看能减少噪音。
完整的视觉测试策略（Storybook + 页面）成本是多少？
成本取决于您选择的工具。在组件层，Loki 是免费的（但需要维护）。Chromatic 从每月149美元起。Percy 从每月399美元起。在页面层，Delta-QA 提供一个对小项目而言足够的免费方案。Loki（免费）和 Delta-QA（按量级免费或付费）的组合提供了在可控成本下的完整覆盖。真正的问题不是策略的成本，而是一个未被检测到的视觉回归在生产环境中的成本。
我的 Storybook story 能作为页面级视觉测试的文档吗？
您的 story 记录了您单个组件的行为和外观，无论是否进行页面级视觉测试，这都依然有用。当 Delta-QA 在某个页面上检测到视觉回归，您的 Storybook story 帮助识别哪个组件该负责。这就是互补在实践中的体现：Delta-QA 告诉您"这个页面在这里改变了"，Storybook 通过向您展示相关组件的不同变体帮助您理解原因。
我如何说服团队在 Storybook 之外再加上页面级视觉测试？
最有说服力的论据是具体的：展示一个 Storybook 不会检测到的真实视觉回归。生产环境中的布局崩坏、移动端组件相互重叠、页面内容溢出容器。这些回归在每个项目中都存在——只要展示一个就足以为引入页面级视觉测试正名。Delta-QA 在三十分钟内就能搭建好，且无需修改您的 Storybook 或代码——它是纯粹的补充，没有摩擦。
结语：完整的视觉覆盖需要两个层级
Storybook 已经改变了团队开发和记录 UI 组件的方式。它是每位前端开发者工具箱里不可或缺的工具。集成 Storybook 的视觉测试工具——Chromatic、Loki、Percy——通过检测单个组件中的回归，带来了真实的价值。
但组件不会孤立地存在。它们生活在页面里，被其他组件包围，带着真实数据，在受约束的布局中，受到 Storybook 不能重现的全局样式和渲染上下文影响。最危险的视觉回归——那些影响用户体验的——就发生在这种组装层面。
要获得完整的视觉测试覆盖，您需要两个层级。第一层在 Storybook 中测试组件。第二层在浏览器中测试页面。两者都必要，没有哪一个能单独胜任。
Delta-QA 就是为这第二层而设计的。它在真实浏览器中捕获您真实的页面，按您应用实际的渲染。无需脚本，无需 story，无需框架特定的依赖。它是您 Storybook 的天然补充——把您组件级视觉测试转变为完整视觉测试所缺失的那一块。