问题
您将如何将自动化测试添加到游戏中？
我相信您可以对游戏引擎的许多功能（网络、对象创建、内存管理等）进行单元测试，但是是否可以自动测试实际游戏本身？
我不是在谈论游戏元素（比如 Protoss 会在地图 X 中击败 Zerg），而是在谈论游戏和引擎之间的交互。
介绍
在游戏开发中，引擎只是游戏的一个平台。您可以将游戏引擎视为操作系统，将游戏视为操作系统将运行的软件。游戏可以是脚本的集合或游戏引擎中的实际子程序。
可能的答案
我的想法是这样的：
您将需要一个确定性的引擎。这意味着给定一组输入，输出将完全相同。这将包括使用相同输入播种的随机生成器。
然后，创建一个包含化身/用户可以与之交互的几个对象的准系统级别。从小处着手，然后随着更多交互的发展，将对象添加到关卡中。
创建一个遵循路径的脚本（测试寻路）并与不同的对象交互（存储结果或预期行为）。该脚本将是您的自动化测试。一段时间后（比如一周），运行脚本和引擎的单元测试。
Games From Within 上的这篇文章可能是相关的/有趣的。
Riot Games 有一篇关于对多人在线 RTS 游戏英雄联盟 (LoL) 使用自动化测试的文章。
据开发者称，游戏代码和游戏平衡每天都有很多变化。他们构建了一个 Python 测试框架，它基本上是一个更简单的游戏客户端，它将命令发送到运行 LoL 游戏服务器实例的持续集成服务器。然后服务器向测试框架发送命令的效果，允许测试响应。
该框架提供了一个事件队列，用于记录特定时间点的事件、数据和效果。文章称其为“快照”。
这篇文章描述了一个法术单元测试的例子：
设置
1. 赋予角色能力。
2. 在中路（地图上的一个位置）生成一个敌方角色。
3. 在中路生成一个小兵。（在英雄联盟的背景下，小兵是弱的不可控制的角色，是每个团队的军队的一部分。他们基本上是经典饲料，是敌方团队的经验和金币来源。但如果不加以控制，他们可以压倒对方team) 4. 将角色传送到中路。
执行
1. 拍摄所有变量的快照（例如玩家、敌人和普通角色的当前生命）。
2. 施法。
3. 激活对敌方角色的法术效果（例如，有些法术会在击中时触发）。
4. 重置法术的冷却时间，使其可以立即再次施放。
5. 施法。
6. 激活法术对小兵的影响（在英雄联盟中，大多数法术在小兵上使用时都有不同的计算）。7. 拍摄另一个快照。
验证
从第一个快照开始，重播事件，并断言预期结果（从游戏设计师的角度来看）是正确的。可以验证的事件示例包括： 伤害在法术伤害范围内（LoL 使用随机数来为攻击提供变化），与玩家角色和小兵相比，伤害得到了适当的抵抗，并且法术在范围内施放其有效范围。
文章显示，在普通游戏客户端查看测试服务器时，可以提取出测试视频。
另一个答案中已经提到了来自内部的两场游戏的力量的一篇文章，但我建议阅读那里的所有内容（或几乎所有内容），因为它们都写得很好并且直接适用于游戏开发。关于 Assert的文章特别好。您还可以访问他们以前的网站Games From Within，其中有很多关于测试驱动开发的文章，这是将单元测试发挥到极致。
两个人的力量是实现 UnitCpp 的人，这是一个非常受好评的单元测试框架。 就个人而言，我更喜欢 WinUnit。
在开发的游戏性方面，值是如此随机，以至于测试绝对值将是一个牵强的想法
但我们可以测试确定性值。例如，一个单元测试可能让 Guybrush Threepwood 走向一扇门（寻路），打开门（使用命令），因为他的库存中没有钥匙而失败（反馈），选择门钥匙（寻路 + 库存管理），然后终于开门。
所有这些路径都是确定性的。通过这个单元测试，我可以重构内存管理器，如果它以某种方式破坏了库存管理例程，单元测试就会失败。
这只是游戏中单元测试的一种想法。我很想知道其他想法，因此，这篇文章的动机。
我曾经做过与您的想法类似的事情，并且非常成功，尽管我怀疑它实际上更像是系统测试而不是单元测试。正如您所建议的，您的随机数生成器必须以相同的值作为种子，并且每次都必须产生相同的序列。游戏以 50hz 周期运行，因此时间不是问题。我有一个可以记录鼠标点击和位置的系统，并使用它来手动生成一个“脚本”，该脚本可以被重放以产生相同的结果。通过消除时间延迟并关闭图形生成，可以在几秒钟内复制一个小时的游戏玩法。最大的问题是对游戏设计的更改会使脚本无效。
如果您的准系统房间包含独立于一般游戏玩法的逻辑，那么它可以很好地工作。引擎可以在没有任何 ui 的情况下启动，并在初始化完成后立即启动脚本。一路上的崩溃测试会很简单，但更复杂的测试（例如将字符留在正确位置）会更复杂。如果脚本的记录足够简单，它们在我的系统中，那么它们可以很容易地更新，并且可以非常快速地设置用于测试特殊行为的特殊脚本。我的系统还有一个额外的优势，那就是它可以在游戏测试期间使用，并且记录的事件的确切顺序可以更容易地修复错误。
如果您正在测试渲染引擎，我想您可以渲染特定的测试场景，进行屏幕截图并将它们与参考测试渲染进行比较。通过这种方式，您可以直观地检测引擎的变化是否会破坏任何东西。您可以为声音引擎甚至动画（通过比较一系列帧）编写类似的测试。
如果您想测试游戏逻辑或场景进度，您可以通过测试脚本变量的各种条件来实现（假设您使用脚本来实现大部分场景和故事方面）。
如果您使用的是 XNA（这个想法当然可以外推到其他框架），您可以使用游戏内单元测试框架，让您在单元测试中访问游戏的状态。一个这样的框架是Scurvy.Test :-)
http://flea.sourceforge.net/gameTestServer.pdf
这是关于在游戏中实现成熟的功能测试器的有趣讨论。
术语“单元测试”意味着正在测试“单元”。这是一回事。如果您正在执行更高级别的测试（例如同时进行多个系统），通常这称为功能测试。可以对游戏的大部分内容进行单元测试，但是您不能真正为了好玩而进行测试。
只要您的测试可以是模糊的，确定性就不是必需的。例如，“角色是否受伤”而不是“角色是否损失了 14.7 点生命值。
我已经写了一篇关于该主题的论文 - http://download.springer.com/static/pdf/722/art%253A10.7603%252Fs40601-013-0010-4.pdf?auth66=1407852969_87bc2e71ad5228b36738f0237084ebe5&ext=.pdf
这并没有真正回答你的问题，但我正在听微软的 Pex播客，它与你提出的解决方案做了类似的事情，当我听它时，我记得我想看看是否真的很有趣它将能够测试游戏。我不知道它是否能具体帮助您，但也许您可以看看他们使用的一些想法并将其应用于您的单元测试。