qa-execution

真实用户 QA 执行

像真实用户那样 QA 产品：一个角色设定沿着产品的公开界面走完一段旅程，感受其中的阻碍，触及边界，并报告发生了什么。这是自测，不是按脚本跑完一轮测试——会话本身就是工作，而不断更新的 QA 文档树会记录这一切。

每次会话都必须遵守以下三条原则：

1. 代入角色。 每次交互和每项验证都必须通过真实用户可访问的界面进行——不能走开发工具的捷径，不能通过阅读代码来判断应该发生什么，也不能在卡住时打补丁。
2. 拿证据说话，而非盲目乐观。 只有观察到预期结果、通过独立读取路径确认、刷新后仍然成立，并捕获了证据，才能判定为 Pass。乐观 UI 不算确认。
3. 写回记录，否则就等于没做。 每次会话都必须更新文档树——场景文件判定结果、缺陷登记表，以及记录会话复盘的日期报告。

输入

• qa-docs-path（可选）：不断更新的 QA 文档树的根目录；默认为 docs/qa/。此树是本技能的记忆，也是唯一的输出位置——绝不能使用临时目录。如果该目录不存在，先运行 qa-report；该工具负责创建文档树并完成初始化。

步骤

选择计划中的冒烟／定向／完整范围。只阅读相关的流程／架构章节，并复用针对未变更行为的现有证据。小范围变更的旅程不需要跑完所有导览、边界类别，也不需要再进行一次完整巡查。

步骤 1 — 确定文档树、范围和前置条件

• 按顺序阅读：<qa-docs-path>/README.md（入口、开发服务器命令、区域代码）、范围内的 scenarios/ 文件、相关的未解决 bugs/，以及本周期的章程。文档树就是记忆；不先阅读就直接运行，会重现本设计要消除的重复工作。
• 范围：分支／PR 运行覆盖其用户可见差异涉及的旅程；如果共享行为可能出现回归，还要覆盖一个相邻的哨兵旅程——如果没有用户可见变更，报告这一点后停止。发布／完整运行覆盖周期计划标记为范围内的旅程。
• 前置条件：满足适用的前置条件和现有必需检查（复用现有证据；针对性探测不必等待无关套件完成），且产品可在与生产环境一致的构建中访问（真实开发服务器、真实身份验证、不使用模拟）。无法访问 → 指明具体障碍并停止。
• 完成条件： 范围已确定，且所有前置条件均已满足，或已明确指出未满足项。

步骤 2 — 构建矩阵并立即创建报告

• 阅读 references/status-and-reporting.md——其中定义了六值状态枚举和报告生命周期。
• 根据计划中的章程组装会话矩阵：角色设定 × 旅程 × 导览 × 时间限制，按风险排序。范围内的旅程若缺少章程，须在运行前依照 ../qa-report/references/session-charters.md 起草——绝不能执行未规划的巡查。
• 在首次会话开始前，根据报告模板创建 <qa-docs-path>/reports/<YYYY-MM-DD>-<scope>.md（项目副本位于 <qa-docs-path>/templates/report.md，否则使用 assets/report-template.md），并将矩阵中每一行都标记为 Pending。此磁盘报告是恢复执行时的唯一事实来源——每次会话和每次修复后都要更新，绝不能只在最后更新。
• 完成条件： 磁盘上已创建包含完整矩阵的报告，且每一行均为 Pending。 步骤 3 — 以角色身份逐一走查每段用户旅程
• 阅读 references/session-protocol.md（进入→操作→验证→记录循环及证据标准）和 references/persona-fidelity.md（公共接口防护原则及停滞即为发现）。
• 按矩阵顺序逐一处理每份测试章程：采用相应角色（设备、网络、区域设置），从其真实入口进入，并按动词顺序走完整段用户旅程，直至真实结束状态——根据证据标准验证每一步。
• 全程留意细微不便：角色能感受到的摩擦，但不会导致任何功能检查失败。严重的问题应记录为发现。
• 只有真人才能完成的环节（真实付款、外部邮件／短信、真实 OAuth）应标记为 Blocked (needs human verify) 并附上准确说明——绝不伪造。
• **完成条件：**每份测试章程都已走查并记录判定结果；已在检查点和偏差处收集证据；已将复盘写入报告的 Session Debriefs 部分；并已更新矩阵行。

步骤 4 — 执行每项体验巡查和边界探测

• 阅读 references/tours.md（包含 10 项体验巡查的目录及界面到巡查的对应矩阵）和 references/edge-cases.md（面向非技术用户的边界情况）。
• 在对应界面上，以角色身份在既定范围内执行每份测试章程对应的单项体验巡查，并在每个操作时自问：“这会影响本次体验巡查的主题吗？”
• 根据变更的契约和风险，选择不同的边界情况；没有最低数量要求。尝试后确认一切正常，也是证据。
• **完成条件：**每份测试章程都已执行体验巡查，并已尝试和记录选定的边界情况。

步骤 5 — 体验视角检查

• 阅读 references/lenses.md — 了解六种视角及其严重性默认值。
• 对于已请求的可用性／全面审查，或尚未解决的体验风险，将相关视角应用于受影响的用户旅程。复用首次走查的观察结果，只重新走查缺失的证据。
• **完成条件：**相关体验风险已有证据，或对于目标范围而言，无需执行此可选检查。

步骤 6 — 将发现录入登记表

• 阅读 ../qa-report/references/bug-registry.md — 该文件负责管理 ID、去重和影响等级规则。
• 先去重：搜索 bugs/ 和受影响场景的 bug_ids。重新发现的 → 追加 ## Re-found；复发的 → 以 ## Regressed 重新打开；只有真正的新症状才创建新的 BUG-<YYYYMMDD>-<slug> ID。
• 优先按用户视角记录问题 — 影响等级、角色、用户旅程步骤、从角色入口开始的复现步骤、证据路径 — 然后将 ID 链接到受影响的场景文件中。
• **完成条件：**每项发现都已去重、登记，并链接到相应行。

步骤 7 — 修复循环（受控）

• 阅读 references/fix-loop.md — 了解治理规则、每项修复都需配套回归测试的规则，以及 Decisions for a Human。
• 在编辑之前，先根据治理规则评估每项修复：只有满足所有界限的内容才可自动修复；每项自动修复都必须在所属测试套件／探测中有证据（仅针对尚未覆盖的不变量添加回归测试），并重新走查受影响的用户旅程；若故障可能扩散，还需走查相邻用户旅程。其他所有内容都应连同选项和建议一并提交至报告的 Decisions for a Human。
• **完成条件：**每项发现都已修复并重新测试，或已附上建议并升级处理；没有任何修复只完成了一半。 步骤 8 — 结束本轮
• 重新阅读 references/status-and-reporting.md 中的轮次结束检查清单；根据 ../qa-report/references/state-schema.md 将矩阵判定映射到跟踪器枚举值。
• 根据观察到的发现、覆盖范围和限制，结束所请求的 QA 范围。修复后，运行受影响的检查以及该工作所需的任何项目检查，并复用有效证据。如果请求还包括 PR 交付或发布就绪性，则记录适用的交付门槛和当前 HEAD 的 CI；缺少必需证据或证据未通过，会阻止就绪性声明，但不妨碍如实报告 QA 结果。
• **完成条件：**矩阵中没有 Pending 行，场景文件判定和 Bug 状态均为最新，每次会话的复盘都已写入报告，且 Final Status 说明 QA 结果、各影响等级的总数，以及来自已检查构建的证据。只有当 PR／发布就绪性属于本次决策范围时，才说明其就绪状态。

配套技能

• qa-report — 负责规划本技能运行的内容，并维护代码库的各类架构（跟踪器、Bug 注册表、章程、角色、用户旅程）。此处记录的结果将用于下一轮规划。
• agent-output-audit — 负责 CI 门槛、AI 测试卫生扫描、任务状态核对和不稳定测试的分类处理。若会话发现这些文件存在问题，应记录该发现并指出相关门槛；不得在会话中途转换方向。
• agent-browser — 步骤 3-5 的浏览器驱动程序；其命令接口位于 references/session-protocol.md。

错误处理

• **开发服务器或浏览器工具不可用：**将浏览器环节标记为 Blocked (needs human verify)，并注明确切缺失的前置条件；继续执行仍可在角色流程中通过 CLI／HTTP 完成的用户旅程。
• **流程卡住：**结束会话并记录，使用全新会话重试一次，然后标记为阻塞。卡顿属于需要登记的发现，绝不能试图强行继续（references/persona-fidelity.md）。
• **凭据或测试数据缺失：**将相关会话标记为阻塞，注明确切的前置条件，并继续处理其余部分。
• **矩阵超出可处理范围：**按风险裁剪（优先处理可能阻断完成的候选项，其次是数据丢失，再其次是信任受损），将裁剪的行标记为 Skipped 并说明理由，同时在 Final Status 中披露——覆盖范围要么明显缩小，要么完全不变。