游戏自动化测试：从脚本到AI智能体的落地实践
游戏自动化测试：从脚本到AI智能体的落地实践
过去一年，我在三个不同类型的游戏项目里推动过同一件事：把跑在流水线上的自动化测试，从一堆脆弱的脚本，改造成能自己看、自己点、自己判断的智能体。结果并不像宣传里那样一帆风顺。有一次，一个新接入的智能体在两天内报了四百多条缺陷，团队兴奋地逐条复核，最后确认真正有效的只有十一条，其余全是它在动画过渡帧里看不清造成的误报。那件事让我彻底放下了AI一来、脚本就退休的幻想，也让我开始认真追问：从脚本到智能体，中间到底隔着什么？
我的结论可能不够性感，但足够真实：脚本没有过时，它只是被我们过度使用了；智能体也不是银弹，它只是把测试工程师的注意力，从怎么点转移到了什么才算错。这篇文章想聊的，就是这条迁移路径上的坑、方法与判断。
一、脚本时代：一项被高估的手艺
游戏自动化测试的起点，几乎都长得一样：录制回放。
早期的思路非常朴素——人在真机上操作一遍，工具把点击坐标和时间戳记下来，回放时按同样的坐标再点一遍。这套方法在很长一段时间里养活了一整条工具链，也的确解决了一个真问题：回归测试是体力活，人力跑不完。一个玩法改动之后，需要有人把主流程从头到尾走一遍，确认没有把别的地方弄坏。这件事重复、枯燥、且必须有人做。
但很快就撞墙了。
墙的第一层是分辨率与机型。安卓生态的碎片化让坐标这种东西天然脆弱，同一份脚本换一台设备就全盘作废。于是有了第二层方案：图像识别。用模板匹配去找按钮的图标、找血条的像素颜色、找界面上的关键字。这一步进步很大，因为它第一次让脚本有了视觉。
第二层墙随之而来：动画。游戏不是静态表单，帧与帧之间按钮会呼吸、会缩放、会被粒子特效覆盖。模板匹配在动态场景下召回率骤降，于是又有了第三层：协议层与引擎层介入。直接在游戏引擎里暴露钩子，或者从网络协议抓包断言，绕过界面直接验证逻辑。
到这里，脚本时代其实已经相当成熟了。界面自动化负责表现层，协议断言负责逻辑层，性能采集负责帧率与内存。到2023年前后，很多头部项目的自动化覆盖率已经能做到回归用例的七成以上，一些团队甚至把它接进了每日构建，做到每次提交自动验证。
那问题出在哪？
问题出在，这条技术路线对人的投入是线性依赖的。每上线一个新玩法、每改一次界面、每加一个活动弹窗，就会有一批脚本失效。维护成本随用例数线性上涨，而收益却是边际递减的。到最后，团队里一半的自动化人力不是在写测试，而是在修测试。我曾经统计过一个中型项目的数据：三千多条自动化用例里，超过四成在过去三个月内没有成功执行过一次，而维护它们的时间占了整个QA团队近三成的工作量。
这才是脚本时代真正的天花板：不是它不能测，而是它不划算。
二、游戏测试为什么比普通软件测试更难
在讨论AI之前，我想先把难这件事说清楚，因为很多从其他行业迁移过来的方案，都低估了它。
第一，状态空间是爆炸的。一个网页应用的表单，输入组合再多也有限；而一局对战游戏，从开局第一秒起，每一个单位的位置、血量、技能冷却、网络延迟都在连续变化。你想穷举，数学上就不成立。
第二，正确性本身是模糊的。网页少渲染一个按钮叫缺陷，游戏里怪物卡进墙里三秒钟再走出来，算不算缺陷？穿模一帧算不算？数值浮动百分之零点三算不算？这些都需要人的主观判断，而这些判断往往只存在于资深测试工程师的脑子里，从未被写下来过。
第三，随机性与不确定性是设计的一部分。暴击、掉落、匹配、行为树，都带着刻意的随机。测试要做的不是消除随机，而是在随机里找到不合理的确定性。
第四，多端与性能耦合。同一份逻辑在高端机和低端机上表现完全不同，很多问题只在低端机的特定帧率区间里出现，单看代码或单看日志都发现不了。
这四点共同决定了一件事：脚本能覆盖流程，但覆盖不了判断。而判断，恰恰是测试工作里最有价值的部分。
三、AI入场的第一阶段：感知层的胜利
大约从2024年开始，AI在游戏测试里的第一个规模化落地，其实不在决策，而在感知。
传统的模板匹配需要人工切割图片、人工调阈值、人工维护素材库。而基于目标检测的模型，可以一次性识别出按钮、图标、血条、弹窗、红点，并且对不同分辨率、不同皮肤有更好的泛化能力。这一层带来的收益非常实在：素材维护工作量下降了一个数量级，跨机型适配变得容易，新机型接入的周期从两周缩短到两三天。
第二个落地是文字识别与语义提取。游戏里的文本量巨大——任务描述、道具说明、聊天频道、活动公告，传统识别方案在艺术字、描边字、渐变字上表现很差，而新一代的多模态模型对这类非标准排版的容忍度明显更高。当测试能够稳定读出屏幕上的文字，很多断言才第一次变得可能。
第三个落地是异常检测。用无监督方法学习正常画面应该长什么样，一旦出现大面积穿模、界面错位、黑屏、资源加载失败，模型就能报警，而不需要人提前写好断言。这在美术资源频繁替换的项目里尤其有用。
这三个方向有一个共同点：它们都在降低人写规则的成本，而不是替代人的判断。我把这个阶段称为感知层的胜利。它不性感，但它真的省钱。
四、从脚本到智能体：中间缺的是什么
到这里，真正的转折才开始。
大模型让决策第一次变得可行——智能体可以观察屏幕，自己决定下一步点哪里，遇到意外情况自己想办法绕过去。听上去，这正好补上了脚本的短板。
但我在项目里踩的坑是：能跑通演示，和能进流水线，是两回事。
演示里，你给它一个明确的任务：打开背包，使用一瓶红药，确认血量上升。它会做得很好。但流水线需要的是：每天凌晨三点无人值守跑八百条用例，失败了要能复现，要能说清为什么失败，要在十分钟内给出结论。
从这个角度看，从脚本到智能体之间，缺的不是智能，而是四样工程化的东西。
第一是可复现性。大模型有温度参数，同样的输入两次结果可能不同。测试本身就是一门关于确定性的学科，一个自身都不确定的测试工具，凭什么去断言别人？
第二是可解释性。脚本失败时，你可以去读它的代码，看它卡在哪一行。智能体失败时，你面对的是它的一串思考过程，而那串过程未必是它真实的决策依据。这让排障变得极其昂贵——一个失败用例的定位时间，可能从十分钟变成两小时。
第三是成本。一次多模态推理的调用成本，比一次模板匹配高出三到四个数量级。如果每条用例每一步操作都要问一次模型，跑一轮全量回归的账单会让人心惊。
第四是评测基准。我们怎么知道一个新版本的智能体比旧版本更强？如果没有一套稳定的、有标注的测试任务集，所有的升级都是玄学。而构建这样一套基准，本身就是一件比训练模型更枯燥、也更难外包的工作。
我后来常跟团队说一句话：智能体的价值不在它有多聪明，而在它有多可控。
五、一条现实可行的架构
踩了两年坑之后，我倾向于把游戏测试智能体拆成五层，而不是一个大而全的AI测试平台。
感知层负责把屏幕变成结构化信息——界面元素树、可点击区域、文本、数值、状态变化。这一层尽量用确定性模型，少用大模型，能省则省。
记忆层记录当前任务上下文、历史操作序列、已知的游戏状态。这一层是智能体不失忆的关键。我见过太多演示里的智能体点着点着就忘了自己要干什么，甚至开始重复同一个无效操作。
规划层把测试用例的自然语言描述拆成可执行的步骤，并在遇到异常时重新规划。这一层是对大模型依赖最重的地方，也是最应该做缓存和限制的地方。
执行层真正去点击、滑动、输入。这一层要非常保守，优先用引擎钩子或注入式接口，只有在无法触达时才退化到图像坐标。
断言层判断结果对不对。这一层我强烈建议混合式——结构化的、有明确预期的断言继续用代码写，只有那些说不清楚但一眼能看出不对的部分，才交给模型。
这个分层的核心思想是：把不确定性关进最小的笼子里。大模型只负责它真正擅长的那一小块——理解模糊意图、处理意外情况；剩下的交给确定性代码。这样做还有一个隐性好处：当模型能力升级时，你只需要替换笼子里的那一部分，而不是推倒重来。
六、落地路径：不要一步到位
如果你现在手上有一个项目，想开始做这件事，我的建议是分四步走，而且一定要按顺序。
第一步，先清理脚本资产。把现有自动化用例做一次体检：哪些是高频回归的、哪些是常年失败的、哪些是没人看的。我见过太多团队一边喊着要上AI，一边维护着三千条三个月没人跑过的脚本。先砍到三百条真正重要的，再谈智能化。
第二步，把感知层换掉。用目标检测加多模态替代模板匹配，这一步收益最快、风险最低，通常两三个月就能看到效果。跨机型适配的维护成本会明显下降。
第三步，引入半自主的探索型测试。不做断言，只做探索——让智能体像新手玩家一样乱点，记录崩溃、异常、卡死、资源泄漏。这类测试能发现很多人工想不到的边界情况，而且因为不需要断言，对准确率的要求低得多，非常适合作为智能体的第一个落地场景。
第四步，才是让智能体承接正式用例。而且一定要从低风险、高重复的用例开始——比如每日签到、活动领奖、商店购买这类流程固定、判断明确的场景。
我特别想强调第三步。很多团队一上来就想让智能体跑核心用例，结果被误报淹没，最后项目黄掉。探索型测试是智能体最好的训练场，也是最能说服老板的切入点。因为它不承诺替代谁，只是增加了一种新的发现能力，这种姿态在组织里最容易活下来。
七、成本这件事，必须算清楚
我必须专门用一节来讲成本，因为这是最容易被理想主义掩盖的部分。
一笔账应该这样算：智能体每跑一次用例，大约需要多少次模型调用？每次调用的开销是多少？按2026年的价格水平，一天跑一千条用例、每条十步操作、每步一次多模态推理，一天的推理成本大致在几百到几千元人民币之间，取决于你用的是哪一档模型。
把这个数字乘以一个月，再对比一下它替代掉的人力，答案就很清楚了：如果智能体只是替代了原本就有人在做的事，那它必须便宜到比人便宜一个数量级，才有意义。
所以省钱的关键不在模型本身，而在架构：能缓存的缓存，能用小模型的用小模型，能用规则的用规则，能只在一段流程的关键节点问一次大模型，就绝不在每一步都问。
我见过一个团队把每步推理都换成了一次轻量模型调用加本地规则判定，整体成本降了将近八成，效果几乎没有损失。这就是工程的价值——不是找到最强的模型，而是找到最合适的调用方式。
八、人的位置：从写脚本到教智能体
这几年我最深的感受是，测试工程师的角色正在发生一次静默的迁移。
过去，一个有价值的测试工程师的标志是：他能写一手健壮的脚本，能快速定位问题，能设计出覆盖全面的用例。
现在，这些能力依然重要，但权重变了。新的核心能力变成了三样。
第一，把模糊的判断写清楚。智能体不会自己知道什么算缺陷。你需要把它拆成可判定的规则、可量化的阈值、可标注的样本。这件事的难度，其实比写脚本高得多，因为它要求你把自己潜意识里的直觉外化出来。
第二，设计评测。我们怎么衡量一个智能体好不好？需要有人去构建任务集、标注真值、定义指标。这是全新的工种，而目前市面上真正会做这件事的人非常少。
第三，接受概率。传统的测试思维是二值的——通过或不通过。而智能体带来的是概率——它有百分之九十二的概率判断正确。这意味着测试报告的形式要变，团队的沟通方式也要变。你要学会说：这条用例的置信度不算高，建议人工复核一下。
我认识的一些同行对这件事是抗拒的，觉得这是在把自己的工作教给机器。但我的看法相反：当机器能完成操作这件事之后，真正稀缺的恰恰是定义什么是正确的能力。而这是人类最擅长、也最难被替代的部分。
九、我对未来两年的判断
如果一定要给出预测，我会说三件事。
第一，智能体会先吃掉探索测试，再慢慢吃回归测试。因为探索测试对准确率的要求天然更低，容错空间大，是人机协作的最佳切入点。而回归测试追求的是稳定和可复现，这恰恰是大模型目前最弱的地方。所以未来两年，我们看到的会是一个混合形态：脚本跑主流程，智能体跑边角与探索，两者共用同一套报告体系。
第二，测试平台会重新洗牌。过去几年，测试平台拼的是用例管理、报告展示、设备调度。接下来，拼的会是感知模型的准确率、智能体的任务成功率、以及每次任务的平均成本。这是一个完全不同的技术栈，也是新玩家进场的机会。
第三，也是我最想说的一点：不要为了AI而AI。如果你的项目只有五个页面、每周发一次版，那老老实实写脚本，性价比高得多。智能体真正划算的场景，是那些用例成千上万、版本迭代以天计、且存在大量说不清但看出来就知道不对的场景。它是一把重武器，不是一把万能钥匙。
结语
回到开头那次四百多条误报。后来我们没有换掉那个智能体，而是做了一件很朴素的事：把动画过渡帧过滤掉，把关键操作的等待时间从固定值改成状态驱动，并且给它加了一层连续两次观察到同一异常才上报的确认逻辑。
误报率降到了可以接受的水平。
这件事让我明白，从脚本到智能体，本质上不是一次技术换代，而是一次关于确定性的重新分配。我们把一部分确定性交给代码，一部分交给模型，一部分交给人。哪部分交多少，取决于你的项目、你的成本和你的团队。没有标准答案，只有不断调优。
脚本时代教会我们的是把操作自动化。智能体时代要教我们的，可能是把判断自动化——而在这件事真正做成之前，我们得先学会把自己的判断，讲得足够清楚。
这大概才是这场变革里，最有意思的部分。