自动测试游戏[关闭]

有自动测试游戏的方法吗？

赞赏特定经验，并提供有关项目的相关信息，例如平台和游戏类型（如果有帮助的话）。

一人独立游戏。这是一款具有可破坏地形的多人坦克游戏，可破坏地形和碰撞代码证明有些脆弱。

我最终装配了一些基本的哑人工智能（通过“哑”，我的意思是“绝对愚蠢”-他们会随机选择“向敌方坦克行驶”，“从敌方坦克行驶”和“向随机方向行驶） （同时随机发射主要武器）并在记录按键时以最大帧速率玩游戏。我的实时性大约是10-15倍。该代码已被断言，因此，如果发生任何错误，它将把整个按键日志以及错误报告和初始随机种子转储到磁盘。然后，我可以去重播按键日志以准确复制状态，或者只是从错误报告中调试。

我让它连续运行了几个月。一开始它几乎不会花一个小时而不会崩溃-我不得不坐在那里看护一个星期，每天杀死几个晦涩的虫子。最终，它在两次故障之间连续运行了一个星期，这意味着每次崩溃大约需要1500个玩家小时。

这是无价的，我衷心推荐。

对于我从事过的MMO（100个开发人员，专注于PC），我们尝试添加各种各样的自动化测试，并取得了不同的成功。这是起作用的：

• 在我们的自动构建过程中进行基本测试是一个巨大的胜利。这包括创建角色，传输地图，运行一些可编写脚本的UI测试以及寻找预期行为等任务。在实际到达公司其他部门之前，这捕获了许多错误。
• 在服务器基础结构方面，我们开发了许多不同的自动化测试来模拟典型的MMO服务器事务。然后，我们可以在各种情况下进行回放，以比较性能或确保安全。随着时间的流逝，这些测试变得越来越精确，直到变成回放实时记录的数据
• 我们编写了一个“伪造的玩家”，可以在世界各地随机漫游，跳跃，杀死事物并在聊天中说随机的话。这发现了大量物理和基础设施问题。

什么不起作用：

• 我们试图将一些非常具体的面向战斗的自动化测试添加到自动化构建器中，但这基本上是行不通的。实施后，它可以工作约3天，直到设计师或美术师更改了某些内容，然后测试失败，抛出了构建失败的警报。90％的时间不是一个真正的问题。这些测试太脆弱了，实际上无法维护具有特定功能的特定地图上的特定游戏玩法
• 我们尝试实施一项自动性能测试，该测试将客户性能（平均FPS等）与一周前记录的性能进行比较。这也是相当脆弱的，因为我们用于此的演示往往会经常腐烂，并且很难确定速度下降是由于性能的实际损失或测试过程的某些副作用引起的。

不幸的是，在进行3D战斗的4倍策略游戏时（想想Homeworld与Orion Masters相遇），由于公司资金短缺，因此从未见过曙光。

我始终确保您可以在没有人类玩家的情况下玩游戏，因此我们可以让游戏整夜运行。

我们可以关闭3d战斗（简化为随机结果），然后让AI策略引擎自行运行。这发现了许多错误和问题。不仅显示制止器错误，而且还显示策略错误，在这些错误中，（例如）人工智能策略会陷入僵局，并花费数千转弯来做“正确的事情”。仅在“玩游戏”时很难发现这类错误。

在我从事的第一人称射击游戏中（下降3 – linux / mac / windows，该团队在1999年约有30个人），演示记录/回放功能非常有用。我提供了一个选项，您可以像播放游戏渲染帧一样快地播放演示，这成为在更改了许多事情之后验证性能的好方法。

除渲染系统外，它还行使了很多代码，因此这是一个很好的检查。进行一系列更改后，我可以运行10分钟的演示播放。很多时候，它会在我本不想检查自己的区域捕获错误。

我们有一个开放世界射击游戏（x360，PS3，PC），该射击游戏在构建服务器上使用了快速烟熏测试-它加载了游戏，跨过前端，运行了头像，转储了屏幕截图并退出了。如果cctray检测到干净出口，则构建成功。

我们将其运行到项目的最后一年，团队规模约为100个开发人员。

它可以有效地捕获显示最高水平的错误，但创建通过烟雾测试却无法通过大多数“真实”水平，或者无法在多人游戏中工作或无法使用AI的构建很容易，因此它并不完美。这绝对是值得做的。

自从我离开后，我就听说他们开始运行更大范围的烟雾测试，并被移植到多台PC上。显然，保持冒烟测试是一个问题，并且有一个小团队致力于保持构建服务器和软件的维护，因此我不能说这是否成功。

我在《孤岛危机2》开发过程中对自动测试的经验可以在这里找到：http: //yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html

摘要：

• 自动化测试提高了交付物的稳定性，从而提高了内容创作者和工程师的工作效率
• 自动化测试是提高代码质量并减少必须加班的机会的有效工具
• 总体而言，游戏行业的反应非常强烈，自动化测试遇到了一些不合理的论点
• 不要将其称为测试，而将其称为其他东西，几乎是其他任何东西（查看行为驱动开发）
• 要灵活，编写好的测试很困难，并且需要游戏行业未广泛使用的技能

游戏开发实际上是单元测试对我来说有意义的一种情况，因为离散系统之间的交互是如此普遍。合同设计当然是其中的一部分，应该在开发的第一天就进行计划，但是我不明白为什么如果有足够的资金后就不能实施它。

当然，最困难的部分是集成测试。游戏的许多可以仅仅通过演示环路，或东西进行测试，但这些东西在概念上很容易调试-在那里我会更感兴趣的是花我的时间暴露错误时，会发生球员做一些事情，以玩家从未见过的错误的心态显然不如玩家所犯的错误重要。

显然，这很困难。在其他应用程序上起作用的策略（模糊，预期通过/预期失败等）在这里效果不佳。在可编写脚本的系统中，构建模拟脚本的测试脚本集似乎是必经之路（请参见JZig的答案）。但是，专门针对玩家可能会遇到的事情进行测试，这使我成为集中精力进行人工和自动测试的最佳场所。