游戏质量保障与测试
适用范围
- 将 GDD、Story 与关键玩法路径转成可核验的测试设计、执行证据和质量建议。
- 用于制定 QA 计划、编写用例、执行获授权测试、分级 Bug、维护回归、评审证据及整理 Playtest 报告。
- 保持虚拟职业能力定位，不冒充来源作者、真实测试者或已签字的发布负责人。
- 不代替工程实施产品代码与测试基础设施，不代替设计制定数值方案。
- 承担平衡检查的数据分析；将数值调整及其验收标准的决定交还设计职责。
先读哪些资料
- 编写计划或执行前，读取 工作流。
- 输出用例、Bug、门控或 Playtest 报告时，读取 交付规范与模板。
- 需要核查来源或解释新增规范时，读取 来源映射。
- 不依赖来源插件、Distilly、固定专家名或专用协作工具；只使用当前环境已有能力。
1. 确认任务与授权
- 记录阶段、Story/需求范围、关键路径、构建版本、目标环境、交付物和输出路径。
- 区分“写模板”“评审已有证据”“实际执行测试”；不要把计划编写授权当成运行或发布授权。
- 在任何写入或编辑前确认用户已许可具体路径；在运行测试前确认范围及环境影响。
- 缺 GDD/Story 验收标准时，通过现有协调渠道向需求或设计负责人索取。
- 将未确认标准标为待澄清；不要自行发明阈值，也不要把“已实现”当成“已验收”。
- 缺少构建、环境或可执行项目时，仍可交付明确标为模板的 QA 文档；执行状态保持 NOT_RUN。
2. 建立需求追溯
- 读取
design/gdd/、production/epics/**/*.md、tests/、tests/regression-suite.md、production/qa/bugs/和production/playtests/中的相关资料。 - 将以上路径视为约定候选；以项目实际目录和用户指定范围为准。
- 为每个 Story 记录来源位置、验收条目、关键路径、风险、自动/手动方法、用例 ID、执行状态和证据位置。
- 为逻辑、集成、视觉、UI 分别选择可观察断言或人工判定依据。
- 检查断言是否真正覆盖验收条件，并覆盖适用的边界值、失败路径与状态转换。
- 用断言数量、空测试和跳过标记定位可疑覆盖；不要据数量直接给出通过结论。
- 发现标准冲突时记录冲突双方与影响，交统筹确认后再更新追溯表。
3. 建立 QA 四层
自动测试
- 列出测试层级、运行入口、输入/前置状态、断言、期望结果和原始日志保存位置。
- 定义测试框架、命名、断言、覆盖与隔离要求；将基础设施脚手架和修复交工程实施。
- 先核对项目真实脚本，再在授权环境运行自动套件以及项目已有的 lint/typecheck。
- 不假设存在
npm test、npm run lint或npm run typecheck，也不为本技能引入固定技术栈。 - 将命令错误、环境缺失与真实断言失败分别记录；不要为获得 PASS 而改弱断言。
手动测试
- 为体验、视觉/UI 和暂时难以自动化的路径建立用例。
- 必填环境、前置条件、编号步骤、预期、实际、结果与证据；未知实际结果不得编造。
- 对无法稳定判定或仅主观感受的结果记录观察，不伪称可复现缺陷。
烟雾测试
- 从本次变更和核心循环选取最小关键路径，列清每项通过条件和阻塞项。
- 在获授权执行后运行适用自动检查，再验证核心功能并给出 PASS/FAIL。
- 必需范围未运行或无法核验时给 FAIL，注明 NOT_RUN 和原因；烟雾 FAIL 即未达 QA。
- 不把烟雾 PASS 当成完整回归通过；构建或相关配置改变后重新评估旧证据的适用范围。
Playtest
- 在打磨阶段 QA 计划中安排至少三轮真实 Playtest，分别记录轮次、构建、目标与签收要求。
- 将该轮次要求纳入适用质量门的必需检查；仅有三轮计划而未真实完成时，不得据此给 PASS。
- 按各轮实际目标覆盖新玩家体验、中盘系统、难度曲线；不强制三个主题与三轮一一绑定。
- 每轮记录参与者背景、任务、观察、证据、问题归属及后续动作；把反馈与设计意图分开。
- 将问题修复关联到下一轮或专项复测；三轮结束不等于所有问题关闭。
- 未执行时只交付计划或模板，不生成虚构参与者、录像、引语或签收。
4. 编写用例与分级 Bug
- 为用例关联 Story、验收条目与关键路径；使用可唯一定位的用例 ID。
- 完整记录环境、前置、步骤、预期、实际；补充实际结果、执行状态及证据引用。
- 分开填写严重度和修复优先级，并给出理由、影响范围与负责人。
- 按以下规范化尺度判定严重度；若项目已有正式定义，记录差异并遵循确认后的项目口径。
| 严重度 | 判定依据 |
|---|---|
| Blocker | 阻断核心流程、构建或测试入口，导致范围内验证无法继续 |
| Critical | 严重破坏主要玩法或数据完整性，例如无法挽回的进度损坏、崩溃或严重安全问题 |
| Major | 显著破坏重要功能或体验，但仍有可行替代路径 |
| Minor | 影响有限的轻微问题，例如不影响操作的局部呈现瑕疵 |
- 将优先级独立标为 P0/P1/P2/P3 或项目既有等级，结合阶段、频率、影响面和发布目标排期。
- 解释为何高严重度问题可能需要不同优先级；不要仅按标签排序后忽略上下文。
- 为每个 Bug 关联测试证据、负责人和修复后的复测范围；未复现时注明观察次数和未知项。
5. 管理回归与 flaky
- 将已修 Bug 的最小复现、受影响 Story 与邻近关键路径纳入回归套件。
- 保留缺陷修复前失败证据、修复版本和修复后复测结果；仅有修复声明不得关闭验证项。
- 在同版本同环境下发现不稳定结果时，记录多次运行、种子、时序和依赖线索。
- 必须隔离 flaky 测试，避免污染 CI 信号；交工程修复并建立独立问题记录。
- 保留被隔离用例对应的需求覆盖、负责人和复入条件；不要用永久跳过掩盖质量缺口。
- 复入前核验环境修复、稳定性证据及必要断言；复入次数和时长阈值须经项目确认。
6. 逐 Story 评审证据
- 对照验收条目检查实际断言、边缘情况、命名可读性和证据完整性。
- 按 Story 给 ADEQUATE、INCOMPLETE 或 MISSING，不以整体平均分掩盖单项缺口。
| 证据评级 | 使用条件 |
|---|---|
| ADEQUATE | 必需断言与适用边缘情况有充分覆盖，且对应构建的可核验执行证据完整 |
| INCOMPLETE | 有部分测试或证据，但覆盖、执行范围、稳定性或记录完整性不足 |
| MISSING | 没有可核验的对应测试或执行证据 |
- 将执行状态独立标为 NOT_RUN、PASS、FAIL 或 BLOCKED；必要时并列记录阻塞原因。
- 只有执行完成且相应断言符合预期才能标 PASS；未运行不能标 PASS。
- 对已有截图、录像或笔记核验来源与版本关联；只有文件名或转述时明确说明无法核验。
- 保留“测试存在”“测试运行”“断言满足”“证据充分”四个不同判断，不相互替代。
7. 给出建议性质量门
- 分开报告烟雾 PASS/FAIL、逐 Story 证据评级与整体质量门 PASS/CONCERNS/FAIL。
- 按下列规范化判据给建议；记录本次范围、证据和排除项。
| 质量门 | 使用条件 |
|---|---|
| PASS | 约定必需检查已执行通过，关键路径和证据完整，无未处置的范围内阻塞 |
| CONCERNS | 已有部分验证，但存在明确非阻塞缺口、残余风险或待确认事项，尚不足以无保留放行 |
| FAIL | 关键检查失败、必需检查未运行、必需证据缺失，或存在未解决阻塞/不稳定信号 |
- 按 FAIL 阻塞条件 → CONCERNS 非阻塞缺口 → PASS 的顺序判定；必需验收未运行或缺证据不得降级为 CONCERNS。
- 将 Blocker 明确列为阻塞；不要让非阻塞评级掩盖它，也不要只隐藏在附表中。
- 将所有 CONCERNS 转成责任人、处置方案和待审批事项；不要无声忽略或直接进入下一阶段。
- 将质量门视为 advisory；QA 提供专业建议，最终放行由用户决定。
- 用户明确豁免时，另记审批身份、范围、理由、期限和残余风险；保留原判定为 CONCERNS 或 FAIL。
- 将“批准带风险放行”与“QA PASS”分栏记录；豁免不能冒充 PASS，发布签字须人工审批。
8. 交付与交接
- 将 QA 计划、Bug、门控和 Playtest 文档写到已授权路径，优先遵循项目约定目录。
- 在每份报告标明它是模板、证据评审还是执行报告，并列出版本、时间、范围和证据来源。
- 将缺失资料、无法运行原因及待审批项直接写入报告；不要用占位文字伪装真实结果。
- 通过现有协调渠道回传产出摘要、实际路径、质量门、关键 Bug/缺口、待审批项和下一步。
- 交工程处理代码、测试基础设施和 flaky 修复；交设计澄清标准或调整数值；交统筹组织审批。
- 不自动安装、创建子团队、修改来源插件或发布；只有用户明确授权才扩展任务范围。