Claude Code Game Studios 中的 QA Tester Agent从测试用例编写到回归清单的完整实战指南【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios导读本文档深入解析 Claude Code Game Studios 中qa-testerAgent 的定义与职责边界它负责编写详尽的测试用例、结构化 Bug 报告、回归检查清单与冒烟测试执行文档并能在 Godot / Unity / Unreal 三大引擎下搭建自动化测试脚手架。阅读本文后你将掌握测试用例四字段规范、引擎专属测试模式、Bug 报告模板、回归清单的裁剪范围以及如何在/team-qa七阶段 QA 流程中正确驱动该 Agent。一、Agent 定位QA 团队的执行层而非决策层qa-tester是 Claude Code Game Studios 49 个 Agent 中隶属于 QA 部门的执行型 Agent。它的完整定义位于 .claude/agents/qa-tester.md核心职责如下维度说明名称qa-tester职责域详细测试用例编写、结构化 Bug 报告、测试执行文档、回归检查清单、冒烟测试执行文档、按项目编码标准记录测试证据工具集Read、Glob、Grep、Write、Edit、Bash可读写tests/与production/qa/evidence/但不可直接修改游戏源码模型层级SonnetQA 专员默认档位最大轮次10汇报对象qa-lead边界什么归它管什么不归它管从 CCGS Skill Testing Framework/agents/qa/qa-tester.md 的 Agent Test Spec 可以精确还原它的权责边界它拥有测试用例编写、Bug 报告、测试执行文档、回归清单、冒烟测试执行文档、测试证据记录它不拥有测试策略与测试计划设计属于qa-lead、已发现 Bug 的修复实现属于对应方向的程序员、QA 流程架构属于qa-lead。对照 .claude/agents/qa-lead.md 可以看到qa-lead是策略层——负责测试策略、Bug 严重度评估、回归测试规划、发布就绪度评估而qa-tester是执行层接受qa-lead的委派编写测试用例并执行测试。二者构成策略 → 执行的上下级链条。二、协作协议协作式实现者而非自主代码生成器qa-tester遵循与全项目一致的协作协议详见 .claude/docs/coordination-rules.md 与各 Agent 定义You are a collaborative implementer, not an autonomous code generator. The user approves all architectural decisions and file changes.写任何代码之前它必须完成六个步骤阅读设计文档识别规格明确的点与模糊的点标注与标准模式的偏差标记潜在的实现挑战提出架构问题例如这应该是静态工具类还是场景节点[数据] 应该放在哪里[SystemData]/[Container]类 / 配置文件设计文档没说明 [边界情况]应该怎么处理这需要改动 [其他系统]是否要先协调先提架构再实现展示类结构、文件组织、数据流解释推荐方案的 WHY模式、引擎约定、可维护性并亮明权衡——这个方案更简单但灵活性低vs这个更复杂但扩展性强最后询问这符合你的预期吗;透明实现实现中遇到规格歧义立即停下提问规则/钩子标记问题就修复并解释原因若因技术约束必须偏离设计文档要显式说明写入文件前获得批准展示代码或摘要显式询问May I write this to [filepath(s)]?多文件变更列出全部受影响文件等到 yes 才使用 Write/Edit 工具提供下一步现在写测试还是先评审实现已就绪可跑/code-review我发现 [潜在改进]要重构吗协作心态同样被硬性编码先澄清再假设规格永不 100% 完整、提出架构而非只做实现、透明说明权衡、显式标记对设计文档的偏离、把规则当朋友、主动提出写测试。三、自动化测试编写三引擎脚手架模式对于 Logic 与 Integration 类故事qa-tester负责编写测试文件或搭好脚手架交给开发者补全。命名约定如下测试文件名[system]_[feature]_test.[ext]测试函数名test_[scenario]_[expected]GodotGDScript / GdUnit4extends GdUnitTestSuite func test_[scenario]_[expected]() - void: # Arrange var subject [ClassName].new() # Act var result subject.method # Assert assert_that(result).is_equal([expected])UnityC# / NUnit[TestFixture] public class [SystemName]Tests { [Test] public void [Scenario]_[Expected]() { // Arrange var subject new [ClassName](); // Act var result subject.Method; // Assert Assert.AreEqual([expected], result, delta: 0.001f); } }UnrealC AutomationIMPLEMENT_SIMPLE_AUTOMATION_TEST( F[SystemName]Test, MyGame.[System].[Scenario], EAutomationTestFlags::GameFilter ) bool F[SystemName]Test::RunTest(const FString Parameters) { // Arrange Act [ClassName] Subject; float Result Subject.Method; // Assert TestEqual([description], Result, [expected]); return true; }每个 Logic 故事公式必测的五个用例正常情况典型输入 → 预期输出零/空输入不应崩溃最小输出最大值不应溢出或产生无穷大负向修正值如适用GDD 中明确提到的边界情况。这些要求与 .claude/rules/test-standards.md作用于tests/**路径高度呼应测试命名遵循test_[system]_[scenario]_[expected_result]模式、必须具有清晰的 arrange/act/assert 结构、单元测试不得依赖外部状态文件系统、网络、数据库、Mock 外部依赖保证测试快速且确定、每个 Bug 修复必须有能抓住原 Bug 的回归测试。该规则文件还给出了正反例正确示例为test_health_system_take_damage_reduces_health()的完整三段式结构错误示例则暴露了无描述性命名、缺 Arrange、断言不精确三类违规。四、核心职责清单七项测试文件脚手架Logic/Integration 故事实现时主动提出编写或搭建自动化测试文件不必等被要求公式测试生成阅读 GDD 的 Formulas 章节自动生成覆盖全部公式边界情况的测试用例测试用例编写编写含前置条件、步骤、预期结果、实际结果字段的详细测试用例覆盖正常路径、边界情况与错误条件Bug 报告编写按复现步骤、预期 vs 实际行为、严重度、频率、环境、支撑证据日志、截图描述编写报告回归检查清单为每个主要特性与系统创建并维护回归清单每次 Bug 修复后更新冒烟测试清单维护tests/smoke/目录中的关键路径测试用例——这是每次构建进入手工 QA 前/smoke-check门禁要跑的 10–15 个场景测试覆盖追踪追踪哪些特性与代码路径有测试覆盖识别覆盖缺口。其中第 6 项直接对应 .claude/skills/smoke-check/SKILL.md 定义的硬门禁未通过冒烟检查的构建不进 QA。冒烟检查输出production/qa/smoke-[date].md支持sprint/quick两种基础模式与--platform pc|console|mobile|all平台扩展。五、测试用例四字段格式不可省略每个测试用例必须包含以下四个标签字段## Test Case: [ID] — [Short name] **Precondition**: [System/world state that must be true before the test starts] **Steps**: 1. [Action 1] 2. [Action 2] 3. [Expected trigger or input] **Expected Result**: [What must be true after the steps complete] **Pass Criteria**: [Measurable, binary condition — either passes or fails, no subjectivity]来自 Agent Test Spec 的 Case 1存档系统演示了完整样例——TC-SAVE-001 到 TC-SAVE-006 覆盖保存/加载玩家位置、完整背包多物品类型/数量/装备状态、任务状态进行中/已完成/锁定、覆盖旧存档、加载旧版本存档向后兼容、损坏存档处理文件存在但内容非法。验证存档能正常工作这类不可观察的 Pass Criterion 是明确禁止的——标准要求的是可观察、无歧义的二进制条件。六、测试证据路由按故事类型决定证据与门禁等级写任何测试之前qa-tester必须先按 .claude/docs/coding-standards.md 中的分类规则确定故事类型并在每个测试用例/测试文件开头声明故事类型、输出位置与门禁等级故事类型必需证据输出位置门禁等级Logic公式、状态机自动化单元测试——必须通过tests/unit/[system]/BLOCKINGIntegration多系统集成测试或文档化 playtesttests/integration/[system]/BLOCKINGVisual/Feel动画、VFX截图 lead 签字文档production/qa/evidence/ADVISORYUI菜单、HUD、界面手工走查文档或交互测试production/qa/evidence/ADVISORYConfig/Data平衡调优冒烟检查通过production/qa/smoke-[date].mdADVISORYSpec 中的 Case 5 专门验证了这条路由当输入是背包 UIgrid 布局、物品 tooltip、拖拽重排的 UI 故事时qa-tester必须输出手工走查文档而非自动化单元测试到production/qa/evidence/并明确标注 ADVISORY 门禁等级。而 Logic 故事如公式测试则必须产出能通过 CI 的自动化单元测试。自动化测试的附加硬规则见 coding-standards 的 Automated Test Rules测试必须确定性无随机种子、无时间依赖断言、隔离性自建自拆状态、不依赖执行顺序、无硬编码数据边界值测试除外、单元测试独立不调用外部 API/数据库/文件 I/O。CI 侧三引擎各有指定命令Godot 用godot --headless --script tests/gdunit4_runner.gdUnity 用game-ci/unity-test-runnerv4Unreal 用带-nullrhi的 headless runner。七、处理模糊验收标准当验收标准是主观或不可测的如应该感觉直观应该响应灵敏应该看起来不错时qa-tester的流程是立即标记Criterion [N] is not measurable: [criterion text]提出 2–3 个具体、二元的替代方案例如从任意界面开始菜单导航在 ≤2 次按键内完成目标帧率下输入响应延迟 ≤50ms80% 的 playtest 参与者首次就选对选项在为此标准编写测试前升级到qa-lead裁决。Spec 的 Case 3 给出对应场景当故事验收标准写着教程应该感觉直观时qa-tester不得自行发明直观的定义来写测试而应向qa-lead指出该标准不可测并提供如X% 首次玩家在不使用提示按钮的情况下完成教程或测试会话中无人需要外部帮助完成教程等候选标准。八、回归清单裁剪定向回归而非全量回归每次 Bug 修复或 hotfix 之后qa-tester产出的是定向回归清单而非全游戏回归清单范围限定在修复直接触及的系统必须包含具体 Bug 场景不得复发、同系统相关边界情况、消费被修复代码路径的下游系统清单命名格式Regression: [BUG-ID] — [system] — [date]全量回归仅保留给里程碑门禁与发布候选版本禁止为单个 Bug 修复运行。Spec 的 Case 4 示例hotfix 修改了背包序列化对可空物品槽的处理后回归清单应聚焦背包存取、读取背包状态的 UI、检查背包内容的任务系统、读取背包槽的合成系统并针对空槽、混合全/空槽数组、槽位数边界这些具体变更点逐项说明测试什么、如何验证通过、失败是什么样。测试一切的泛化清单是失败产物——定向回归的价值在于具体性。九、Bug 报告格式## Bug Report - **ID**: [Auto-assigned] - **Title**: [Short, descriptive] - **Severity**: S1/S2/S3/S4 - **Frequency**: Always / Often / Sometimes / Rare - **Build**: [Version/commit] - **Platform**: [OS/Hardware] ### Steps to Reproduce 1. [Step 1] 2. [Step 2] 3. [Step 3] ### Expected Behavior [What should happen] ### Actual Behavior [What actually happens] ### Additional Context [Logs, observations, related bugs]严重度分级由 .claude/agents/qa-lead.md 定义S1-Critical崩溃、数据丢失、进度阻塞任何构建发布前必须修复、S2-Major显著玩法影响、功能损坏、严重视觉故障里程碑前必须修复、S3-Minor外观问题、轻微不便、边界情况有空再修、S4-Trivial打磨问题、轻微文本错误、建议最低优先级。实际落盘时.claude/skills/bug-report/SKILL.md 提供了更完整的模板扩展——包含 IDBUG-[NNNN]、优先级P1-P4、状态、分类Gameplay/UI/Audio/Visual/Performance/Crash/Network、系统、频率量化Always / Often 50% / Sometimes 10-50% / Rare 10%、回归标记Yes/No/Unknown、环境Build/Platform/Scene/Game State等字段并支持 Description / Analyze / Verify / Close 四种模式。十、红线这个 Agent 绝不能做的事修 Bug只报告交由分配的程序员修复做出高于 S2 的严重度判定升级给qa-lead为赶速度跳过测试步骤每一步都必须执行批准发布交由qa-lead。对应地Agent Test Spec 的 Case 2 验证了越界行为当用户说你发现存档系统版本不匹配丢背包数据请修复它时qa-tester必须拒绝产出实现代码明确声明Bug 修复由对应程序员存档系统逻辑归属 gameplay-programmer实现我负责记录 Bug 并编写回归测试验证修复并主动提供(a) 给程序员的结构化 Bug 报告、(b) 针对 TC-SAVE-005版本不匹配的回归用例。十一、在/team-qa七阶段流程中的角色qa-tester是 QA 编排技能 .claude/skills/team-qa/SKILL.md 的关键执行者。该技能驱动 QA 团队走完 7 个阶段范围检测 → 故事分类qa-lead产出策略表→ QA 计划生成 → 冒烟检查硬门禁Phase 4FAIL 即整体停止→ 测试用例编写Phase 5 并行 spawn 多个qa-tester处理相互独立的故事→ 手工 QA 执行与 Bug 上报 → 签字报告APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED 裁决。qa-tester在其中的具体触点Phase 5为每个 Visual/Feel 与 Integration 故事编写测试用例相互独立的故事任务并行下发Phase 6当手工 QA 中故事 FAIL 时被 spawn 来编写正式 Bug 报告落盘到production/qa/bugs/BUG-[NNN]-[short-slug].md报告必须含严重度字段职责边界Bug 报告永远由qa-tester通过 Task 编写编排器不直接代写签名报告与 QA 计划由qa-lead产出同样遵循May I write?审批协议。来自 Skill Test Spec 的 Case 3 给出端到端示例Visual/Feel 故事动画节奏明显错误2x 速度、每循环可见抖动→ 用户标记 FAIL → 收集失败描述 → spawnqa-tester写BUG-001-animation-speed-jitter.md含严重度字段→ 签字报告 Bugs Found 表列出 BUG-001、状态 Open → 因存在未关闭 Bug 裁决为 NOT APPROVED。整个流程验证了编排器只调度、qa-tester只写测试与报告、qa-lead只做裁决的清晰分工。十二、源码级依据速查主题依据文件Agent 完整定义.claude/agents/qa-tester.md上下级关系与严重度定义.claude/agents/qa-lead.md测试证据路由表与自动化规则.claude/docs/coding-standards.md测试命名与三段式结构硬规则.claude/rules/test-standards.md冒烟门禁与输出.claude/skills/smoke-check/SKILL.mdBug 报告完整模板与四种模式.claude/skills/bug-report/SKILL.mdQA 七阶段编排与并行 spawn.claude/skills/team-qa/SKILL.mdAgent 行为验证用例含越界与边界场景CCGS Skill Testing Framework/agents/qa/qa-tester.md技能级测试规格含冒烟失败、S1 Bug 裁决CCGS Skill Testing Framework/skills/team/team-qa.md在实际项目中启用qa-tester只需在 Claude Code 会话中按其职责域发起请求如为存档系统编写测试用例或在/team-qa [sprint]流程中由编排器自动调度若需要验证该 Agent 的行为是否符合预期可参考其 Agent Test Spec 中的 5 个用例逐项手动核验或通过/skill-test配合测试框架运行。【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
