--- 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--v-/ ├── 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 报告模板。