SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场soak-test

soak-test

测试与质量

查看项目

更新于 10-15 14:30

技能介绍

用途

Soak Test（浸泡测试，又称耐久测试）是一种带有明确观察目标的长时间游玩会话。与冒烟检查（覆盖关键路径，约 10 分钟）或单功能试玩（约 30 分钟）不同，浸泡测试持续 30 分钟到数小时，用于暴露以下问题：

  • 内存泄漏：仅在场景切换后出现的堆内存逐渐增长
  • 性能漂移：随时间推移而恶化的帧时间
  • 状态累积缺陷：仅在某个机制重复 N 次后出现的问题（背包满、分数溢出、AI 状态损坏）
  • 乐趣疲劳：首次会话感觉良好但长时间游玩后变得重复的机制
  • 内容枯竭：玩家耗尽新颖内容的临界点

本技能生成观察协议与分析框架，实际游玩由人类完成。

输出：production/qa/soak-test-[date]-[duration].md

适用时机：打磨阶段（在 /gate-check release 之前）、修复内存或稳定性问题之后（回归浸泡）、长时间游玩尚未被正式追踪时。

主要能力

参数解析

时长（默认 1h）：

  • 30m — 短浸泡，适合测试单个机制或场景
  • 1h — 标准浸泡，覆盖大多数常见泄漏类别
  • 2h — 扩展浸泡，推荐用于首次完整打磨浸泡
  • 4h — 深度浸泡，长会话设计游戏（RPG、模拟类）必需

重点（默认 all）：

  • memory — 关注堆大小、对象数量、泄漏模式
  • stability — 关注崩溃/冻结/挂起检测
  • balance — 关注乐趣疲劳、内容枯竭、难度感知
  • all — 以上全部

上下文加载

读取 project.yaml（engine.name 与 performance.* 预算，缺失时回退到 .claude/docs/technical-preferences.md）、design/gdd/game-concept.md（预期会话长度与核心循环，或 design/game-brief.md）、production/qa/playtests/ 中最近的文件（避免重复记录已知问题）、production/qa/qa-plan-*.md 中最近的文件（了解已正式测试的内容）。

观察检查点

根据时长生成定时检查点：

  • 30m：T+0、T+10、T+20、T+30
  • 1h：T+0、T+15、T+30、T+45、T+60
  • 2h：T+0、T+20、T+40、T+60、T+80、T+100、T+120
  • 4h：T+0、T+30、T+60、T+90、T+120、T+180、T+240

协议生成

内存/稳定性观察项（focus = memory 或 all）：提供引擎特定监控指引。记录工具显示的原始单位，不做换算，也不假设单位。所有阈值均为相对本次会话 T+0 基线的比率或增量，与单位无关。

  • Godot 4：Debugger → Monitors 标签页，跟踪 Memory → Static Memory 与 Object Count → Objects；记录 Static Memory（按显示单位）、Object Count、Orphan Nodes。告警阈值：前 15 分钟后内存增长超过 T+0 的 20%。Orphan Nodes 是唯一值得关注的绝对值，场景卸载后应回到 T+0 值。
  • Unity：Memory Profiler（Window → Analysis → Memory Profiler）；记录 Total Reserved Memory、GC Allocated、Object Count（按显示单位）。告警阈值：GC Allocated 在 3 个以上检查点单调增长。
  • Unreal Engine：使用 stat memory 控制台命令；记录 Physical Memory Used、Physical Memory Available（按显示单位）。告警阈值：整个浸泡期间 Physical Memory Used 相对本次 T+0 增长超过 20%。

注意：上述工具、面板与计数器名称未被 docs/engine-reference/ 覆盖，属于测试者需在自己编辑器中于 T+0 确认的指引，而非已验证路径。若找不到内存工具，则未测量任何内容，结论部分适用 NOT ASSESSED。

稳定性观察项（focus = stability 或 all）：每个检查点记录是否发生崩溃/挂起/冻结、帧率是否仍在目标预算内、音频是否正常、HUD 是否正常渲染、输入是否正常响应。

平衡/疲劳观察项（focus = balance 或 all）：每个检查点收集主观观察——核心机制是否仍有回报感（Y/N）、感知难度（太简单/合适/太难）、是否出现“我见过这个”的时刻（内容枯竭）、是否有挫败时刻（记录原因）、是否有高峰投入时刻（记录原因）。

协议文档结构

生成的文档包含：

  1. 会话前准备：从全新启动运行、关闭后台应用、打开性能监控工具、确认浸泡目标、列出需关注的已知问题
  2. 基线（T+0）：在开始游玩前记录内存/堆、对象数量、FPS（前 30 秒）、引擎特定指标
  3. 检查点日志：每个定时检查点记录内存/稳定性表格（含相对基线增量与告警标记）、稳定性检查清单、平衡/疲劳观察、自由观察
  4. 会话后分析：内存趋势表（含每小时外推增量、是否检测到泄漏、按当前速率估算 OOM 时间）、稳定性汇总（崩溃/挂起总数、最差 FPS、性能退化程度）、平衡/疲劳汇总（乐趣曲线、内容枯竭点、难度弧线）、问题列表（ID、严重度、检查点、描述）
  5. 结论：PASS / PASS WITH CONCERNS / NOT ASSESSED / FAIL
  6. 签署：测试者与 QA 负责人

结论判定规则

  • PASS：未检测到泄漏、稳定性保持、乐趣因素一致
  • PASS WITH CONCERNS：注意到轻微漂移或疲劳，可在打磨阶段解决
  • NOT ASSESSED：浸泡未运行到能显示其目标问题的长度——需说明运行到何处、哪些检查点未达到
  • FAIL：确认内存泄漏、稳定性违规或严重乐趣疲劳

短浸泡不能返回 PASS。本协议要检测的一切（缓慢泄漏、疲劳、后期出现的边缘情况）按定义在早期不可见，因此在检查点之前结束的会话并未显示稳定性，而是什么都还没显示。记录 NOT ASSESSED — reached T+[N] of [duration]; checkpoints [list] not reached。其等级高于两个 PASS 值、低于 FAIL：T+20 观察到的崩溃是真实发现，无论运行多短，都不应因运行长度而降级。同样适用于构建因与浸泡无关的原因崩溃、无内存检测工具可用（未测量任何内容，因此“未检测到泄漏”意味着“不可能检测到泄漏”）、或协议已写但从未执行（协议文档不是结果）的情况。

使用方式

  1. 调用技能并指定时长与重点（或使用默认值）
  2. 技能加载项目上下文并生成协议文档
  3. 在对话中展示协议摘要，询问是否写入 production/qa/soak-test-[date]-[duration].md
  4. 仅在批准后写入
  5. 写入后按指引运行：打开文件、遵循会话前准备清单、游玩时记录每个检查点、完成后填写会话后分析、将“Issues Found”中的问题提交到 production/qa/bugs/、会话后运行 /bug-triage sprint 整合 S1/S2 问题（在 workflow: minimal 下无 sprint，使用 /bug-triage full）、若结论为 FAIL 则在修复后重新运行 /smoke-check

适用场景

  • 打磨阶段发布门禁前的正式验证
  • 修复内存或稳定性问题后的回归浸泡
  • 长时间游玩尚未被正式追踪的项目
  • 需要评估乐趣疲劳与内容枯竭的平衡性验证

限制

  • 本技能生成协议，人类运行它——绝不可尝试自动运行浸泡测试，观察需要人类观察者
  • 时长应匹配游戏的会话设计——5 分钟的游戏不需要 4 小时浸泡，城市建造类可能需要；不确定时应询问
  • 首次浸泡应使用 all 重点——窄焦点（仅内存）用于特定修复后的回归浸泡，而非首次
  • 写入前始终确认
  • 自动化模式解析：modes.automation（project.local.yaml → project.yaml → 默认 collaborative）；每次 AskUserQuestion 调用与文件写入遵循 .claude/docs/automation-modes.md（collaborative 总是询问 · guided 仅主要项 · autonomous 记录并继续；automation_always_ask 类别总是提示）