爱游戏游戏测试观察组
先看一个穿墙案例
假设测试Agent在“灰烬回廊”里巡逻，某一帧，角色坐标从东侧走廊跳到了西侧房间，中间隔着一堵实心墙。按最直观的规则，这是穿墙BUG。但如果规则库里有一条“玩家技能‘影步’可在冷却完毕后向前瞬移最多八米，不检测阻挡”，这就是正常行为。判断一个结果是否为BUG，依赖的不是画面，而是“预期是什么”。这个用来回答“预期是什么”的依据，就是测试Oracle（测试判定依据）。
这正是爱游戏测试AI需要单独设计Oracle的原因。没有Oracle的测试Agent只能发现一类问题，就是崩溃和卡死这些不需要解释的问题。测试Agent能主动制造大量奇怪状态，但如果不知道哪些状态不对，探索得越多，噪声越多。
Oracle的分层：越靠上越确定
| 层级 | 判定依据 | 典型例子 | 误报风险 | 需要的输入 |
|---|---|---|---|---|
| 通用信号 | 程序本身出错 | 崩溃、无响应、断言失败、日志出现错误级别 | 很低 | 进程与日志监控 |
| 代码断言 | 开发写在代码里的检查 | 耐久不得为负、数组下标不越界 | 低 | 开发提前埋点 |
| 不变量 | 任何时刻都应成立的关系 | 背包总重不超过上限、同一任务不能同时“已完成”和“进行中” | 低到中 | 与设计一起提炼 |
| 规则库 | 设计文档与配置表 | “影步”最大距离、掉落表、任务前置条件 | 中 | 结构化的规则数据 |
| 差分 | 与旧版本或参考实现对比 | 同一存档同一操作，上一版本结果是A，这一版是B | 中，改动本身也会造成差异 | 基线版本与对比工具 |
| LLM判定 | 模型读规则与证据后给出判断 | “对话文本说任务已完成，但任务面板显示未完成” | 较高 | 规则、状态摘要、截图 |
这张表的关键是把“确定程度”与“覆盖范围”摆在一起看：上面几层几乎不会出错，但只能发现有限的一类问题；下面几层能覆盖“逻辑上不对”的广阔区域，代价是需要更多验证。一个稳妥的测试体系，会让上层给出高置信度的确认，让下层提供线索，并把线索交给人。
规则从哪里来
Oracle再聪明，也只能基于规则。规则的来源大致有三类。
- 设计文档：最全面，但通常是自然语言，含糊、过时，需要整理成结构化条目。
- 配置表：技能参数、物品属性、掉落表、任务前置，它们是游戏真正在使用的数据，也最适合直接转成可执行的检查。
- 代码断言和已知缺陷：开发在代码里埋下的检查，以及历史BUG沉淀出的回归条目。
规则库要带版本。上个补丁里“影步”的距离是八米，这个补丁改成六米，Oracle用错了版本，就会把正常行为报成BUG，或者把真正的BUG当成正常。这一点和我们在长程测试里强调的“记录构建号与环境”是同一个道理，可以参考长时间运行后才暴露的BUG中对轨迹字段的讨论。
用穿墙案例走一遍判定流程
- 通用信号：进程正常，没有崩溃，无日志错误。此层无结论。
- 不变量：“角色坐标每帧位移不得超过最大速度乘以帧间隔，除非本帧有位移类技能事件。”本帧位移远超限制，而事件日志里存在“影步”释放记录，这条不变量被技能事件豁免，通过。
- 规则库：影步最大距离八米，实际位移约七米，在范围内；冷却时间已满足，通过。
- 再查一个细节：规则库里写明“影步不能穿越标记为‘不可穿越’的墙”，而这堵墙恰好带此标记。此时判定为疑似BUG，附上坐标、事件日志和墙体属性。
- 人工复核：开发查看后确认，是这堵墙的标记漏配，而非技能逻辑错误。修复的是数据，不是代码。
这个流程里，没有哪一步靠“看起来不对劲”，每一步都基于一条可以被指出来的规则。最后一步也说明，Oracle给出的结论只能是“疑似”，根因判断仍在人。
LLM Oracle：能帮什么，风险在哪
有些不一致很难写成规则，比如NPC的对话文本与任务面板不一致、道具描述与实际效果不一致。这时可以让大语言模型读取规则条目、状态摘要和相关文本，给出“是否矛盾”的判断。爱游戏对这个层级的态度是：可以用，但只做线索，不做终审。
- 误报：模型可能把设计意图当成BUG，例如把“NPC故意撒谎”当成文本错误。
- 漏报：模型可能忽略微小的数值偏差，也可能因为上下文太长而漏读关键规则。
- 需要证据：每条判断都应附带具体的规则条目、状态字段和文本片段，让人能快速核对，不能只给一句“这里有问题”。
- 需要可复现：同样的输入多次判断，结果不应经常摇摆。
差分Oracle的一个常见误区
与旧版本对比听上去很省事：同一个存档、同一串操作，旧版本结果是A，新版本变成了B，就报警。但补丁本来就是要改东西的。把“有差异”直接当成“有BUG”，会在每次平衡调整之后产生大量误报。更合理的做法，是让差分结果先与本次补丁的变更清单核对：清单里写明改动了影步距离，那么距离相关的差异被视为预期；清单里没有提到的差异才值得重点看。爱游戏AI在设计差分层时，倾向于把变更清单也当成一种规则输入。
人工复核流程
比较合适的流程是：Oracle把疑似问题分成“高确定”和“待确认”两档，高确定的直接进入缺陷列表，待确认的按影响程度排序交给人。人的判断再回流成规则：如果复核后发现是设计如此，就把这个例外写进规则库，避免下一次再报；如果确认是BUG，则把它写成新的不变量，让以后的版本自动检查。这样，Oracle会随着项目积累而变准，而不是一次性配置完事。爱游戏的测试思路里，机器负责大范围地提出“哪里可能不对”，规则负责回答“凭什么说不对”，人负责最后一句“到底改不改”，三者缺一不可。对于手感、节奏、乐趣这类没有规则可依的问题，Oracle无能为力，仍然要交给真人试玩来判断。
