企业级 Web UAT 验收测试

SKILL.md

---
name: enterprise-web-uat
description: 面向企业 Web 系统、SaaS 管理后台、内部业务平台、多角色权限系统的通用、抽象、隐私安全 UAT 验收测试流程。适用于规划、设计、执行、复核、审计和打包自动化/半自动化 Web UAT，强调需求追踪矩阵 RTM、角色权限覆盖、真实证据、可复现缺陷、最终审核关卡和交付包。本 Skill 不包含任何项目专属业务名称、客户数据、凭证、URL 或本机路径。
---

# 企业级 Web UAT 验收测试

这个 Skill 用于指导 Agent 执行**可交付、可复盘、隐私安全的企业级 Web UAT**。它是一套通用方法论，不是某个具体项目的测试脚本。

适用对象包括：带有菜单、表单、表格、流程、角色权限、配置项、集成、后台任务、报表、文件、通知、审计日志或数据生命周期规则的 Web 系统。

## 核心原则

1. **抽象通用**：除非用户在当前任务中明确提供，否则不要假设具体客户、模块名、URL、账号、租户或业务流程。
2. **隐私优先**：不要发布、打包、记录或报告密钥、Cookie、Token、密码、私有 URL、个人数据、浏览器存储状态文件或客户专属实现细节。
3. **需求驱动**：UAT 的目标是证明验收覆盖，不是随机点页面。
4. **证据驱动**：每个结论都必须有执行记录、截图、DOM/控件清单、必要的控制台/网络观察以及可复现步骤支撑。
5. **安全自动化**：未经明确授权，不执行删除、付款、外发通知、生产配置变更、法律签署等高风险或不可逆操作。
6. **尊重正常登录**：如果遇到密码、MFA、SSO、扫码、验证码等登录步骤，让用户在专用浏览器中手动完成；不要绕过认证。

## 强制流程

除非用户明确要求只做小范围检查，否则按以下顺序执行：

`资料输入 → 验收基线 → 业务理解 → RTM 需求追踪矩阵 → UAT 用例设计 → 授权与边界确认 → 执行留证 → 问题记录 → 初版报告 → 最终审核 → review-fixed 修正版交付包`

如果某一步因为资料、账号、环境或数据不足无法完成，必须标记为 `Blocked`、`To-confirm` 或 `OutOfScope`。不要把缺少证据的内容默认为通过。

## 启动参数与必填信息

### 最小启动参数

只要用户要求开始一次 Web UAT，至少需要明确以下信息；缺失时先一次性追问，或在报告中标记为阻塞/待确认：

| 参数 | 是否必填 | 说明 | 缺失处理 |
|---|---:|---|---|
| `target_url` / 目标地址 | 是 | 被测系统入口、页面地址或环境入口 | 无法访问时标记 `Blocked` |
| `scope` / 测试范围 | 是 | 要验收的模块、页面、流程、角色或用户故事 | 不明确时先做范围澄清 |
| `environment` / 环境信息 | 是 | 测试、预发、演示或生产类环境，以及版本/构建号（如有） | 未知时记录为风险 |
| `login_method` / 登录方式 | 是 | 测试账号、人工登录、SSO/MFA/扫码登录或免登录页面 | 无法登录时标记 `Blocked` |
| `safety_boundary` / 安全边界 | 是 | 是否允许新增、编辑、删除、导入导出、发通知、跑任务等 | 未授权的高风险操作默认禁止 |
| `output_required` / 交付物 | 是 | 只要结论、问题清单、完整报告、证据包或 ZIP 交付包 | 未说明时默认输出简版结论+问题清单 |

### 完整企业级 UAT 推荐参数

做正式交付型 UAT 时，尽量补齐：

| 参数 | 用途 |
|---|---|
| `source_docs` | 操作手册、PRD、合同/SOW、变更单、验收准则、接口文档 |
| `roles` | 角色、权限、组织/数据范围、测试账号或人工登录安排 |
| `test_data_rules` | 可使用的数据、禁止触碰的数据、清理规则 |
| `acceptance_criteria` | 明确的验收标准；没有时从资料中抽取并标记假设 |
| `browser_matrix` | 浏览器、分辨率、设备、兼容性要求 |
| `integration_boundaries` | 外部系统、通知、文件、异步任务、审计日志等边界 |
| `risk_constraints` | 支付、删除、生产配置、法律签署、外发通知等禁止项 |
| `package_format` | HTML、Markdown、CSV、JSON、截图证据、ZIP 等交付格式 |

### 参数缺失处理规则

- 最小启动参数缺失时，不要直接开始正式 UAT；先追问或标记 `Blocked`。
- 完整企业级参数缺失时，可以继续执行已授权范围，但必须在 RTM、用例和报告中标记风险。
- 用户只给 URL 时，可以先做非破坏性页面探查和范围草案，不得执行提交、删除、外发、支付、发布等动作。
- 用户明确要求“全量 UAT”时，必须要求或整理范围、角色、资料、数据和安全边界；不能把“全量”理解为随机点击所有按钮。

## 1. 资料输入

按当前任务需要收集或确认：

- 目标环境与访问地址
- 操作手册、PRD、合同/SOW、变更单、验收标准或用户故事列表
- 与 GUI 流程相关的接口/API 文档
- 角色权限矩阵
- 测试账号或安全登录方式
- 允许使用的测试数据规则
- 浏览器/设备要求
- 高风险边界和明确禁止的操作

如果资料不可用，先记录假设和风险，再执行。

## 2. 验收基线

把来源资料转成验收准则清单。

必填字段：

`准则编号｜来源｜原始描述｜验收准则｜适用角色｜模块/流程｜优先级｜验证方式｜是否阻断验收｜备注`

规则：

- 每条准则必须能测试、能确认，或明确标记为范围外。
- 文档之间冲突时，记录为 `DocumentConflict` / `To-confirm`。
- 不要把缺失的业务规则自行脑补成事实。

## 3. 业务理解

自动化前先形成简洁业务模型：

- 菜单与导航结构
- 业务对象及生命周期
- 核心端到端流程
- 角色、权限与数据范围边界
- 配置项依赖关系
- 集成、异步任务、通知、导入导出、审计日志
- 高风险操作及安全替代方案

## 4. RTM 需求追踪矩阵

执行前创建 RTM。

必填字段：

`准则编号｜准则摘要｜来源｜模块｜业务流程｜角色｜用例编号｜执行状态｜缺陷编号｜证据编号｜覆盖结论｜验收结论｜备注`

每条验收准则必须映射到以下之一：

- UAT 用例
- 人工确认项
- 接口/后台补充验证项
- 明确的 `Blocked`、`OutOfScope` 或 `To-confirm`

## 5. UAT 用例设计

先设计场景化 UAT 用例，再执行。

必填字段：

`用例编号｜关联准则编号｜业务场景｜角色｜前置条件｜测试数据｜业务步骤｜页面操作步骤｜接口/后台补充说明｜预期结果｜优先级｜证据要求｜是否可自动化｜风险点｜验收影响`

用例类型包括：

- GUI 可操作用例
- 接口/后台补充验证用例
- 异步/定时/后台任务用例
- 集成/通知/导入/导出用例
- 权限与数据范围用例
- 反向/异常用例
- 仅人工确认用例

## 6. 授权与安全边界

触碰类生产或真实业务环境前，必须确认边界。

默认禁止，除非用户明确授权：

- 真实支付、退款、结算或资金流转
- 删除或修改真实业务数据
- 批量发送短信、邮件、推送或外部通知
- 发布、停用、覆盖生产配置
- 使用真实证书、印章、许可证或具有法律效力的签署能力
- 执行可能影响真实用户或外部系统的任务
- 上传涉密或受监管文件

优先使用带 UAT 标识的测试数据和可回滚操作。需要清理的数据必须记录并验证清理结果。

## 7. 登录状态与浏览器规则

- 使用专用 UAT 浏览器配置，不混用用户日常浏览器。
- 遇到密码、MFA、SSO、验证码或扫码登录时，让用户在专用浏览器中手动完成。
- 不打包、不发布、不报告 Cookie、浏览器存储状态、Token、凭证或包含密钥的截图。
- 做角色权限 UAT 时，不同角色使用独立配置或干净会话。
- 登录状态通过页面文字、URL 模式、可见角色/菜单信号和截图确认，但不得泄露密钥。

## 8. 执行标准

适用时按三条线覆盖：

1. **业务流程线**：真实业务场景的端到端闭环和数据生命周期。
2. **模块菜单线**：导航、表单、列表、筛选、排序、分页、行操作、弹窗、上传下载、导入导出、配置页。
3. **角色权限线**：菜单可见性、按钮可操作性、数据范围、直接 URL/API 越权控制、跨角色隔离。

操作 GUI 页面前：

- 读取当前页面/Frame 的 DOM 结构
- 建立控件清单：表单、输入框、按钮、下拉框、表格、行操作、弹窗、分页、TAB、提示、空状态
- 标记安全控件与高风险控件

重要操作后：

- 重新读取 DOM 或页面状态
- 截图留证
- 记录 URL、角色、动作、输入类型、实际结果、控制台错误、网络失败和证据编号

没有证据支撑时，不要声称控件或流程已通过。

## 9. 问题记录

使用明确状态：

- `FormalIssue`：已确认、影响验收的缺陷
- `Blocked`：因账号、数据、环境或依赖无法执行
- `NeedReview`：观察到行为，需要产品/业务确认
- `ToConfirm`：预期行为在文档中缺失或不明确
- `Observed`：非阻断观察项
- `Pass`：已有证据验证通过

问题字段：

`问题编号｜模块/流程｜页面/功能点｜页面 URL｜角色｜业务场景｜问题描述｜严重级别｜优先级｜环境/版本｜测试数据类型｜复现步骤｜预期结果｜实际结果｜证据编号｜验收影响｜建议修复｜状态`

规则：

- `页面 URL` 指 Web 页面地址；接口地址必须单独标为 `接口 URL`。
- 复现步骤必须是人能看懂的页面/业务步骤。
- 不包含密码、Token、Cookie、个人隐私数据或涉密载荷。
- 控件缺失只有在需求/手册/用例明确要求时才算正式缺陷；否则标为 `ToConfirm`。

## 10. 报告标准

决策型 UAT 报告应包含：

1. 验收总览与最终建议
2. 范围、环境、假设与排除项
3. 资料来源与验收基线
4. RTM 需求覆盖矩阵
5. 业务流程验收结果
6. 模块/菜单验收结果
7. 角色权限/数据范围验收结果
8. 接口/后台/异步/集成补充验证结果
9. 用例执行明细
10. 正式缺陷清单
11. 阻塞项与待确认项
12. 文档/系统差异
13. 风险与遗留问题
14. 证据索引
15. 最终验收建议
16. 签署确认页

验收建议：

- `通过`：阻断准则通过、核心流程闭环、证据完整、无阻断缺陷。
- `有条件通过`：剩余问题不阻断验收，且有明确规避方案或修复计划。
- `不通过`：核心流程、权限边界、数据完整性、安全边界或关键准则失败。
- `阻塞`：因访问、环境、数据或依赖问题导致证据不足，无法判断。

## 11. 最终审核关卡

交付前必须审核：

- 不包含密钥、凭证、Cookie、Token、私有 URL、本机路径或客户专属涉密名称
- RTM 覆盖所有准则，或明确标记缺口
- 用例状态、问题状态、证据相互一致
- 截图归属于对应页面、模块和角色
- 阻塞项/待确认项明确展示，不能计为通过
- 缺陷复现步骤清晰可读
- 接口/后台验证不得冒充完整 GUI 验证
- 最终建议有证据支撑
- 若需要打包，交付包包含报告、RTM、用例、问题、执行记录、证据索引、审核记录和清单

如果审核失败，修正报告/交付包，并标记为 `review-fixed`。

## 12. 交付包建议

用户要求打包时，使用项目中立结构，例如：

```text
uat-delivery-<project-slug>-v<version>-<YYYYMMDD>/
├── report/
├── evidence/
├── data/
│   ├── acceptance-criteria.csv
│   ├── rtm.csv
│   ├── uat-cases.csv
│   ├── execution-records.csv
│   └── issues.csv
├── audit/
│   └── final-audit.md
└── MANIFEST.md
```

输出位置应遵循用户当前任务要求。公开 Skill 中不要硬编码个人桌面路径或本机用户名。

## 13. 附带参考文件

仅在需要时读取：

- `references/uat-standards.md`：验收、执行、报告和审核详细标准。
- `references/audit-checklist.md`：最终审核清单。
- `references/issue-writing.md`：正式缺陷写法。
- `references/report-structures.md`：报告结构模板。
- `assets/report-template.html`：通用 HTML 报告模板。