用户验收测试（UAT） 是做什么的？
端到端的 UAT 框架，涵盖计划生成、执行、利益相关者签署以及发布决策。UAT 是投产前的最后一个质量关卡，请认真对待。没有明确的利益相关者根据验收标准签署同意，任何功能都不能发布。
预处理（自动上下文）
在开始之前，自动收集项目上下文：
- 如果项目根目录或父目录中存在
PORTFOLIO.md，则读取它以获取产品/团队上下文 - 运行：
cat package.json 2>/dev/null || cat build.gradle.kts 2>/dev/null || cat Podfile 2>/dev/null以检测技术栈 - 运行：
git log --oneline -5 2>/dev/null以查看最近的变更 - 运行：
ls src/ app/ lib/ functions/ 2>/dev/null以了解项目结构 - 使用这些上下文来定制所有输出，使其适应实际项目
步骤 1：分类 UAT 需求
在制定计划之前，先确定 UAT 类型。类型决定了范围、深度、利益相关者参与度和时间线。
| UAT 类型 | 触发条件 | 范围 | 典型时长 |
|---|---|---|---|
| 新功能 UAT | 功能开发完成，合并到 staging 分支 | PRD/用户故事中的所有验收标准，完整的快乐路径 + 边缘情况 | 2-5 个工作日 |
| 回归 UAT | 重大重构、依赖升级或平台迁移 | 重新验证关键用户旅程，无行为回归 | 1-3 个工作日 |
| 候选版本 UAT | 发布分支已创建，所有功能已集成 | 完整的发布范围——每个功能、集成点和跨平台行为 | 3-5 个工作日 |
| 热修复验证 | 生产环境漏洞已修复，补丁已部署到 staging | 范围小——验证修复，确认对相邻流程无副作用 | 2-4 小时 |
如果 UAT 类型不明确，请先询问后再继续。热修复验证和候选版本 UAT 需要完全不同的计划。
自动上下文收集
在创建 UAT 计划之前：
- 全局搜索现有的测试规范、PRD 文件、验收标准文档
- 读取找到的任何规范，提取可测试的需求
- 使用 grep 搜索控制被测功能的特性标志
工件生成（必需）
使用 Write 生成：
- UAT 计划：
docs/uat/uat-plan.md—— 使用测试计划输出风格 - 测试用例：
docs/uat/test-cases.md—— 包含步骤和预期结果的详细测试用例 - 签署表单：
docs/uat/sign-off.md—— 利益相关者批准模板 - 缺陷分类模板：
docs/uat/bug-triage.md—— 严重性分类指南
步骤 2：收集上下文
在编写 UAT 计划之前，收集所有输入。缺少上下文会产生不完整的计划。
| 输入 | 是否必需 | 来源 | 备注 |
|---|---|---|---|
| 功能名称/发布版本 | 是 | 项目经理/技术负责人 | 用于跟踪的简短标识符 |
| 验收标准 | 是 | PRD、用户故事、Jira/Linear 工单 | 如果可用，使用 /sdlc 技能输出 |
| 利益相关者列表 | 是 | 项目经理/产品负责人 | 谁测试，谁签署，谁有否决权 |
| 目标环境 | 是 | 工程团队 | Staging URL、构建号、特性标志 |
| 平台 | 是 | 工程团队 | Android、iOS、Web 或组合 |
| 合规要求 | 可选 | 法务/安全 | HIPAA、SOC 2、PCI-DSS、GDPR 对测试数据的约束 |
| 已知风险或限制 | 可选 | 工程团队 | 技术债务、已知问题、不完整的集成 |
| 之前的 UAT 结果 | 可选 | QA/PM | 用于回归比较的基线 |
| 发布日期截止 | 是 | 项目经理 | 硬截止日期 vs. 灵活——驱动发布决策的压力 |
如果验收标准不存在，请停下来，首先使用 /sdlc 技能创建它们。没有验收标准的 UAT 是基于意见的测试——它证明不了什么。
步骤 3：UAT 计划生成
3.1 验收标准提取
从每个来源提取验收标准，并将其规范化为可测试的语句。
格式：Given [前置条件]，When [操作]，Then [预期结果]
来源优先级：
1. PRD 验收标准（权威）
2. 用户故事验收标准（详细）
3. 设计规范/原型（视觉和交互行为）
4. API 契约（响应形状、错误码）
5. 代码审查或功能审计期间识别的边缘情况
每个验收标准变成一个或多个测试场景。如果一个标准无法手动测试，则标记它并指定自动化验证方法。
3.2 测试场景矩阵
构建完整的场景矩阵。每个场景恰好有一个预期结果。
| 编号 | 类别 | 场景 | 前置条件 | 步骤 | 预期结果 | 平台 | 优先级 |
|---|---|---|---|---|---|---|---|
| UAT-001 | 快乐路径 | [主要成功流程] | [设置状态] | [1. 2. 3.] | [预期结果] | 全部 | P0 |
| UAT-002 | 快乐路径 | [次要成功流程] | [设置状态] | [1. 2. 3.] | [预期结果] | 全部 | P0 |
| UAT-003 | 边缘情况 | [边界条件] | [设置状态] | [1. 2. 3.] | [预期结果] | 全部 | P1 |
| UAT-004 | 错误状态 | [无效输入/失败] | [设置状态] | [1. 2. 3.] | [错误处理] | 全部 | P1 |
| UAT-005 | 跨平台 | [平台特定行为] | [设置状态] | [1. 2. 3.] | [平台预期] | 特定 | P1 |
| UAT-006 | 可访问性 | [屏幕阅读器/键盘导航] | [辅助技术启用] | [1. 2. 3.] | [可达性结果] | 全部 | P1 |
| UAT-007 | 性能 | [加载时间/响应能力] | [标准条件] | [1. 2. 3.] | [在预算内] | 全部 | P2 |
| UAT-008 | 离线/降级 | [无连接/信号差] | [飞行模式/限速] | [1. 2. 3.] | [优雅处理] | 移动端 | P1 |
优先级定义：
- P0 —— 核心功能。如果失败，该功能无法工作。阻止发布。
- P1 —— 重要行为。如果失败，功能可以工作但存在重大缺陷。必须在发布前修复。
- P2 —— 锦上添花的验证。如果失败，可以在已知问题记录的情况下发布。
3.3 环境检查清单
在 UAT 开始前验证测试环境。损坏的环境会浪费利益相关者的时间并侵蚀信任。
UAT 前环境检查清单
[ ] Staging 环境已部署，包含正确的构建/版本
[ ] 构建版本已记录：_______________
[ ] 为 UAT 范围启用的特性标志：
[ ] 标志：_____________ = 开/关
[ ] 标志：_____________ = 开/关
[ ] 测试数据已植入（账户、内容、交易）
[ ] 已创建具有所需角色/权限的测试账户
（有关账户配置，请参阅 test-accounts 技能）
[ ] 第三方集成处于测试/沙箱模式：
[ ] Stripe：使用测试 API 密钥的测试模式
[ ] 支付处理器：沙箱环境
[ ] 电子邮件/短信：被拦截或使用测试收件人
[ ] 分析：开发/暂存属性（非生产）
[ ] 后端/API 指向暂存环境（非生产）
[ ] 数据库已植入代表性数据量
[ ] 推送通知已为暂存环境配置
[ ] 深层链接 / 通用链接已为暂存域名配置
[ ] SSL 证书在暂存环境上有效
[ ] 所有测试者的 VPN/网络访问已配置
3.4 利益相关者角色表
定义谁做什么。角色模糊意味着覆盖范围存在空白。
| 角色 | 人员 | 职责 | 签署权限 |
|---|---|---|---|
| UAT 负责人 | [姓名] | 拥有 UAT 计划，协调会议，分类缺陷，生成报告 | 最终发布决策建议 |
| 产品负责人 | [姓名] | 验证验收标准是否满足，测试业务逻辑场景 | 是 —— 业务签署 |
| 设计负责人 | [姓名] | 验证视觉保真度、交互模式、品牌一致性 | 是 —— 设计签署 |
| 工程负责人 | [姓名] | 可用于缺陷调查、环境修复，解释技术约束 | 是 —— 技术签署 |
| QA 测试员 | [姓名] | 系统性地执行测试场景，附带证据记录发现 | 否 —— 向 UAT 负责人报告 |
| 领域专家 | [姓名] | 测试特定领域的工作流程（金融、医疗、法律） | 是 —— 领域签署 |
| 可访问性测试员 | [姓名] | 屏幕阅读器通过测试、键盘导航、WCAG AA 验证 | 咨询 —— 上报至 UAT 负责人 |
最低有效签署要求：产品负责人 + 工程负责人。所有其他签署是推荐的，但取决于范围。
步骤 4：UAT 执行框架
详细信息请参阅 reference/details.md（第 4 节：“UAT 执行框架”）。
步骤 5：签署和发布决策关卡
5.1 发布决策矩阵
发布决策是基于数据的，而不是基于意见的。对每个标准进行评分并计算加权结果。
发布决策矩阵
功能/版本：_______________
日期：_______________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌──────────────────────────────────┬────────┬────────┬───────┬───────┐
│ 标准 │ 权重 │ 状态 │ 分数 │ 备注 │
├──────────────────────────────────┼────────┼────────┼───────┼───────┤
│ 所有 P0 场景通过 │ 30% │ 可/否 │ X/30 │ │
│ 所有 P1 场景通过 │ 25% │ 可/否 │ X/25 │ │
│ 没有未关闭的 P0 缺陷 │ 20% │ 可/否 │ X/20 │ │
│ 没有未关闭的 P1 缺陷（或已接受风险）│ 10% │ 可/否 │ X/10 │ │
│ 可访问性通过（WCAG AA） │ 5% │ 可/否 │ X/5 │ │
│ 性能在预算内 │ 5% │ 可/否 │ X/5 │ │
│ 跨平台一致性已验证 │ 5% │ 可/否 │ X/5 │ │
├──────────────────────────────────┼────────┼────────┼───────┼───────┤
│ 总计 │ 100% │ │ X/100 │ │
└──────────────────────────────────┴────────┴────────┴───────┴───────┘
决策阈值：
可发布 >= 90/100 所有 P0 标准必须为“可”。
有条件发布 70-89/100 附带已记录的条件和解决时间线发布。
不可发布 < 70/100 不要发布。修复并重新测试。
硬性阻塞（无论分数如何，自动不可发布）：
- 任何未关闭的 P0 缺陷
- 数据丢失或损坏场景
- 安全漏洞（身份验证绕过、数据暴露）
- 关键用户旅程崩溃
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.2 签署模板
利益相关者签署
功能/版本：_______________
构建/版本：_______________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌──────────────────┬──────────────┬──────────┬────────────┬─────────┐
│ 利益相关者 │ 角色 │ 决定 │ 条件 │ 日期 │
├──────────────────┼──────────────┼──────────┼────────────┼─────────┤
│ [姓名] │ 产品负责人 │ 可/否 │ [如果有] │ [日期] │
│ [姓名] │ 工程负责人 │ 可/否 │ [如果有] │ [日期] │
│ [姓名] │ 设计负责人 │ 可/否 │ [如果有] │ [日期] │
│ [姓名] │ 领域专家 │ 可/否 │ [如果有] │ [日期] │
│ [姓名] │ UAT 负责人 │ 可/否 │ [如果有] │ [日期] │
└──────────────────┴──────────────┴──────────┴────────────┴─────────┘
有条件签署意味着：“可发布，前提是以下问题在 [日期] 前解决：”
1. [条件]
2. [条件]
如果任何利益相关者签署了“否”，则发布被阻止，直到他们的关切得到解决。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.3 回滚计划
每个发布在发布决策做出之前都必须有一个已记录的回滚计划。没有回滚计划 = 自动不可发布。
回滚计划
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
触发条件：[触发回滚的条件——例如，崩溃率 > 2%、生产环境中的 P0 缺陷]
负责人：[谁启动回滚]
步骤：
1. [禁用特性标志 / 回滚部署]
2. [验证回滚成功]
3. [通知利益相关者]
4. [回滚后监控 30 分钟]
数据：[是否需要任何数据迁移回滚？Firestore 文档版本控制？]
沟通：[如果需要，谁与用户沟通——支持团队、状态页面]
事后复盘：[在回滚后 48 小时内安排]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.4 发布说明草稿
从 UAT 发现生成发布说明。在这一点上，UAT 测试员比任何人都更了解该功能。
发布说明（来自 UAT 发现）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
版本：_______________
日期：_______________
新增
- [添加的功能/能力——用户视角的语言]
改进
- [对现有功能的增强——对用户更好的地方]
修复
- [在 UAT 期间修复的缺陷——之前损坏的现在已解决]
已知问题
- [随此版本发布的 P2 缺陷——如果可用，提供变通方法]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
步骤 6：UAT 报告
在所有会议完成后且签署已收集时，生成完整的 UAT 报告。
═══════════════════════════════════════════════════════════════
UAT 报告
功能/版本：[名称]
版本/构建：[版本]
日期：[今天]
UAT 负责人：[姓名]
═══════════════════════════════════════════════════════════════
执行摘要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
决定： 可发布 / 有条件发布 / 不可发布
总场景数： [N]
通过： [N] ([X]%)
失败： [N] ([X]%)
阻塞： [N] ([X]%)
未执行： [N] ([X]%)
未关闭阻塞：[N] P0 / [N] P1 / [N] P2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
按类别的通过率
┌──────────────────────┬──────────┬────────┬─────────┬────────┐
│ 类别 │ 总数 │ 通过 │ 失败 │ 通过率 │
├──────────────────────┼──────────┼────────┼─────────┼────────┤
│ 快乐路径 │ [N] │ [N] │ [N] │ [X]% │
│ 边缘情况 │ [N] │ [N] │ [N] │ [X]% │
│ 错误状态 │ [N] │ [N] │ [N] │ [X]% │
│ 跨平台 │ [N] │ [N] │ [N] │ [X]% │
│ 可访问性 │ [N] │ [N] │ [N] │ [X]% │
│ 性能 │ [N] │ [N] │ [N] │ [X]% │
│ 离线/连接性 │ [N] │ [N] │ [N] │ [X]% │
├──────────────────────┼──────────┼────────┼─────────┼────────┤
[截断以用于翻译]