test

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Establish systematic confidence in UI behavior through the right mix of visual regression, interaction testing, and accessibility assertions.

Treat testing as a design input, not a post-ship safety net. The goal is not maximum coverage; it is catching the bugs that matter most without drowning the team in maintenance.

Consult the accessibility testing reference when the testing strategy needs automated axe checks, screen reader validation, or keyboard traversal tests. Consult the component accessibility reference when testing custom components for focus management, ARIA correctness, and keyboard behavior. Consult the interaction design reference when validating workflows under stress, error, or edge-case conditions. Consult the error-recovery reference when testing validation behavior, recoverable field errors, or abandonment paths. Consult the loading feedback and perceived performance reference when testing loading states, skeletons, stale-data cues, or perceived-performance behavior.

通过合理搭配视觉回归、交互测试和可访问性断言，系统性地建立对 UI 行为的信心。

将测试视为设计输入，而非发布后的安全网。目标不是最大化覆盖率，而是在不让团队陷入维护重负的前提下，捕获最重要的缺陷。

当测试策略需要自动执行 axe 检查、屏幕阅读器验证或键盘遍历测试时，请参阅可访问性测试参考文档。当测试自定义组件的焦点管理、ARIA 正确性和键盘行为时，请参阅组件可访问性参考文档。当验证工作流在压力、错误或边缘条件下的表现时，请参阅交互设计参考文档。当测试验证行为、可恢复的字段错误或用户放弃路径时，请参阅错误恢复参考文档。当测试加载状态、骨架屏、陈旧数据提示或感知性能行为时，请参阅加载反馈与感知性能参考文档。

MANDATORY PREPARATION

强制准备

Users start this workflow with

/test

. Once this skill is active, load $frontend-design — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow that protocol before proceeding — if no design context exists yet, you MUST load $setup first. Additionally gather: the most common UI bugs currently escaping to production, the team's tolerance for test maintenance, and which parts of the UI change most frequently.

用户以

/test

开始此工作流。此 skill 激活后，加载 $frontend-design——其中包含设计原则、反模式以及 Context Gathering Protocol。继续之前必须遵循该协议——如果尚不存在设计上下文，则必须先加载 $setup。此外还需收集：目前最常漏到生产环境的 UI 缺陷、团队对测试维护工作的接受程度，以及哪些 UI 区域变更最频繁。

Assess Testing Needs

评估测试需求

Identify what is breaking and what should be caught:

Map bug escape routes:
- Visual regressions (unintended layout shifts, broken spacing, missing assets)
- Interaction failures (buttons that do nothing, broken forms, dead links)
- State bugs (stale data, race conditions, incorrect loading states)
- Accessibility defects (missing labels, keyboard traps, color contrast failures)
- Cross-browser or cross-device inconsistencies
Evaluate current coverage:
- What is already tested? What is tested but provides no signal?
- Which tests fail randomly and get ignored (flaky tests erode trust)
- How long does the test suite take? Slow suites get bypassed.
Prioritize by risk and churn:
- High-traffic user paths (checkout, signup, core workflows)
- UI surfaces that change frequently (design-system components)
- Areas with known historical bugs
- Accessibility-critical surfaces (forms, navigation, modals)

确定当前出现了什么问题，以及测试应捕获哪些问题：

梳理缺陷逃逸路径：
- 视觉回归（非预期的布局偏移、间距破坏、资源缺失）
- 交互故障（按钮无响应、表单失效、链接失效）
- 状态缺陷（陈旧数据、竞态条件、错误的加载状态）
- 可访问性缺陷（缺少标签、键盘陷阱、颜色对比度不达标）
- 跨浏览器或跨设备不一致
评估现有覆盖率：
- 已经测试了什么？哪些测试虽然存在，却无法提供有效信号？
- 哪些测试会随机失败并被忽略？不稳定的测试会侵蚀团队对测试的信任
- 测试套件需要运行多久？速度缓慢的测试套件往往会被绕过
按风险和变更频率确定优先级：
- 高流量用户路径（结账、注册、核心工作流）
- 变更频繁的 UI 界面（设计系统组件）
- 存在已知历史缺陷的区域
- 对可访问性要求较高的界面（表单、导航、模态框）

Testing Dimensions

测试维度

Visual Regression

视觉回归

Catch unintended visual changes before they ship.

What to capture:

Component states (default, hover, focus, active, disabled, loading, error)
Full-page layouts at representative breakpoints
Cross-browser rendering differences (focus styles, form controls, fonts)

Baseline discipline:

Treat baselines as team assets, not personal screenshots
Review intentional changes in pull requests, not after merge
Re-baseline immediately after intentional design updates to prevent noise

Anti-flake practices:

Wait for fonts, images, and animations to settle before capturing
Mock or freeze dynamic content (timestamps, random data, animations)
Use deterministic test data and fixed viewport sizes
Isolate tests from network variability; stub API responses

Scope boundaries:

Test design-system components exhaustively
Test page layouts at a few key breakpoints, not every pixel width
Do not test third-party widgets you do not control (embeds, ads)

在发布前捕获非预期的视觉变化。

需要捕获的内容：

组件状态（默认、悬停、聚焦、激活、禁用、加载、错误）
代表性断点下的完整页面布局
跨浏览器渲染差异（焦点样式、表单控件、字体）

基线管理原则：

将基线视为团队资产，而不是个人截图
在 pull request 中审查有意变更，而不是合并后才审查
有意更新设计后立即重建基线，防止产生噪声

防止测试不稳定的实践：

捕获前等待字体、图片和动画稳定
模拟或冻结动态内容（时间戳、随机数据、动画）
使用确定性测试数据和固定视口尺寸
隔离测试与网络波动；使用桩 API 响应

范围边界：

全面测试设计系统组件
页面布局只需在几个关键断点测试，无需覆盖每个像素宽度
不要测试无法控制的第三方组件（嵌入内容、广告）

Interaction Testing

交互测试

Validate that user actions produce correct outcomes.

Component-level interactions:

Form submission, validation, and error recovery
Modal open/close, focus trapping, and escape behavior
Dropdown, accordion, tab, and disclosure state transitions
Button actions and their side effects

User flow validation:

Multi-step workflows (checkout, onboarding, wizard flows)
Navigation and routing behavior
State persistence across browser back/forward
Concurrent actions (rapid clicking, double submissions)

Test data strategy:

Use realistic but deterministic data
Cover edge cases (empty inputs, maximum lengths, special characters)
Include error-state responses, not just happy-path stubs

验证用户操作是否产生正确结果。

组件级交互：

表单提交、验证和错误恢复
模态框打开与关闭、焦点陷阱和 Escape 行为
下拉菜单、手风琴、标签页和折叠面板的状态转换
按钮操作及其副作用

用户流程验证：

多步骤工作流（结账、引导、向导流程）
导航和路由行为
浏览器前进与后退操作之间的状态持久性
并发操作（快速点击、重复提交）

测试数据策略：

使用真实但确定的数据
覆盖边缘情况（空输入、最大长度、特殊字符）
包含错误状态响应，而不只是只模拟成功路径

Accessibility Assertions

可访问性断言

Embed accessibility validation into the testing pipeline.

Automated checks (run on every build):

axe-core or equivalent for WCAG rule violations
Color contrast minimums (4.5:1 normal text, 3:1 large text / UI components)
Semantic HTML validation (heading order, landmark regions, label associations)
Focus management (visible focus indicators, logical tab order)

Keyboard traversal tests:

Tab through entire flows without a mouse
Validate that all interactive elements are reachable
Confirm that focus traps in modals and escape routes work
Test that skip links and bypass blocks function

Screen reader smoke tests (for critical paths):

Announcement of dynamic content changes (live regions)
Meaningful accessible names and descriptions
State announcements (expanded/collapsed, selected, required)
Error messaging that surfaces to assistive technology

Motion and animation:

Verify
```
prefers-reduced-motion
```
is respected
Confirm no seizure-inducing flashing (under 3 flashes per second)

将可访问性验证嵌入测试流水线。

自动化检查（每次构建时运行）：

使用 axe-core 或同类工具检查 WCAG 规则违规
颜色对比度最低要求（普通文本 4.5:1；大号文本或 UI 组件 3:1）
语义化 HTML 验证（标题层级、landmark 区域、标签关联）
焦点管理（可见焦点指示器、合理的 Tab 顺序）

键盘遍历测试：

不使用鼠标，通过 Tab 键遍历整个流程
验证所有交互元素均可访问
确认模态框中的焦点陷阱和退出路径正常工作
测试跳转链接和 bypass 区域是否有效

屏幕阅读器冒烟测试（用于关键路径）：

动态内容变化的播报（live region）
有意义的可访问名称和描述
状态播报（展开或折叠、选中、必填）
能够被辅助技术捕获的错误信息

动效与动画：

验证是否遵循
```
prefers-reduced-motion
```
确认不存在可能诱发癫痫的闪烁（每秒少于 3 次）

Test Pyramid for UI

UI 测试金字塔

Balance speed, confidence, and maintenance cost:

Layer	Scope	Speed	Purpose
Unit (component)	Single component, mocked dependencies	Fast (< 1s)	Logic, rendering, prop handling
Integration (component + context)	Component with real providers, stubs	Medium (< 10s)	Interaction behavior, state transitions
End-to-end (full browser)	Real browser, real network or stubs	Slow (< 30s per test)	Critical user flows, cross-page behavior
Visual regression	Screenshot comparison	Medium (parallelizable)	Unintended visual changes

Guidance:

Push tests down the pyramid when possible. A component test is faster and more precise than an E2E test for button behavior.
Reserve E2E for user journeys that span multiple pages or require real browser behavior (routing, auth, payment).
Run visual regression in CI on every pull request, not just before release.

在速度、信心和维护成本之间取得平衡：

层级	范围	速度	目的
单元（组件）	单个组件、模拟依赖项	快（< 1 秒）	逻辑、渲染、属性处理
集成（组件 + 上下文）	使用真实 Provider 和桩服务的组件	中等（< 10 秒）	交互行为、状态转换
端到端（完整浏览器）	真实浏览器、真实网络或桩服务	慢（每个测试 < 30 秒）	关键用户流程、跨页面行为
视觉回归	截图对比	中等（可并行执行）	非预期的视觉变化

指导原则：

尽可能将测试下移到测试金字塔更底层。对于按钮行为，组件测试比 E2E 测试更快、更精确。
仅将 E2E 用于跨多个页面的用户旅程，或需要真实浏览器行为的功能（路由、身份验证、支付）。
在 CI 中为每个 pull request 运行视觉回归测试，而不是只在发布前运行。

Tool Selection

工具选择

Match the tool to the team's stack and the testing layer:

Need	Strong options	Considerations
Component unit/integration	Vitest + Testing Library, Jest + Testing Library	Framework-agnostic; prefer Testing Library queries that mirror user behavior
End-to-end critical flows	Playwright, Cypress	Playwright for speed and cross-browser parallelism; Cypress for simpler setup
Visual regression	Chromatic, Loki, Playwright screenshots, Percy	Chromatic for Storybook integration; Playwright for in-house baseline management
Accessibility automation	axe-core, @axe-core/react, Playwright + axe	Integrate into CI; treat as warnings, not blockers, until baseline is clean
Interaction / user flow	Playwright, Cypress, Storybook Test Runner	Storybook Test Runner for isolated component interactions; Playwright/Cypress for full flows

Pragmatic rules:

Prefer one E2E tool and one component test tool. Tool proliferation fragments expertise.
If the project uses Storybook, add interaction tests there before adding a separate component test suite.
Integrate accessibility checks into the existing test runner, not as a separate tool chain.

根据团队技术栈和测试层级选择工具：

需求	推荐选项	注意事项
组件单元与集成测试	Vitest + Testing Library、Jest + Testing Library	与框架无关；优先使用模拟用户行为的 Testing Library 查询
关键流程端到端测试	Playwright、Cypress	Playwright 速度更快且支持跨浏览器并行；Cypress 设置更简单
视觉回归	Chromatic、Loki、Playwright screenshots、Percy	Chromatic 适合与 Storybook 集成；Playwright 适合内部基线管理
可访问性自动化	axe-core、@axe-core/react、Playwright + axe	集成到 CI；在基线清理完成前，将问题视为警告而非阻断项
交互与用户流程	Playwright、Cypress、Storybook Test Runner	Storybook Test Runner 适合隔离的组件交互；Playwright/Cypress 适合完整流程

务实原则：

优先选择一种 E2E 工具和一种组件测试工具。工具过多会分散团队精力。
如果项目使用 Storybook，应先在其中添加交互测试，再创建独立的组件测试套件。
将可访问性检查集成到现有测试运行器中，而不是建立独立的工具链。

Anti-Patterns

反模式

Test implementation details: Assert on what the user sees and does, not internal state or CSS class names.
Ignore flaky tests: A flaky test is worse than no test. Fix or delete it immediately.
Test everything through E2E: Slow suites discourage running tests. Push logic down to component tests.
Snapshot everything: Snapshot tests catch changes but do not explain intent. Use them sparingly for markup stability, not for behavior.
Separate accessibility testing from the main pipeline: Accessibility checks that run manually once per sprint find nothing consistently.
Mock the browser environment: Use a real browser for E2E and visual regression. jsdom and happy-dom are fine for component logic, not for layout or interaction fidelity.
Test third-party widgets: Do not baseline or assert on embeds, maps, ads, or chat widgets you do not control.
Skip cross-browser testing: At minimum verify focus styles, form controls, and layout in the browsers your users actually use.
Leave baselines stale: An outdated baseline hides regressions. Re-baseline after intentional visual changes.

测试实现细节：断言用户看到和执行的行为，而不是内部状态或 CSS 类名。
忽略不稳定的测试：不稳定的测试比没有测试更糟糕。应立即修复或删除。
通过 E2E 测试所有内容：缓慢的测试套件会降低运行测试的意愿。将逻辑下移到组件测试中。
为所有内容创建快照：快照测试能够发现变化，却无法解释变更意图。仅将其少量用于标记结构稳定性，不要用于行为测试。
将可访问性测试与主流水线分离：每个 sprint 只手动运行一次的检查无法持续发现问题。
模拟浏览器环境：E2E 和视觉回归应使用真实浏览器。jsdom 和 happy-dom 适合组件逻辑测试，但无法保证布局和交互的真实性。
测试第三方组件：不要为无法控制的嵌入内容、地图、广告或聊天组件建立基线或编写断言。
跳过跨浏览器测试：至少验证用户实际使用的浏览器中的焦点样式、表单控件和布局。
任由基线过期：过时的基线会隐藏回归问题。有意进行视觉变更后应立即重建基线。