组件视觉测试（component visual testing）：一种自动化验证方法，在脱离完整页面上下文的情况下单独渲染界面组件，并将其外观与已确认的基准状态进行比较，以便在设计系统层面的视觉回归扩散到生产页面之前将其发现。
前端团队往往刻意回避一个问题：“我们的组件在 Storybook 里做了视觉测试，但生产环境的页面也测了吗？”大多数情况下，答案是没有。这个缺口代价不小，因为真正到达用户眼前的视觉缺陷并不存在于 Storybook，而是存在于真实页面中：真实的数据、真实的交互、真实的组件组合。
Chromatic 是测试隔离组件的出色工具，Delta-QA 则专为测试完整页面而设计。想了解视觉测试的入门知识，请阅读我们的视觉回归指南。严格来说它们并非竞争对手，而是从不同高度审视同一个问题的工具。但如果你只能选一个，或者想弄清各自的价值，这篇对比会直奔主题。
我们所有的对比文章都基于可核实的标准：替代方案与对比。
Chromatic 检查隔离的组件；那么生产环境中的真实页面由谁来测？ Delta-QA 无需编写代码即可覆盖这些页面，提供免费账户，无需银行卡。 免费使用 Delta-QA →
Chromatic：设计系统的守门人
Chromatic 由 Storybook 的维护者打造，是 Storybook 生态在视觉测试方面的自然延伸。关于视觉测试在设计系统中的整体应用，请参阅我们的专题指南。它的思路很漂亮：你已经在 Storybook 中定义好了组件及其各种状态（stories）。Chromatic 在每次提交时为每个 story 截图，与基准进行比较，并标出变化。
对于使用设计系统的团队，这是一套集成度很高的工作流。设计师定义了一个有四种变体（primary、secondary、disabled、loading）的按钮，开发者实现这些变体并创建对应的 stories。每次代码变更时，Chromatic 都会检查这四种变体在视觉上是否发生回归。如果按钮的 border-radius 被意外修改，Chromatic 会在任何人做代码评审之前就发现它。
该工具还提供界面评审（UI Review）功能，让设计师和开发者在合并之前以视觉方式确认变更。它本质上是一种视觉化的代码评审，对于维护设计系统的一致性确实有用。
截至 2026 年 10 月，Chromatic 已不再局限于 stories：它还执行交互测试和无障碍测试，可以基于现有的 Playwright、Cypress 或 Vitest 测试运行，并在四种浏览器（Chrome、Firefox、Safari、Edge）中渲染截图。它还把自己定位为 AI 代理所编写界面的护栏，并提供有文档说明的 MCP 服务器，向它们提供已验证组件的上下文。
Chromatic 的盲区：真实世界
有一个问题 Chromatic 没有解决（这不是质量缺陷，而是架构上的取舍）：隔离的组件与组装后的页面表现并不一样。
在 Storybook 中单独测试的按钮，渲染于受控环境：固定的视口、没有相邻元素、没有继承的 CSS 上下文、没有动态数据、也没有与其他组件的交互。这正是它在组件层面可靠的原因，同时也让它对组装层面的问题视而不见。
生产环境中视觉上出问题的是什么？很少是某个孤立的组件，出问题的是组合。因为 z-index 变了，头部组件盖住了导航组件。因为卡片组件多了一个 margin，商品网格错位了。因为某种语言里的标签比预期更长，表单溢出了容器。因为中间某个区块丢了最小高度，页脚爬到了主内容上面。
这些缺陷在 Storybook 中是看不到的。每个组件单独看都没问题，有问题的是它们的组装。而 Chromatic 按设计就不测试组装，它测试的是砖块，而不是整座建筑。
Delta-QA 测试的是整座建筑。你在网站上录制一条操作路径，无需代码，工具会在每个版本中于真实浏览器里重放，所有组件都已组装，带着继承的样式、交互和数据。每个页面都像人眼那样与其基准比较：报告会告诉你哪个元素变了（一个按钮从蓝色变成了绿色，一处边距发生了移动）。这是对现实的测试，而不是对建筑师图纸的测试。
Storybook 与生产环境之间的鸿沟
Storybook 所展示的与生产环境所呈现的之间存在结构性差异，而这种差异很少被讨论。
数据。 在 Storybook 中，组件接收的是精心挑选的模拟数据，具有代表性，也能放进设计稿。在生产环境中，它们接收真实数据：一个长达 150 个字符、事先没人想到的商品名，一张比例奇怪的图片，一个小数位数不固定的价格，一个原本一行、现在占了三行的分类列表。这些真实数据会造成 Storybook 永远无法重现的视觉状况。
继承的样式。 在 Storybook 中，每个组件都渲染在相对干净的 CSS 沙箱里。在生产环境中，组件会继承全局样式、CSS reset、主题、上下文覆盖，有时还有第三方样式（分析小部件、聊天机器人、Cookie 横幅）。一个组件可能在 Storybook 里完美无缺，在生产环境里却因为某个任何 story 都无法重现的样式冲突而视觉损坏。
动态状态。 Storybook 测试的是预先定义的状态，也就是开发者认为值得记录的那些。在生产环境中，组件会经历中间状态、未预料到的错误状态，以及没人想过要测试的状态组合。校验进行中的表单、位于会调整尺寸的 flex 容器中的按钮、因促销而多出徽章的商品卡片，每一种组合都是 Storybook 没有覆盖的视觉测试。
Delta-QA 测试的是你的用户实际看到的内容，而不是 Storybook 承诺他们会看到的内容。
无代码与 Storybook：受众问题
Chromatic 面向使用 Storybook 的前端开发者。这个受众合理而重要，但范围有限。
要使用 Chromatic，你必须有写在代码里的测试：Storybook stories，或者 Playwright、Cypress、Vitest 测试。你得会写它们，得理解基准与视觉快照的概念，还得熟悉基于 pull request 和持续集成的工作流。总之：你得是前端开发者。
想在发布前检查某个页面的 QA 经理呢？他不能直接使用 Chromatic。在验收中发现视觉问题的产品负责人呢？他无法启动测试。想把设计稿与生产结果做对比的设计师呢？不通过开发者，他就进不了 Chromatic 的工作流。
Delta-QA 把视觉测试向整个团队开放。不需要 Storybook，不需要代码，也不需要去理解 CI/CD 流水线。你像用户一样浏览网站，Delta-QA 录制场景，在下一个版本中重放，你只需阅读报告。QA 在上线前检查下单流程，产品负责人确认某次改动没有破坏其他地方，每个人都能独立完成。
对于希望在 CI 中通过 Playwright 测试来检查页面的开发者，Delta-QA 现在有了 SDK，即 SDK Vision：每个要检查的页面只需一行，未经判定的差异会让测试失败。
这不是对技术的反智主义，而是承认视觉质量关乎每一个人，工具理应反映这一现实。
组件与页面：两个互补的测试层级
与其把 Chromatic 和 Delta-QA 对立起来，不如把它们看作完整视觉测试策略中的两个层级。
组件层级（Chromatic）：验证设计系统的每一块砖在视觉上是否符合规格。这是视觉的单元测试，在最细的粒度、开发周期最早的阶段（甚至在合并之前）发现回归。
页面层级（Delta-QA）：验证组装后的页面在真实数据和层叠样式下视觉上是否正确。这是视觉的集成测试，发现组装问题、样式冲突，以及只在完整页面上下文中才存在的回归。
两者兼用的团队拥有出色的视觉覆盖：组件回归由 Chromatic 尽早发现，页面回归由 Delta-QA 发现，安全网是双层的。
但如果只能选一个（出于预算、时间或资源的限制），问题就变成：哪个测试层级能更好地保护你的用户？答案毫无疑问是页面层级。因为你的用户看到的不是组件，而是页面。
云端还是 On-Premise：你的截图去了哪里？
除了组件与页面的模式之外，还有一个对某些组织影响很大的架构差异：截图存放在哪里。
Chromatic 是云服务。你的截图会发送并存储在 Chromatic 的基础设施上；截至 2026 年 10 月，其价格表未提及自托管部署，即使是 Enterprise 方案（提供 SSO、SLA 以及数据保留设置）也是如此。对大多数公开项目来说，这不成问题。但对于内部应用、包含客户数据的后台，或受严格监管约束的组织，界面截图离开企业边界这件事本身就可能构成障碍。
Delta-QA 提供 On-Premise 方案，通过 Docker 安装在你自己的基础设施上：截图不会离开你的网络，并可通过为期一个月的免费 POC 进行评估。这与下文详述的数据主权是同一逻辑，只是放在架构层面来表述：data stays vs data leaves（数据留下与数据离开）。
商业模式：按快照计费
Chromatic 按每月快照数计费。一个快照等于一个 story、一种浏览器、一种分辨率。200 个组件、每个 3 个 stories、2 种浏览器，每次构建就是 1 200 个快照。每天 20 次构建（活跃团队），一个月就是 720 000 个。
截至 2026 年 10 月，免费方案每月提供 5 000 个计费快照，足够覆盖最初的范围，但随着设计系统扩大很快就会用完。而且这个免费方案仅限 Chrome：跨浏览器测试（Firefox、Safari、Edge）从 Starter 方案起，每月 179 美元，含 35 000 个快照。Pro 方案为每月 399 美元，含 85 000 个快照，每多一个快照收费 0.008 美元，Enterprise 则需报价。TurboSnap 可以减轻账单：只有受文件变更影响的测试才会重新截图，其余的在配额中计得更少。具体来说，180 个 stories × 3 种分辨率 = 每次构建 540 个快照，仅 9 次构建就会用完免费配额。这带来了与 Percy 相同的矛盾：测试覆盖率与预算成反比。没有 TurboSnap 的话，团队最终会限制被测试的 stories 或构建频率，以便留在配额之内。
Delta-QA 从免费账户开始，无需银行卡。它的覆盖范围按路径和已验证的步骤来衡量，而不是按 stories 乘以浏览器和分辨率来计算。
Chromatic 测试隔离的组件；那完整页面呢？ Delta-QA 以无代码方式覆盖，无需银行卡。 免费使用 Delta-QA →
Chromatic 能做而 Delta-QA 做不到的事
坦诚起见，必须承认 Chromatic 的独特优势。
协作式界面评审。 Chromatic 的工作流允许开发者和设计师在 pull request 中以视觉方式确认组件变更。这是一个集成的评审流程，Delta-QA 中没有完全对等的功能。
测试组件的所有状态。 如果你的按钮有 12 种变体（尺寸、颜色、状态、主题），Chromatic 会系统地全部测试。要在页面层级测试这 12 种变体，就得找出 12 个不同的页面，而这并不总是可行。
多浏览器。 Chromatic 在 Chrome、Firefox、Safari 和 Edge 上截取你的测试（从 Starter 方案起）。Delta-QA 目前在 Chromium 上比较，Firefox 和 WebKit 已在计划中。
与 Storybook 的原生集成。 Chromatic 出自 Storybook 的创建者之手，集成已经做到极致：自动检测新的 stories，配置极少，工作流顺畅。如果 Storybook 是你界面开发工作流的核心，这是实实在在的优势。
活的视觉文档。 Chromatic 保存每个组件随时间变化的视觉历史。它是一个活的设计库，展示每个组件的演变，对设计系统来说是很有价值的功能。
Delta-QA 带来而 Chromatic 未覆盖的价值
对现实的测试。 生产环境中的页面，带着真实数据、真实的继承样式、组件之间真实的交互。不是 Storybook 里干净的理想化状态，而是世界本来的样子。
人人可用。 团队中的任何成员都可以发起视觉测试。不需要是开发者，不需要了解 Storybook，也不需要接触 CI 流水线。视觉测试的民主化。
技术栈无关。 无论你的前端技术栈是什么，Delta-QA 都能工作：React、Vue、Angular、Svelte、WordPress、Shopify、静态网站、jQuery 写的遗留应用，都无所谓。只要能在浏览器里显示，Delta-QA 就能测试。Chromatic 依赖写在代码里的测试（Storybook、Playwright、Cypress、Vitest），因此要求前端项目具备相应的配套。
数据主权。 使用 On-Premise 方案，比较在你自己的基础设施上运行，不会有任何截图发送给第三方。适用于内部应用、敏感数据，以及受严格法规约束的组织。
指明元素的报告。 每处差异都对应页面上的一个元素，并以清晰的语言描述：颜色、边距、字体、位置。你知道该看哪里，无需去解读一张差异图。
理想场景：两者并用
如果你的团队已经在用 Storybook，并且有预算使用 Chromatic，那么两个工具结合是最稳健的策略。
Chromatic 在设计系统层面监控你的组件。每一处样式变化、每一种变体、每一个状态都经过视觉验证，回归在开发阶段、代码到达主分支之前就被发现。
Delta-QA 监控生产环境（或预发布环境）中的页面。组装问题、样式冲突、只在真实上下文中才会出现的缺陷，会在用户看到之前被发现。
两者结合就是双重覆盖：一边是砖块，一边是组装好的路径。
务实场景：只用一个工具
如果你只能选一个工具（因为预算有限、团队规模小，或者想从简单的开始），问题归结为：什么能更好地保护你的用户？
你的用户看不到你的 Storybook 组件，他们看到的是你的页面，与页面交互，通过浏览页面形成对产品的看法。一个在 Storybook 中完美、在组装后的页面中却损坏的组件，从用户的角度看就是一个损坏的组件。
Delta-QA 测试你的用户所看到的内容。就这么简单。
准备好测试用户真正看到的页面了吗？ 用 Delta-QA 发起你的第一次比较，免费账户，无需银行卡。 免费使用 Delta-QA →
FAQ
Chromatic 可以脱离 Storybook 使用吗？
可以。截至 2026 年 10 月，除了 Storybook 的 stories，Chromatic 也会截取 Playwright、Cypress 或 Vitest 测试中的页面。不过仍然需要写在代码里的测试：由它们决定截取什么。Delta-QA 从无需代码录制的场景出发，不论是什么技术栈生成了你的页面；对于 Playwright 测试，它提供 SDK Vision。
在 Storybook 中测试组件就足以保证视觉质量吗？
不够。隔离测试的组件无法重现组装后页面的真实条件：样式继承、动态数据、组件之间的交互、第三方样式。Chromatic 验证你的砖块是否正确，Delta-QA 验证组装是否正确。要实现完整覆盖，两个层级都是必要的。
Chromatic 能检测响应式问题吗？
可以，但仅限于 Storybook 所展示的范围。你可以为 stories 配置不同的视口尺寸，Chromatic 会对其进行测试。但组装页面特有的响应式问题（某个元素与其他元素组合时溢出、真实的长数据导致布局崩坏）无法被发现。而 Delta-QA 会在真实浏览器中比较带有真实数据的组装页面。
Chromatic 的免费方案涵盖什么？
截至 2026 年 10 月，Chromatic 的免费方案每月提供 5 000 个计费快照，仅限 Chrome，大约能覆盖几十个组件和偶尔的构建。一旦组件数量或构建频率增加，配额很快就会用完。一个有 100 个组件、每个组件 3 个 stories、每天 2 次构建的项目，在没有 TurboSnap 的情况下每月大约消耗 18 000 个快照。
可以用 Delta-QA 测试隔离的组件吗？
Delta-QA 针对完整页面优化，而不是隔离的组件。如果你有一个环境，其中组件在可访问的 URL 上被单独渲染（比如已部署的 Storybook），理论上可以用 Delta-QA 来比较它们。但这不是它的主要使用场景。对于隔离组件的测试，Chromatic 仍然是首选工具。
如果不在组件层面，Delta-QA 如何处理设计系统？
Delta-QA 在最重要的层面检查设计系统的视觉一致性：使用它的页面。如果设计系统中的某次改动破坏了十几个页面的布局，Delta-QA 会直接发现。这是设计系统的端到端测试，与 Chromatic 的单元测试互为补充。