UI 质量与交互测试

• 测试金字塔各层的定位与职责
• 各层测试的比例与成本
• 分层策略的平衡与取舍

UI 测试遵循"测试金字塔"的分层思想：底座是单元测试，覆盖组件内部逻辑（状态、props、计算、渲染正确性），成本低、速度快、定位精确，是数量最多的层；中间是集成测试，覆盖组件之间的交互与协调（如表单提交触发回调、父子组件联动），验证"交互正确性"；再往上是 E2E 测试，覆盖真实用户流程（从入口到完成的关键路径），验证跨组件、跨路由、跨系统的端到端行为，成本高、速度慢、稳定性差，数量最少；视觉测试则作为"外观层"，验证渲染出的界面是否符合预期，可与上述各层并行。分层策略的关键是"按比例分配成本"：单元测试应占大头（覆盖组件逻辑细节），集成测试与 E2E 聚焦关键路径，视觉测试覆盖每个 UI 状态。UI 测试金字塔的核心原则是"底层快而多、顶层慢而少"，避免用大量昂贵的 E2E 覆盖组件逻辑，也避免用视觉测试替代逻辑断言。同时，"从右向左测试左移"——把能在单元层验证的逻辑尽量下沉，减少对昂贵的 E2E 与视觉测试的依赖。视觉测试在金字塔中通常是"横向的补充层"，不替代任何一层，而是补充"外观正确性"这一维度。

答题核心是理解各层职责与成本差异，强调"底层多、顶层少"的比例原则与"左移下沉"策略。突出视觉测试作为横向补充层的定位。

• play 函数与组件隔离环境
• 与 Testing Library 的集成方式
• 交互验证的可视化与断言

Storybook 的 Interaction Testing 通过 play 函数在组件隔离环境中仿真用户交互——play 函数在 story 渲染完成后自动执行，可模拟点击、输入、键盘、异步等待等操作，并配合断言验证交互结果。play 函数本质上是在浏览器环境（Storybook 的 iframe）中驱动真实 DOM，与单元测试的 jsdom 不同，它运行在真实浏览器渲染环境中，能验证真实交互行为。与 Testing Library 的集成：Storybook 的 play 函数内置了 Testing Library 的 API（fireEvent、userEvent、waitFor、screen 等），你可以在 play 中直接使用 Testing Library 的查询与事件工具，例如 const button = screen.getByRole('button'); await userEvent.click(button);，从而复用 Testing Library 的"以用户视角查询、模拟真实用户行为"的理念。集成方式通常是把交互断言写成 play 函数，并配合 Storybook 的 addon-interactions 面板可视化逐步回放交互过程与断言结果，便于调试与审查。这样，组件在隔离环境中即可验证"用户操作 → 组件状态变化 → UI 更新"的完整交互链路，无需完整页面环境，反馈快、定位精确。实践中也可把 play 函数中的断言逻辑抽离为可复用工具，供单元测试与 E2E 复用。

答题核心是理解 play 函数在真实浏览器隔离环境中的交互仿真能力，以及它复用 Testing Library API 与可视化回放的特点。强调"隔离环境 + 真实交互 + 可视化断言"的价值。

• 脆弱测试的成因（过度耦合、选择器不稳）
• 以用户视角查询（Role、Label、Text）
• 语义化与数据属性、稳定选择器

脆弱测试（brittle tests）指因 UI 微调（改文案、改样式、改 DOM 结构）而频繁失败、需要不断维护的测试，其根源是测试与实现的"过度耦合"。抗脆弱性设计的基本原则是"让测试验证用户可感知的行为，而非实现细节"。具体手段：一是用"以用户视角查询"替代脆弱的 CSS 选择器——优先使用 Testing Library 的 Accessibility Query（getByRole、getByLabelText、getByText、getByPlaceholderText），它们按用户能感知的语义（角色、标签、文本）定位元素，而非依赖 DOM 层级与 class；二是避免依赖布局/样式选择器（如定位、嵌套层级），改用 data-testid 作为稳定的语义锚点（仅当无用户可感知语义时）；三是断言"行为结果"而非"内部状态"——例如断言按钮是否可点击、表单提交后是否显示成功提示，而不是断言某个内部变量；四是避免过度精确的文本匹配——用正则/子串匹配容忍文案微调；五是隔离外部依赖——用 mock 隔离网络、时间、随机数，保证测试确定性；六是断言"用户可见结果"而非动画中间态。通过这些手段，测试在面对 UI 微调时仍稳定通过，只在真实行为变化时才失败，从而把维护成本降到最低。

答题核心是"测试与实现的解耦"——以用户可感知的语义查询与行为断言替代实现细节依赖。强调 Role/Label/Text 查询、稳定锚点、mock 隔离等抗脆弱性手段。

• 表单校验的即时性与异步校验
• 防重复提交与提交状态
• 焦点管理与错误提示的可访问性

表单交互测试要点可归纳为"校验、提交、焦点、提示、恢复"五个维度。一是即时校验——验证输入时实时的格式/必填校验（错误在下一次输入时消失或更新）、异步校验（如用户名唯一性）的防抖与竞态，以及校验通过的时机；二是防重复提交——验证提交后按钮是否禁用/加载态，防止用户连点导致重复提交，测试需覆盖"提交中再次点击不触发第二次请求"；三是焦点管理——验证提交后焦点是否移动到错误字段（便于键盘用户修正）、错误提示是否可被读屏感知（aria-invalid、aria-describedby）、表单项间的 Tab 顺序是否合理；四是错误提示——验证错误消息的展示位置、内容、颜色（对比度）、与字段的关联（程序化关联），以及空态/错误态下的可访问性；五是错误恢复——验证提交失败后数据是否保留（不丢失用户输入）、错误信息是否清晰、用户能否修正后重新提交、是否出现"已提交数据 + 失败"的一致状态。测试时可结合"提交一次"交互、mock 服务的失败/慢响应、键盘导航等场景，覆盖正常与异常路径。特别要注意"即时校验"与"提交校验"的区分——即时校验在输入时触发，提交校验在提交时触发，二者都可能显示错误。

答题核心是覆盖表单交互的完整生命周期，重点强调"防重复提交、焦点管理、错误恢复"这些容易被遗漏但直接影响用户体验与可访问性的要点。

• 动画的最终状态与中间状态验证
• 动画的禁用/减速策略
• 手势交互与 View Transitions 的验证

动画与过渡效果的测试难点在于"时序性"与"非确定性"。策略上分几层：一是验证"最终状态"——动画结束后元素应处于正确状态（位置、透明度、尺寸、可见性），用 waitFor 或等待动画结束来断言终态，这是最稳定、最常用的方式；二是验证"关键中间态"——对关键动画（如菜单展开、轮播切换）可冻结动画（prefers-reduced-motion 或禁用过渡）后直接断言目标状态，或主动暂停动画在特定时间点截图/断言，验证动画路径是否合理；三是"禁用/加速动画"——在测试中禁用 CSS 动画/过渡（注入 animation: none）以消除时序问题，或在测试配置中启用 prefers-reduced-motion，让测试确定性更强；四是验证"View Transitions"——验证路由/页面切换的过渡是否正确触发、过渡结束时新页面是否就绪、是否出现闪白或闪烁；五是"手势交互"——用 userEvent/touch 事件模拟拖拽、滑动、长按、双指缩放等，验证手势触发的动画与最终状态；六是验证"可访问性"——尊重 prefers-reduced-motion，禁用动画时功能仍可用。整体上，策略是"宁可验证终态与关键状态，也不要依赖动画时序的精确帧"，把动画的时序不确定性隔离在测试之外。

答题核心是"避免依赖动画时序的精确帧"，通过验证终态、冻结/禁用动画、尊重 reduced-motion 来获得确定性，同时覆盖手势与 View Transitions 的正确性。

• 多语言文本的布局风险（长度、溢出、截断）
• RTL 镜像布局的正确性
• 检测手段与断言方式

多语言/RTL 布局测试的核心是"不同的语言文本长度与书写方向会破坏固定布局"。检测手段包括：一是文本溢出检测——对每个语言环境，用布局断言检查元素是否溢出容器、是否出现横向滚动、文本是否被截断（用 scrollWidth/clientWidth 比较或检查省略号），重点覆盖长文本语言（如德语、俄语、阿拉伯语）与固定宽度容器；二是文本换行与截断——验证长标题/长标签是否合理换行而非截断，或验证截断策略（ellipsis）是否符合预期；三是 RTL 镜像验证——在 RTL 环境下验证布局是否正确镜像（文本右对齐、图标/箭头方向翻转、导航顺序反转），用视觉对比或布局断言检查"镜像后元素是否对称、无重叠、无溢出"；四是文字方向与嵌入——验证 dir="rtl" 下混合文本（如数字、URL、英文）的 bidi 处理是否正确；五是字体与字符集——验证非拉丁字符的字体渲染是否正常、是否出现豆腐块（乱码）。测试时需按语言矩阵（至少覆盖英文、中文、阿拉伯语/希伯来语 RTL）驱动，配合视觉回归与布局结构断言双重验证，并可在 CI 中按语言批量执行。

答题核心是"从文本长度与书写方向两个维度覆盖布局风险"，用布局断言检测溢出/截断，用镜像验证检测 RTL 正确性。强调多语言与 RTL 的专项测试必要性。

• 微前端的样式隔离风险
• 子应用间事件/状态通信
• 视觉一致性与集成测试

微前端把前端拆分为多个独立部署的子应用，UI 集成测试需关注三方面：一是样式隔离——子应用间 CSS 可能互相污染（全局选择器、CSS-in-JS 注入、全局样式冲突），测试需验证"子应用 A 的样式不影响子应用 B"，通过视觉回归对比"单独加载 vs 集成加载"的差异，或检查加载某子应用后全局样式是否被意外覆盖；二是事件通信——子应用间通过全局事件/自定义事件/状态总线通信（如单一登录态、跨应用跳转），测试需验证事件分发、订阅、payload 传递是否正确，以及跨应用的导航/状态同步是否一致；三是视觉一致性——不同子应用由不同团队开发，可能风格不一致，视觉回归需验证统一设计系统下的组件在集成环境中表现一致（颜色、字体、间距、主题），并检查基线是否统一。集成测试策略上，可做"应用级集成测试"（加载真实主应用 + 各子应用，验证关键用户流程跨应用完成）与"子应用独立视觉回归"（各自基线 + 集成后基线）相结合。同时用样式隔离机制（CSS 命名空间、Shadow DOM、CSS Modules）本身降低风险，测试验证其是否生效。整体上，微前端 UI 测试要"分而治之 + 集成验证"。

答题核心是覆盖微前端特有的"样式隔离、事件通信、视觉一致性"三个集成风险，并给出"分治 + 集成验证"的测试策略。

• Tab 顺序与焦点遍历
• 快捷键与键盘操作
• 焦点陷阱（focus trap）与模态框

键盘操作与焦点管理是交互测试的重要维度，尤其对有障碍用户至关重要。验证要点包括：一是 Tab 顺序——用键盘事件（Tab/Shift+Tab）模拟遍历，验证焦点按预期顺序移动（与视觉布局一致），并覆盖到达最后一个可聚焦元素后循环或退出；二是快捷键——验证快捷键（如 Ctrl+K 打开搜索、Esc 关闭弹窗）是否触发正确行为，以及快捷键在焦点不同位置是否仍生效；三是焦点陷阱（focus trap）——验证模态框/抽屉打开时焦点被限制在对话框内（Tab 不会逃出到背景），关闭后焦点是否恢复到触发元素；四是焦点管理——验证元素获得焦点时焦点环是否可见、打开弹窗时焦点是否自动移入、关闭后是否归还焦点；五是可访问性结合——结合 aria 属性（aria-current、aria-expanded、aria-modal）断言状态，并用键盘测试验证屏幕阅读器用户的关键路径。测试时可用 userEvent.keyboard 或 fireEvent 模拟键盘事件，配合 axe-core 扫描可访问性，把"键盘操作 + 焦点管理 + ARIA 断言"整合为统一的交互测试。特别要覆盖"焦点陷阱"这类容易被普通点击测试遗漏但差异巨大的场景。

答题核心是"用键盘模拟验证焦点遍历、快捷键、焦点陷阱"，并强调与无障碍（ARIA、axe）结合。突出键盘路径对可访问性的重要性。

• 防抖/节流的时序验证
• 搜索联想与按钮连点的行为
• 滚动加载的触发与游标推进

防抖/节流场景的测试难点在于"时序性"，需要验证"延迟后的最终行为"而非即时行为。具体而言：一是搜索联想（防抖）——验证输入后不会立即发起请求，而是等待防抖窗口（如 300ms）后才请求，且快速连续输入只触发最后一次请求（用 mock 记录请求次数，配合 fake timers 控制时间）；二是按钮连点（节流/防重复）——验证连点按钮时请求只触发一次或按节流频率触发，防止重复提交；三是滚动加载（节流/阈值）——验证滚动到接近底部时触发加载，加载过程中不重复触发，加载完成后游标正确推进、能继续加载下一页；四是异步竞态——快速输入时旧请求返回晚于新请求，验证界面展示的是最新结果而非旧结果（可做乱序响应 mock）。测试时常用 vitest/jest 的 fake timers（vi.useFakeTimers）精确控制时间推进，或用真实等待配合 waitFor 验证最终状态。关键原则是"用可控的时钟/模拟时间验证时序，断言最终行为与请求次数"，而非依赖真实随机时间。

答题核心是"用可控时间（fake timers）验证防抖节流的时序，断言最终行为与请求次数"。强调防抖节流导致的竞态与重复请求验证。

• HTML5 拖放与鼠标事件模拟的难点
• 稳定模拟拖拽的手段
• 对列表重排结果的功能断言

拖拽与排序交互的自动化难点在于：拖拽依赖"原生 HTML5 拖放事件"（dragstart/dragover/drop）或"鼠标事件序列"（mousedown → mousemove → mouseup），而 jsdom 对原生拖放支持有限，真实浏览器中拖拽需要在目标元素上连续触发精确的鼠标事件，且依赖坐标计算，容易受布局/动画影响而不稳定。稳定模拟手段包括：一是用好拖拽库的测试辅助——如 react-dnd 的 test-utils、dnd-kit 提供测试工具，或使用 Playwright 的 dragTo、鼠标事件序列（mouse.move/down/move/up）在真实浏览器中模拟；二是为可拖拽元素提供 data-testid 与稳定的"可放区域"选择器；三是绕过真实拖拽、直接调用"重排逻辑"（如把拖拽抽象为"从 A 移到 B"的 action）来验证排序结果，降低对事件序列的依赖；四是断言应以"功能结果"为准——验证列表重排后的顺序（数组顺序、DOM 顺序、对应数据）、持久化结果（重排后保存的顺序）、以及拖拽后的状态（可放区域高亮、禁用项不可拖）。对真实事件序列，用 Playwright 的 mouse API 在真实浏览器中执行并等待 drop 完成，配合 waitFor 断言最终顺序。整体上，策略是"能功能断言就功能断言，需要真实拖拽时用 Playwright 真实鼠标事件 + 稳定选择器"。

答题核心是"拖拽自动化的难点在事件序列与坐标，稳定手段是功能断言优先、真实拖拽用 Playwright 鼠标事件"。强调对重排结果的断言重于对事件细节的模仿。

• 竞态场景的建模（乱序响应、重复操作）
• 竞态用例设计
• 用可控时序保证确定性

异步竞态是交互测试中最难覆盖且最易出现投入不足的领域。常见竞态场景包括：一是响应乱序——同一数据源发出多个请求，后发请求先返回、先发请求后返回，导致界面展示旧数据覆盖新数据；二是加载中重复操作——加载过程中用户再次点击/输入，触发重复请求或状态错乱；三是搜索联想竞态——输入变化时旧请求结果覆盖新输入结果。用例设计上：对不同竞态分别建模，用 mock 控制每个请求的返回延迟（resolve 顺序），让"先发的请求后返回"来重现乱序，断言界面最终展示的是最新/正确的数据；对"加载中重复操作"断言只执行一次或有正确的加载态保护。控制时序保证确定性的手段：一是用可控的 mock（手动 resolve 的 deferred/promise）精确控制每个请求完成时机，而非依赖真实网络；二是用 fake timers 控制时间；三是用固定 mock 数据使结果可预期。核心原则是"用可控的 mock 与时钟重放竞态窗口，断言最终稳定状态"，从而把非确定性的竞态变成确定性测试。同时，竞态用例应覆盖"最终正确性"与"中间状态不闪回"两个层面。

答题核心是"用可控 mock 控制响应顺序来重现竞态，断言最终正确状态"。强调把非确定性竞态通过可控时序转化为确定性测试。

• Design Token 的全局作用域
• 变更影响分析的方法
• 自动化的检测手段

Design Token（颜色、字体、间距、圆角、阴影等）是全局共享的样式变量，一处变更可能影响全站所有使用该 token 的组件/页面。自动检测影响范围的方法包括：一是"Token 引用图谱"——从代码中解析每个组件/样式引用了哪些 token（通过 CSS 变量、样式编译器、静态分析），建立"token → 使用方"的映射，变更某 token 即可反查受影响的所有组件与页面，输出影响范围清单；二是"视觉回归触发"——检测到 token 变更时，自动扩大视觉回归范围，对受影响组件/页面全量跑视觉对比，对比变更前后差异；三是"对比度/合规检查"——token 变更（尤其颜色）可能影响对比度，自动重跑对比度检查，验证无障碍合规；四是"全局样式快照"——对使用 token 的关键组件做样式快照，token 变更后对比快照识别受影响项。实践中，可在 CI 中把"token 文件变更"作为触发条件，跑增量视觉回归 + 影响分析报告，把"哪些组件会变"自动呈现给开发者与测试，从而在 token 变更破坏全局时快速定位。整体上，核心是"建立 token 到使用方的映射，用变更驱动视觉回归与影响清单"。

答题核心是"建立 token 引用图谱，用变更驱动视觉回归与影响分析"。强调 token 的全局作用域与自动化检测影响范围的手段。

• 截图存储的成本控制
• 截图的版本对比
• 审批工作流与审计

截图管理是 UI 测试规模化后的治理问题。存储成本方面：截图数量随"页面 × 视口 × 浏览器 × 状态 × 版本"增长，需控制存储——只保留"基线 + 当前差异"而非全部历史截图，压缩与去重，按策略归档（保留最近 N 个版本、清理失败批次），或使用云端托管（Chromatic/Percy）按需存储。版本对比方面：截图需要与代码版本关联，支持"同一页面不同版本并排对比"、"变更前后对比"，通过版本号/commit 号关联，便于回看"某个版本的外观"，并支持 diff 高亮（哪些区域变了）。审批工作流方面：视觉变更的截图应进入"审查 → 批准/拒绝 → 记录"的流程——批准则更新基线，拒绝则转缺陷，并记录审查人、变更原因、关联 PR，形成审计留痕；云端工具天然支持这种"diff 视图 + 一键批准"的协作流程。整体上，截图管理要"控制存储、关联版本、走审批留痕"，把它作为可治理的测试资产而非临时文件。

答题核心是"截图是需治理的资产"——控制存储成本、关联版本做对比、走审批留痕。强调截图管理的生命周期与治理。

• 视觉断言与行为断言的差异
• 各自适用的场景与粒度
• 两者结合的必要性

UI 自动化断言分为"视觉断言"与"行为断言"两类。行为断言关注"界面行为是否符合预期"——元素是否存在、是否可点击、表单提交后是否出现提示、路由是否跳转、数据是否正确渲染，通常用 Testing Library/Playwright 的 DOM 断言与状态断言实现，逻辑清晰、稳定、定位精确，适合验证交互逻辑与功能正确性。视觉断言关注"界面外观是否符合预期"——颜色、字体、间距、对齐、主题、布局是否正常，通常用快照对比/视觉回归（像素/perceptual diff）实现，能捕捉"行为正确但外观有问题"（如样式错乱、颜色错、布局溢出）的缺陷。适用场景上：行为断言用于验证功能与交互（单元/集成/E2E 的功能层），视觉断言用于验证外观与设计（视觉回归层）。二者互补——行为断言无法发现外观问题，视觉断言无法替代行为验证（外观相同但行为错误）。实践上应结合使用：在功能测试中嵌入关键视觉断言（如关键元素可见、主题正确），在视觉回归中覆盖外观，形成"行为 + 视觉"双通道保障。总之，UI 断言要"行为为主、视觉为辅，二者互补"。

答题核心是厘清"行为断言验证功能、视觉断言验证外观"的边界，并强调二者互补、不可互相替代。

• 响应式测试的视口覆盖
• 多端（移动/桌面/平板）的差异
• 真机 vs 模拟器 vs 浏览器

响应式与多端 UI 测试覆盖"视口变化"与"平台差异"两个维度。响应式方面：以断点为单元覆盖代表视口（移动/平板/桌面），在每个断点验证布局合理（无溢出、无横向滚动、关键元素可见），并结合视觉回归对比外观。多端方面：需区分"逻辑像素响应"与"平台差异"——同一视口在 iOS Safari、Android Chrome、桌面浏览器上存在渲染差异，需覆盖主流浏览器与 WebView；对移动端还涉及设备像素比（DPR）、触摸交互、安全区（刘海屏）、字体缩放等。执行手段上：用浏览器视口模拟（Playwright 的 device 模拟）覆盖大多数响应式场景，速度快、成本低；对平台关键差异（如 iOS 特有渲染、WebView 内嵌）用真机/云真机（BrowserStack、Sauce Labs）做抽样验证。测试策略是"浏览器模拟为主（覆盖断点与响应式）、真机/云真机为辅（覆盖平台差异）"，并配合布局断言 + 视觉回归双重校验。整体上，多端测试要"用模拟覆盖广度、用真机覆盖关键差异"，控制成本与覆盖的平衡。

答题核心是区分"响应式（视口）"与"多端（平台）"两个维度，用浏览器模拟为主、真机为辅的策略覆盖，并强调布局 + 视觉双重校验。

• Mock 的替身边界与风险
• 不同层级的渲染取舍
• 平衡策略

组件 Mock 与真实渲染的取舍本质是"测试隔离度"与"测试真实性"的权衡。Mock 的优点：隔离外部依赖（网络、第三方库、时间、路由），使测试快速、确定、聚焦于被测组件自身逻辑，定位精确；缺点：过度 mock 会掩盖真实的集成问题（如 mock 接口与真实接口不一致、组件间 props 不匹配、第三方库行为差异），导致"单元测试全绿但集成出错"。真实渲染的优点：验证真实行为，发现集成问题；缺点：慢、不稳定、依赖外部环境。平衡策略是"按测试层级选择替身边界"：单元测试（组件逻辑）用 mock 隔离外部依赖，专注组件内部行为；集成测试（组件间交互）用真实组件 + 少量 mock（如只 mock 网络），验证组件协作；E2E 用真实渲染 + 真实接口（或契约 stub），验证端到端流程。原则是"替身边界尽量小而真实"——mock 序言远离被测目标的依赖，尽量不 mock 被测组件自身或其关键子组件；对关键集成点（如 API 契约、路由）用契约测试或真实环境验证。从而在"测试隔离"与"集成置信度"之间取得平衡。

答题核心是"按测试层级选择替身边界"，单元测试 mock 隔离、集成测试真实渲染、E2E 全真实，替身边界尽量小而真实。

• 第三方组件的不确定性来源
• 隔离与打桩的手段
• 保留少量真实集成验证

地图、支付 SDK、广告等第三方组件具有不确定性（网络、密钥、外部服务、渲染结果不可控），不适合在常规 UI 测试中真实加载。测试策略是"隔离 + 打桩 + 少量真实验证"。隔离与打桩手段包括：一是模块 mock——在测试中 mock 第三方 SDK 模块（如 jest.mock 地图库、Playwright 的 route 拦截），用桩替代真实 SDK，返回固定的渲染结果或空壳，使测试确定；二是接口拦截——用 Playwright 的 page.route 拦截第三方资源请求（脚本、图片、接口），返回 stub 响应，避免加载真实外部依赖；三是占位/桩组件——用真实组件的简单占位替换第三方组件，验证"第三方组件所在位置与周边布局"而非其内部渲染；四是环境隔离——用测试专用 key、禁用真实支付/广告请求，避免误触发真实交易/曝光。同时保留"少量真实集成验证"——在冒烟/预发布阶段对关键第三方集成做一次真实验证（如支付回调、地图加载），确认与真实 SDK 的兼容性，抵消"过度 mock 掩盖真实问题"的风险。整体上，常规 UI 测试以 mock 打桩为主，关键集成用少量真实验证兜底。

答题核心是"常规测试隔离打桩第三方组件，关键集成用少量真实验证兜底"，平衡确定性与集成置信度。

• 设计系统变更的来源与影响
• 变更驱动的 UI 回归机制
• 联动自动化的实现

UI 测试与设计系统联动的核心是"用设计系统的变更驱动 UI 回归"，让组件库/Design Token 的每次变更自动触发受影响范围的视觉与功能回归。联动机制包括：一是变更检测——监测组件库（Storybook 代码、组件源码）与 Design Token 文件的变更，作为回归的触发条件；二是组件级回归——组件库变更时，自动对 Storybook 的每个 story 跑视觉回归（Chromatic），定位受影响组件及其外观变化；三是影响范围传导——通过 token 引用图谱/组件依赖分析，把组件库变更传导到"使用该组件的页面"，对受影响页面跑页面级视觉回归，验证"组件变更是否破坏页面布局"；四是统一基线——组件库与使用方共享一致的视觉基线，变更组件后对比基线，识别"有意变更"（需批准）与"真实破坏"（需修复）；五是回归报告——变更后生成影响范围报告，呈现"哪些组件、哪些页面受影响，差异在哪"，供设计/测试审查。整体上，联动把"设计系统变更"变成"自动化驱动的回归信号"，实现"改一处、测一片"，既保证组件库质量，也保证下游页面不被破坏。

答题核心是"用设计系统变更驱动 UI 回归"，通过变更检测、组件级回归、影响传导、统一基线、回归报告形成联动闭环。

• 路由参数与组件状态的同步
• 前进/后退的浏览器历史联动
• 深链接直达的状态恢复

URL 与组件状态的同步测试验证"URL 是状态的一部分，浏览器导航与状态联动"。验证要点包括：一是路由参数同步——组件状态（如筛选、分页、搜索词）应反映到 URL 参数（query/params），测试验证"修改状态 → URL 更新"与"修改 URL → 状态更新"双向同步，以及刷新页面后状态保持；二是浏览器前进/后退——验证前进/后退时组件状态按 URL 恢复（如从列表页进详情再后退回列表，筛选条件保持），以及历史栈中的状态正确还原；三是深链接直达——验证通过 URL 直接访问（分享链接、书签、刷新）时，组件根据 URL 参数恢复正确状态（如打开某筛选后的列表、某 tab、某详情），而不是恢复到默认态；四是状态兜底——验证 URL 参数缺失/非法时组件的容错（默认值、错误处理）。测试时用 Playwright 的 page.goto 直达 URL、page.goBack/goForward 模拟前进后退、拦截路由变化断言 URL 与状态，并配合断言"刷新后状态保持"。整体上，URL 同步测试覆盖"双向同步、历史导航、深链接恢复"三个链路，确保"任何入口进入都能呈现正确状态"。

答题核心是"URL 是状态的一部分"，覆盖双向同步、前进后退历史联动、深链接直达恢复三个链路，并验证容错。