在进行游戏开发时，软件测试是否有所不同？

我在阅读本文对一般和游戏开发软件开发之间的差异，作者提出了一些好点的关于软件测试，并指出，例如，该

...游戏开发人员不愿使用自动化测试，因为面对游戏设计师不断变化的创意需求，这些测试迅速过时。

因此，这种阅读使我想到，当我们处理/测试游戏时，在软件测试中还有哪些其他方面应该与众不同或特别？有人对此有经验吗，或有人听到过有关此事的其他信息？

现代游戏实际上是使用内部或专有游戏引擎开发的大量创意艺术内容。引擎本身可以进行大部分部分的单元测试（渲染，几何，物理，AI模块等）。同样，简单的测试也可以附加到已开发内容的各个部分。这意味着单元测试和白盒测试确实是可行和成功的。

就“整体产品”而言，游戏是一种模拟。它可能比简单的业务程序具有更高的生成复杂性。想一想无休止的，独特的，程序化的世界，而不是具有可计划的行为的企业资源计划器。简而言之，在数学上做某事的可能独特方式的数量在数学上可能非常大。实际上，它被认为是游戏的卖点。

此外，最终输出纯粹是视听的事实，并且没有确定此类输出的绝对正确性的标准。GPU芯片实际上不需要执行精确的计算，只需执行大量计算，即使其中的一些计算不精确。

最后，主要目标是娱乐。如果游戏速度超过60 FPS，看起来很棒，并且拥有无穷无尽的娱乐内容，那么游戏玩家就可以小毛病。

当将传统的自动黑匣子测试思想应用于游戏时，它只是处于“不太切实和值得”的区域。

但是，最近进行了训练NN玩游戏的尝试，这实际上是一种探索性的，自学的猴子测试形式。

自从我开发gamedev已有很多年了，但是除了不错的答案之外，还有一些我想补充和详细说明的内容。

首先已经提到的是，输出仅在视觉和听觉上不受严格的“ FPS关键”约束和计算/内存预算限制。当问题更像是“看起来不错吗？运行平稳而没有结结巴巴吗？听起来不错吗？”时，正确性的想法就变得模糊了。当开发人员进行调整，调整和逼近时，设计师/开发人员的协作会使每次快速迭代的外观和听起来略有不同。

另一个是测试人员可以很棒！我从来没有在其他任何领域找到一支更专注的测试人员团队，因为他们想要测试软件。他们很开心。他们沉迷并沉迷于计算机旁，同时探索游戏的每个角落。当人们实际上在完全沉迷于软件的每个角落进行全面测试时，发现甚至最模糊的故障也变得非常容易。在我目前的行业中，测试人员的工作有点困难，因为他们中的许多都是将生计与软件联系在一起的专业人员，因此他们依靠一些功能来完成工作，并且不一定对用尽这些功能感兴趣始终无处不在。自然，当我们不能高度依赖人类测试人员时，我们需要更多的自动化测试。

还有一个问题是，游戏的代码库通常不会维护，修改和扩展多年。并不是超级马里奥的开发者最初是在6502汇编中进行开发的，因此在游戏交付很长时间后就不必维护任何与原始代码类似的东西。毁灭战士3可能使用毁灭战士1的零行代码（或关闭代码）。如果有持续的特许经营权，那么较新的游戏更像是“续集”而不是“升级”。大多数游戏只是发布，可能会发布一些补丁，DLC，然后完成代码。这与我的VFX行业形成了鲜明的对比，在VFX行业，我一直致力于维护可追溯到几十年来移植和维护的Amiga时代的代码。游戏通常不

游戏代码库短暂存在的原因之一是它们与硬件的联系如此紧密。如果将它们的尖端特性和对FPS的关键要求结合在一起，则通常无法以抽象硬件细节甚至封闭的方式来开发它们。它们通常是专门针对目标硬件而编写的，通常不久之后PS3就会被PS4取代，然后PS4就会过时并被PS5取代，依此类推，而且速度非常快。硬件功能在游戏的设计和开发中起着举足轻重的作用，因此通常不值得尝试为PSX编写许多与PS4相同的代码，例如，大多数延续了几代人的游戏特许经营权仍在编写下一代引擎完全是从最新硬件开始的。

短暂的代码库会带来有限的维护时间（即，必须修改代码的时间有限）。由于在有限的时间内更改代码的时间并不长，随着每次升级引擎的范围越来越大，再加上游戏距离关键任务还很遥远，因此没有绝对的方法可以做到。至关重要的是应用最详尽的单元和集成测试。如果不打算进行将来的更改，那么这样做就没有好处，无法确保将来的更改的完整性，并且如果首先没有“旧版”，那么遗留代码库的单元测试和重构方面自然也就没有关系。

另一个并不总是相关的小问题是，游戏可能只针对非常狭窄的硬件范围而没有任何桌面端口。在这些情况下，消除了在这些情况下无法预测的小故障，即用户使用完全不同的硬件和驱动程序运行软件。

就是说，最高/最粗糙级别的集成测试往往会立即变得有用。例如，许多游戏可能利用一种方式来记录游戏状态如何随时间变化以进行“重播”。这样的重播功能可以确保游戏具有确定性，也可以单独用作测试工具的形式来重播其他人先前记录的游戏会话。

我也遇到过在小型工作室工作的游戏开发人员，他们为自己的游戏编写机器人并让机器人以最大速度玩他们的游戏并运行该模拟，最初在一两天后遇到了一个难以理解的崩溃，然后修复它，然后再次运行模拟，并重复进行直到直到连续运行了数周，再也没有出现停止显示的崩溃为止。因此，有一些有趣的实用方法，例如我从游戏开发者那里看到的用于测试其软件的方法，但是这些方法通常类似于最粗糙的集成测试，并且非常类似于模拟玩家与游戏的交互方式。

最终，这些大型AAA游戏引擎开始类似于一种完全不同的野兽：寿命更长，成功地更好地抽象了硬件，具有更大的代码库和更长的维护范围，而其关卡编辑器开始类似于成熟的开发环境。我想那些大型引擎可能会要求更彻底的测试过程，尤其是如果维护其代码的时间大大延长。仍然有许多游戏工作室没有编写大型的AAA游戏引擎：他们要么授权使用它们，要么开发一种小型的专有引擎，这种引擎的范围要小得多，并且无法维护多年。