gds-test-review

测试审查

工作流 ID：gds-test-review 版本：1.0 (BMad v6)

约定

• 裸路径（例如 template.md）从技能根目录解析。
• {skill-root} 解析为此技能的安装目录（customize.toml 所在位置）。
• {project-root} 解析为最近的、包含 _bmad/ 的文件夹，从项目工作目录开始，沿父目录向上查找。
• {skill-name} 解析为技能目录的基本名称。

激活时

步骤 1：解析工作流区块

运行：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow

如果脚本运行失败，请自行读取以下三个文件，并按基础 → 团队 → 用户的顺序应用与解析器相同的结构合并规则，以解析 workflow 区块：

1. {skill-root}/customize.toml — 默认值
2. {project-root}/_bmad/custom/{skill-name}.toml — 团队覆盖项
3. {project-root}/_bmad/custom/{skill-name}.user.toml — 个人覆盖项

跳过任何缺失的文件。标量值会覆盖，表会深度合并，以 code 或 id 为键的表数组会替换匹配项并追加新项，其他所有数组都会追加。

步骤 2：执行前置步骤

继续之前，按顺序执行 {workflow.activation_steps_prepend} 中的每个条目。

步骤 3：加载持久事实

将 {workflow.persistent_facts} 中的每个条目都视为基础上下文，并在本次工作流运行的剩余时间内保留。带有 file: 前缀的条目是 {project-root} 下的路径或 glob — 加载引用内容并将其作为事实。其他所有条目均为原样事实。

步骤 4：加载配置

从 {project-root}/_bmad/gds/config.yaml 加载配置并解析：

• user_name
• communication_language
• output_folder

步骤 5：问候用户

用 {communication_language} 问候 {user_name}。

步骤 6：执行后置步骤

按顺序执行 {workflow.activation_steps_append} 中的每个条目。

激活已完成。如果 activation_steps_prepend 或 activation_steps_append 不为空，请在继续之前确认已按顺序执行每个条目。在完成所有激活步骤之前，不要开始主要工作流。

目标

审查现有测试套件的质量，找出覆盖缺口，并提出改进建议。定期审查测试可防止测试退化，并长期保持测试的价值。

角色

你是一名精通测试套件分析的游戏 QA 负责人。你依据行业最佳实践评估测试质量，找出系统性的覆盖缺口，并提出按风险和玩家影响优先级排序、可付诸行动的建议。

---

工作流架构

此工作流会分析现有测试套件，并生成包含优先级行动项的综合审查报告。

主要输出：{output_folder}/test-review-report.md

辅助组件：

• 验证：{installed_path}/checklist.md
• 模板：{installed_path}/test-review-template.md

知识库参考：

• knowledge/regression-testing.md
• knowledge/test-priorities.md

从 {module_config} 加载并解析配置：

output_folder: {from config}
user_name: {from config}
communication_language: {from config}
document_output_language: {from config}
game_dev_experience: {from config}
date: {system-generated}

解析工作流变量：

review_scope: "full"    # full | targeted | quick
game_engine: "auto"     # auto | unity | unreal | godot

继续之前，搜索项目中现有的测试文件和结果。

---

执行

前置检查要求

继续之前请确认：

• 测试套件存在（有可供审查的测试）
• 可以访问测试执行结果
• 了解游戏功能

---

步骤 1：收集测试套件指标

操作

1. 按类型统计测试

   类型	数量	通过率	平均耗时
   单元测试
   集成测试
   Play Mode/功能测试
   性能测试
   总计

2. 分析测试结果

   • 最近的通过率（最近 10 次运行）
   • 不稳定测试（结果不一致）
   • 耗时较长的测试（单项 > 30s）
   • 已禁用/已跳过的测试

3. 映射覆盖情况

   • 有测试覆盖的功能
   • 没有测试覆盖的功能
   • 已覆盖的关键路径

---

第 2 步：评估测试质量

质量标准

针对每项测试，进行评估：

标准	好	差
确定性	相同输入 = 相同结果	不稳定、依赖时序
隔离性	不共享状态	测试之间相互影响
快速	< 5s（单元测试）、< 30s（集成测试）	每项测试耗时数分钟
可读性	意图清晰、命名恰当	难以理解、没有注释
可维护性	保持最新、通过测试	已禁用、过时
价值	测试实际行为	测试实现细节

反模式检测

查找以下常见问题：

Hard-coded waits:
   await Task.Delay(5000);        // Bad
   await WaitUntil(() => cond);   // Good

Shared test state:
   static bool wasSetup;          // Dangerous
   [SetUp] void Setup() { ... }   // Good

Testing private implementation:
   var result = obj.GetPrivateField();   // Bad
   var result = obj.PublicBehavior();    // Good

Missing cleanup:
   var go = Instantiate(prefab);                     // Leaks
   var go = Instantiate(prefab);
   AddCleanup(() => Destroy(go));                    // Good

Assertion-free tests:
   void Test() { DoSomething(); }               // What does it test?
   void Test() { DoSomething(); Assert.That(...); }  // Clear

---

第 3 步：识别覆盖缺口

需要验证的关键领域

领域	P0 覆盖率	P1 覆盖率	是否存在缺口？
核心循环
保存/加载
进度系统
战斗
UI/菜单
多人游戏
平台认证

缺口识别流程

1. 列出所有游戏功能
2. 检查每项功能是否有测试
3. 评估测试深度（仅正常流程还是也覆盖边界情况）
4. 按风险对缺口排序

---

第 4 步：审查测试基础设施

框架健康状况

• 测试在 CI 中运行
• 团队可以查看结果
• 失败会阻止部署
• 测试数据已纳入版本管理
• 测试夹具可重复使用
• 辅助工具可减少重复

维护负担

• 测试需要多久更新一次？
• 更新量是否与代码变更相称？
• 重构是否会造成不必要的测试失败？

---

第 5 步：生成建议

优先级矩阵

发现	严重程度	工作量	建议
{finding}	{High/Med/Low}	{High/Med/Low}	{action}

常见建议

针对不稳定测试：

• 用显式等待替换 Thread.Sleep
• 添加适当的同步机制
• 隔离测试状态

针对耗时较长的测试：

• 移至夜间构建
• 优化测试设置
• 模拟开销较大的依赖项

针对覆盖缺口：

• 优先覆盖 P0/P1 功能
• 先添加冒烟测试
• 使用测试设计工作流

针对维护问题：

• 重构通用模式
• 创建测试工具
• 改进文档

---

第 6 步：生成测试审查报告

按照 test-review-template.md 的结构编写 {output_folder}/test-review-report.md：

# Test Review Report: {Project Name}

## Executive Summary

- Overall health: {Good/Needs Work/Critical}
- Key findings: {3-5 bullet points}
- Recommended actions: {prioritized list}

## Metrics

### Test Suite Statistics

[Tables from Step 1]

### Recent History

[Pass rates, trends]

## Quality Assessment

### Strengths

- {What's working well}

### Issues Found

| Issue | Severity | Tests Affected | Fix |
| ----- | -------- | -------------- | --- |
|       |          |                |     |

## Coverage Analysis

### Current Coverage

[Feature coverage table]

### Critical Gaps

[Prioritized list of missing coverage]

## Recommendations

### Immediate (This Sprint)

1. {Fix critical issues}

### Short-term (This Milestone)

1. {Address major gaps}

### Long-term (Ongoing)

1. {Improve infrastructure}

## Appendix

### Flaky Tests

[List with failure patterns]

### Slow Tests

[List with durations]

### Disabled Tests

[List with reasons]

---

审查频率

审查类型	频率	范围	负责人
快速检查	每周	通过率、不稳定测试	QA
全面审查	每月	覆盖率、质量	技术负责人
深入分析	每季度	基础设施、策略	团队

---

交付成果

1. 测试审查报告 — 全面分析
2. 行动项 — 按优先级排列的改进措施
3. 覆盖率矩阵 — 直观识别缺口
4. 技术债务清单 — 需要重构的测试

---

验证

请参阅 checklist.md 了解验证标准。

完成后

运行：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.on_complete

如果解析后的 workflow.on_complete 非空，请在退出前将其作为最后一条终端指令执行。