企业级 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_formatHTML、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 报告模板。