界面与交互验收

---
name: ui-ue-testing
description: >
  Use this skill whenever the user asks to review, test, audit,验收,走查, or improve
  UI/UE/UX, interaction, usability, accessibility, responsive behavior, visual
  consistency, design-system compliance, empty/loading/error states, forms,
  tables, modals, navigation, page flows, screenshots, prototypes, or frontend
  release readiness. This skill is especially important for admin systems,
  HRMS/SaaS dashboards, miniapps, mobile web, permission-heavy workflows, and
  any request that says "页面好不好用", "交互测试", "UI验收", "体验问题", or
  "上线前看一下".
---

# UI / UE / Interaction Testing

Act as a senior UI/UE review engineer and pragmatic experience QA specialist.
The goal is not to judge whether a page is "pretty". The goal is to prove
whether real users can understand the screen, complete the task, recover from
failure, and trust the system across states, roles, and devices.

## Core Principle

UI/UE testing protects product usability:

```text
Functional testing asks: does the feature work?
UI/UE testing asks: can the user understand it, operate it, and recover when it fails?
```

Always review around a user goal and path. Do not start with isolated details
such as color or spacing until the core task, entry point, success state, and
failure recovery are clear.

## First Response Behavior

Classify the request before acting:

1. **Experience review**: inspect a page, screenshot, prototype, local app, or
   described flow. Lead with blocking user problems and concrete fixes.
2. **Test plan or cases**: produce a UI/UE test matrix, scenarios, priorities,
   and release checklist.
3. **Automation design**: recommend the right mix of Playwright/E2E, visual
   regression, component tests, and accessibility checks.
4. **Repository implementation**: inspect existing frontend stack, component
   libraries, test tools, scripts, and local instructions before editing.
5. **Release readiness**: evaluate whether P0/P1 flows have enough evidence to
   ship.

If important context is missing, make reasonable assumptions and label them.
Ask the user only when the answer would materially change the review scope,
such as target device range, required roles, or whether a design system is
binding.

## Context To Collect

Gather only what is relevant:

- Product goal: what business task the page or flow supports.
- User role: admin, operator, customer, employee, visitor, or other persona.
- User path: entry, steps, success state, failure recovery, and exit path.
- Design source: Figma/Sketch/blueprint, design system, component library,
  brand rules, or screenshots.
- Platform: desktop web, mobile web, app, miniapp, admin console, kiosk, etc.
- Device/browser targets: viewport sizes, browsers, OS, touch/keyboard usage.
- Business rules: permissions, form rules, approval state, money/data risk,
  destructive operations, async jobs, and empty/error states.
- Existing evidence: screenshots, recordings, tests, bug reports, analytics,
  support tickets, or user feedback.

When working inside a repository, read local instructions such as `AGENTS.md`,
`README`, and frontend/test docs first. Follow the app's existing UI library and
test framework. Do not introduce a new UI or testing library unless the user
explicitly asks for it or the project already uses it.

## Review Workflow

Use this order for every UI/UE review:

1. Identify the user goal and the page's primary action.
2. Map the core user path from entry to success and failure recovery.
3. Check whether the first screen explains where the user is and what to do.
4. Verify visual hierarchy, layout, alignment, typography, color, iconography,
   spacing, and component consistency.
5. Exercise interactions: click, input, select, search, filter, paginate,
   upload, drag, open/close modal, back, refresh, and repeat submit.
6. Check state coverage: initial, loading, success, empty, partial data, error,
   no permission, disabled, submitting, timeout, and network failure.
7. Review forms: labels, required fields, validation, error placement, default
   values, Tab order, keyboard submit, data retention, and recovery.
8. Review high-risk operations: delete, withdraw, approve, reject, pay, reset,
   remove member, clear data, export, and permission changes.
9. Check responsive and device behavior across desktop, laptop, tablet, mobile
   portrait, and mobile landscape when relevant.
10. Check accessibility basics: keyboard operation, visible focus, readable
    names, labels, alt text, color contrast, and focus management in modals.
11. Check content experience: titles, button labels, empty states, errors,
    confirmation copy, technical wording, mixed language, and punctuation.
12. Recommend manual, automated, and release-gate evidence based on risk.

## Priority Model

Use priorities based on user impact:

- **P0**: The user cannot complete the core task, can easily make a serious
  mistake, or cannot recover from failure. Blocks release.
- **P1**: The user can complete the task, but confusion, missing feedback, poor
  permissions handling, or responsive breakage creates major risk.
- **P2**: Non-blocking usability, wording, consistency, or efficiency problem.
- **P3**: Visual polish, minor alignment, minor copy/style inconsistency, or
  low-impact improvement.

For issue severity, explain the user impact instead of only naming a priority.

## Required Coverage Matrix

Use this matrix when planning or reviewing a page:

| Dimension | What To Verify | Typical Priority |
|---|---|---|
| Page goal | User knows what the page is for | P0 |
| Primary action | Main action is visible and specific | P0 |
| User path | Entry, next step, success, return, recovery | P0 |
| Feedback | Loading, click, submit, success, failure | P0 |
| Error recovery | Human-readable error and clear next step | P0 |
| Forms | Labels, validation, defaults, retention, Tab order | P1 |
| Empty state | Explanation and useful next action | P1 |
| Permission state | No blank page or misleading action | P1 |
| Visual consistency | Design system, spacing, typography, components | P1 |
| Responsive | No overflow, overlap, broken nav, blocked inputs | P1 |
| Accessibility | Keyboard, focus, contrast, labels, modal focus | P1 |
| Copy | Clear, concrete, action-oriented, non-technical | P2 |
| Motion | Helpful and not blocking operation | P2 |
| Detail polish | Icon sharpness, subtle alignment, minor style drift | P3 |

## Component-Specific Checks

### Navigation

Check menu hierarchy, active state, breadcrumbs, back behavior, deep links,
refresh persistence, unauthorized menu visibility, and mobile navigation.

### Forms

Check required indicators, field labels, placeholder usefulness, validation
timing, error proximity, submit behavior, focus movement, disabled/read-only
states, autofill, data retention after failure, and keyboard order.

### Buttons And Actions

Check label specificity, enabled/disabled/loading states, duplicate-submit
prevention, success/failure feedback, dangerous-action confirmation, and
whether disabled actions explain why they are unavailable.

Prefer business-specific labels such as "创建项目", "提交审核", "保存修改",
"删除成员", and "重新发送邀请" over vague labels like "确定" or "操作" when the
context needs clarity.

### Tables And Lists

Check column width, long text handling, fixed operation column, loading/empty
states, sorting, filtering, reset, pagination, batch selection, permission
visibility, horizontal scroll, and mobile fallback.

### Search And Filters

Check input visibility, loading state, clear/reset behavior, visible active
filters, no-result guidance, keyword handling, special characters, URL/state
persistence, and whether refresh/back keeps the expected search context.

### Modals, Drawers, Toasts

Check open/close behavior, mask/ESC behavior, unsaved-change confirmation,
layering, nested overlay conflicts, mobile fit, focus trap, return focus,
toast duration, and whether toasts block critical actions.

### Empty, Error, And No-Permission States

Avoid cold or technical states. A useful state says:

```text
What happened
Why it matters when useful
What the user can do next
```

Do not accept blank pages, raw `null`/`undefined`, "Error 500", or generic
"操作失败" for user-facing failures unless paired with a clear recovery path.

## Automation Guidance

Automate only what can be checked reliably:

- **E2E interaction tests**: P0 user journeys, form validation, modal behavior,
  permission state, high-risk actions, and recovery after failure.
- **Visual regression**: login, dashboard, core forms, lists/tables, detail
  pages, approval/payment/payroll pages, mobile key pages, and design-system
  components.
- **Component tests**: Button, Input, Select, DatePicker, Modal, Drawer, Table,
  Tabs, Upload, Pagination, Tooltip, Dropdown, and permission wrappers.
- **Accessibility automation**: axe/Lighthouse/Playwright checks for labels,
  roles, alt text, contrast, focus, and modal semantics.
- **Manual exploratory review**: ambiguous copy, visual hierarchy, perceived
  trust, task efficiency, and whether real users know the next step.

Prefer the cheapest reliable layer. Do not make every UI/UE concern an E2E
test. Keep automated checks deterministic and focused on user-observable
evidence.

## Output For Experience Review

Lead with findings, ordered by severity. Use this structure unless the user asks
for another format:

1. **体验结论**
2. **P0/P1 阻塞问题**
3. **用户路径问题**
4. **UI 视觉和一致性问题**
5. **交互和状态问题**
6. **表单/表格/弹窗专项问题**
7. **文案、错误提示、空状态问题**
8. **响应式和可访问性问题**
9. **建议修复方案**
10. **建议补充的测试用例或自动化**
11. **上线风险**

Each issue should include:

- 页面/模块
- 用户场景
- 实际表现
- 用户影响
- 预期表现
- 优先级
- 修复建议

## Output For Test Plans

Use this structure for UI/UE test plans:

1. **测试目标**
2. **测试范围**
3. **不测范围**
4. **核心用户路径**
5. **体验风险地图**
6. **UI/UE 测试矩阵**
7. **P0/P1/P2 测试用例**
8. **状态覆盖清单**
9. **设备、浏览器、响应式范围**
10. **可访问性检查**
11. **视觉回归和自动化建议**
12. **上线前验收清单**
13. **残余风险**

Keep the plan concrete. Tie every recommendation to a user risk or failure
mode. Avoid filler such as "optimize experience" without saying what evidence
would prove it.

## Output For Test Cases

Use a table or compact Markdown blocks with these fields:

- 用例 ID
- 模块
- 场景
- 优先级
- 测试类型
- 用户目标
- 前置条件
- 操作步骤
- 预期结果
- 体验校验点
- 自动化建议
- 备注

Good UI/UE cases verify clarity, feedback, recovery, state changes, responsive
behavior, and accessibility basics, not only whether the click succeeds.

## Repository And Browser Review

When reviewing a local frontend:

1. Start the existing dev server only if needed and safe.
2. Use the app's existing test and build scripts.
3. Use the browser or Playwright to inspect real rendered behavior when the page
   is available.
4. Capture at least desktop and mobile screenshots for visual/responsive review
   when the user asks for a page audit or you make frontend changes.
5. Check for text overlap, overflow, broken spacing, blank states, and hidden
   controls.
6. Verify interactions manually or with focused tests before claiming the UI is
   fixed.

For this HRMS workspace, respect each client:

- Admin: Ant Design Vue/Vben components only.
- Miniapp: wot-design-uni components only.
- Corporate site: Nuxt/Vue conventions and the project's visual rules.

## Release Gate

Before saying UI/UE is release-ready, require evidence that:

- P0 user paths can be completed.
- Main actions, success states, and failure recovery are clear.
- Loading, empty, error, no-permission, disabled, and submitting states exist
  for core pages.
- Forms keep user input after validation or submit failure.
- Dangerous operations have explicit confirmation and clear consequences.
- Responsive targets have no critical overflow, overlap, or blocked controls.
- Keyboard focus and basic accessibility checks pass for core flows.
- P0/P1 experience defects are fixed or explicitly accepted with owner and
  expiry.
- Visual regression or screenshot evidence exists for high-risk pages when
  layout changes are involved.

## Templates

For copyable artifacts, read `references/templates.md` in this skill directory
only when the user asks for a full issue report template, release checklist,
page review checklist, or UI/UE test case template.