让 AI 顺着一次 游戏 更新去测试
让 AI 顺着一次 游戏 更新去测试
读 SMART 研究时（一篇公开研究提出的游戏测试框架），我开始重新想一遍：游戏改了以后，自动化该从哪里重新走起。
给一款做饭游戏加一台烤箱，更新说明可以很短。厨房里多了一个设备，玩家终于能做披萨了。测试人员拿到新版本，却得先把这句话拆开：原料怎样取得，半成品能放在哪里，什么时候算烤好，做好的东西又能不能交出去。
如果让一个自动化角色进厨房，它也许很快就能学会做一份披萨。看着它顺利交餐，我们很容易觉得，这次更新大概已经跑通了。可测试时，我还会想知道：它有没有走到这次新加的处理逻辑，还是恰好沿着一条最顺利的路线，把其他情况绕开了。
最近读到的 SMART 研究，就从游戏更新后的测试范围入手。读它时，我在意的是一个很实际的问题：已经能操作游戏的 AI，该怎样知道这一版值得多看哪里？这项研究没有在我的 LQA 工具里复现，下面先讲论文做了什么，再谈它让我想到的事情。
01先弄清楚这次要去哪里
SMART 把新旧代码的结构差异与游戏任务联系起来，让大语言模型整理中间目标，再生成可执行的奖励条件；实际探索由强化学习 Agent 完成。研究在 Overcooked 的开源实验实现和 Minecraft 环境中比较了不同方案。它关注的是有限的增量更新，不能理解成 AI 已经能够接手任意游戏的完整测试。[1]
这里的两类 AI 分工值得分清。大模型先参与准备任务，强化学习 Agent 再通过反复交互寻找行动方式。这和我们平时把截图发给模型、等它回答下一步点哪里，运行条件很不一样。拿来做 LQA 参考时，我不会把两套方法直接视为可以互换的实现。
我更愿意借用它提出问题的顺序。以前设想自动化时，我容易先关心入口能不能打开、动作能不能继续。到了游戏持续更新的阶段，前面还多了一件事：这次变化会影响哪些原有操作，要把哪些位置重新放进检查范围。即使所有入口都还能走通，沿用旧路线也未必足够。
例如，假设烤箱新增了中途取出的操作。只让脚本照旧等到烤好，再取出成品，当然也能完成任务。可新加的操作从未发生，它对应的状态提示也没有机会出现。自动化运行得很稳定，测试计划却已经落后于版本。
如果系统能够把本次变化整理成几项有出处的检查建议，人至少可以看见它为什么要求重走这些位置。至于建议有没有遗漏、理解是否准确，还得对照需求和实际变化核实。这里有机会减少的是重新梳理范围的工作，不能顺手省掉核对范围这一步。
02顺利完成以后还要看什么
SMART 的探索同时受到任务进展与相关代码覆盖的引导。在作者的比较中，结合两类信号比只追求任务完成，更能兼顾任务与覆盖。不过，实验里的覆盖仍是特定更新范围内的覆盖，不能换算成整个游戏的完成度。[1]
这让我想到测试角色和普通玩家之间一个很朴素的差别。玩家找到省事的办法，往往就愿意继续用它。测试人员走通以后，可能还得回来试试另一个操作时机，或者看看条件不满足时会发生什么。为了尽快完成任务而形成的习惯，有时正好会绕开我们想检查的情况。
放到这个虚构厨房里，第一轮确认烤好的披萨可以交付，接下来还可以按需求安排中途取出、没有原料时尝试启动等检查。哪些操作被允许，哪些应该拒绝，要先有游戏自己的规定。光让 Agent 多试几次，并不会自动得到这些答案。
代码覆盖能帮助发现有些处理逻辑还没执行过，但执行过也不意味着结果正确。Unity 的覆盖说明同样提醒，覆盖记录反映代码是否运行，不能直接衡量测试质量。[2] 看到一次操作经过了某个条件判断，我仍然需要知道，它随后显示的内容和产生的状态是否符合要求。
比如，一次背包已满的检查确实被触发了，界面也弹出提示，这两件事都发生了。提示是否告诉玩家无法取得成品，物品有没有因此丢失，仍然是另外要核对的结果。只有“分支已覆盖”的记录，没法替我们确认这些细节。
我因此更在意一条路线能留下什么。如果能保留触发条件、操作过程与结果，就有机会把一次探索整理成后续的复测场景。等这个位置修好，再用同样的条件回来核对，才方便分辨修改是否生效。单独保存一条“任务成功”，后面可利用的信息会少很多。
03放进 LQA 以后还缺什么
这篇论文主要研究玩法更新。我把它往 LQA 上想时，会先补上文本和资源这一层。一次状态变化可能带出新提示，也可能继续使用旧提示；这些内容又可能来自翻译表、动态参数，或者独立的图片资源。只盯着主要逻辑代码的差异，很难据此列出完整的本地化检查范围。
论文也讨论了类似限制：它采用的代码结构分析，无法充分覆盖界面布局、模型和图形资源等变化。[1] 因此，这条思路对我的启发，更多在于关联变化与检查位置。真要用于 LQA，还需要知道文本、界面和游戏状态之间怎样相连。
继续拿烤箱举例。“烘烤中”这条文字没有修改，程序却把它从单独一行移到了带图标的窄栏里。如果增量检查只认翻译表里改过的行，它可能会被跳过。实际运行时，某种语言却可能已经放不下了。这里需要重新检查的原因，来自显示条件的变化。
还有一种情况，界面仍然使用同一个文本 Key，但它出现的时机变了。旧版本是在食物放进烤箱后显示，新版本可能在准备阶段就显示。译文曾经依据旧时机写得很明确，现在就值得重新核对。资源标识能够帮忙找到它，却不能单独证明那条译文仍然适用。
对这种检查，我希望工具能够说清楚“为什么回来”：哪个位置发生了变化，可能影响哪条内容，准备在什么状态下观察。拿到这个理由以后，人可以补充遗漏的关联，也可以排除没有影响的变化。它比笼统地宣布要把所有界面再跑一次，更方便讨论实际范围。
等到发现异常，信息还要继续往下走。截图留下当时的显示事实，运行时数据帮助定位资源，语言资料提供采用依据。AI 对原因的解释先作为线索保留。有了能够复核的候选问题，再决定是否立项、改哪里，后面的修复和复测才接得上。
04先把这一小块说明白
还有一层我会保留警惕：如果测试目标完全从新代码里推出来，代码本身的错误也可能被当成要求。假设需求规定烤好以后可以随时取出，实现却多加了限制，模型读完实现，也许会把这个限制写进测试计划。那样即使执行得很认真，检查的也是一份有问题的预期。
所以，变化记录适合提示我们去哪里，预期行为还得有独立依据。需求说明、确认过的设计决定和已有回归场景，应该能够与模型整理的目标互相核对。材料有分歧时，把分歧留下来，比让 AI 选一个听起来合理的说法更有帮助。
从实验走进项目，还会多出接入和维护的工作。EA 的公开技术报告谈过把强化学习系统接进已有脚本机器人测试方案的尝试，也专门讨论研究环境与大型游戏生产环境之间的距离。[3] 读这些材料时，我很难把模型的一次漂亮表现，直接想成一套可以交给团队长期使用的流程。
每次更新都要有人能够检查任务范围，知道未完成的部分停在哪里。自动化生成的路线也要经得住版本变化，过期的路线不能一直沿用。至于是否比现有方法划算，还要把准备环境、反复交互和人工复核的时间一起算进去。这些都需要实际项目里的对照，论文中的结果不能替我们结算。
如果继续尝试这个方向，我会先选一个范围明确的更新。把受影响的位置和验收要求先列出来，再看系统建议的范围是否有遗漏，观察它能否留下供人检查的过程和结果。与此同时，还要保留必要的原有功能回归，不能因为注意力集中到新功能，就默认周边没有受影响。
回到厨房里的那台烤箱，我现在更想看到一份说得清楚的记录：这次回来检查了哪些操作，哪些状态仍然没走到，发现的异常怎样交给人处理。能够顺利做出披萨当然很好，但要把这次更新交出去，我还想知道那条顺利路线之外，哪些地方已经看过，哪些仍然需要再来。
参考资料
感谢你的阅读。
本文由 Uberleben 创作，原创声明，未经授权不得转载
关注 游戏AI本地化翻译 每周3篇左右，分享AI工具如何赋能游戏本地化翻译
如果你觉得今天这篇有收获，欢迎赞同、喜欢、收藏，我们下篇见
来源：知乎 · AI 游戏文章 · zhuanlan.zhihu.com