当我们处理游戏开发时，软件测试是否不同？

Question

我读过本论文关于软件开发和游戏开发的区别，作者在软件测试方面提出了一些好的观点，例如，

...game开发人员对使用自动化测试犹豫不决，因为面对游戏设计者不断变化的创造性需求，这些测试已经迅速过时。

所以，这篇文章让我想到，在软件测试中，当我们处理/测试一个游戏时，我们应该考虑哪些不同的或特殊的方面？有没有人有这方面的经验，或者有人听说过其他的事情？

Answer 1

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

就“产品作为一个整体”而言，游戏是一种模拟。它可能比一个简单的商业程序更具生成性的复杂性。想象一下无穷无尽的、独特的、过程生成的世界与具有可数的良好计划行为的企业资源规划师相比。简单地说，在游戏的背景下，可能的独特方式的数量，可以是数学上的，非常大。事实上，它被认为是游戏的卖点。

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

最后，主要目标是娱乐。如果游戏玩家运行60+ FPS，看上去很棒，并且有没完没了的娱乐内容的话，他们就可以接受小故障了。

这就简单地将传统的自动黑匣子测试思想应用于游戏“不那么有形和不值得”的领域。

然而，最近有尝试训练NNs玩小游戏，这是一种有效的形式探索，自我学习的猴子测试。

Answer 2

我做游戏开发已经有很多年了，但是除了这个很好的答案之外，还有一些东西我想补充和详细说明。

首先已经提到的是，对于严格的“FPS-关键”约束和计算/内存预算，输出只是视觉和听觉的。当问题更像是：“看上去不错吗?没有口吃的情况下，它运行顺利吗?听起来很棒吗？”虽然开发人员正在进行调整、调优和近似，而designer/dev协作会使事情看起来和听起来与每一次快速迭代略有不同。

另一个是，测试人员可以是可怕的！我从未在任何其他领域找到过一群如此专注的测试人员，因为他们想测试软件。他们玩得很开心。他们上瘾了，睡在电脑旁边，同时探索你游戏的每一个角落。很容易发现即使是最不明显的小故障，当人们实际上被娱乐的时候，对软件的每个角落进行彻底的测试，而实际上却对它上瘾。在我目前的行业中，测试人员更难与之共事，因为他们中的许多人都是专业人士，他们把生计与软件捆绑在一起，所以他们依靠一些特性来完成他们的工作，而且不一定总是对耗尽每一个角落和缝隙感兴趣。当然，当我们不能很大程度上依赖于人类测试人员时，我们需要更多的自动化测试。

另一种情况是，游戏的代码库通常不会被维护、修改和扩展多年。这并不像超级马里奥的开发人员最初在6502组装中开发的那样，在游戏发布很久之后，他们不得不维护任何类似于原始代码的东西。Doom 3可能使用Doom 1的零行代码(或关闭)。如果有一个持续的专营权，新的游戏更像是“续集”而不是“升级”。大多数游戏只是发布或发布一些补丁，DLCs，然后代码就完成了。这与我的VFX行业形成了巨大的对比，我在那里一直致力于维护代码，这些代码可以追溯到Amiga时代，这些代码已经被移植和维护了几十年。游戏通常没有30年的代码库--更不用说十年前的代码库了--现在还在进行维护和积极的改变。

游戏代码库这种短命的特性的原因之一是它们与硬件紧密相连。当结合它们的尖端特性和FPS关键需求时，它们往往无法以抽象硬件细节的方式进行开发，甚至无法接近。它们通常是专门为目标硬件生成编写的，而PS3通常很快就会被PS4所取代，而后者会变得过时，然后被PS5所取代，诸如此类，一切都会非常迅速。硬件功能在游戏的设计和开发中扮演着如此重要的角色，因此通常不值得尝试维护许多为PSX编写的代码，例如，大多数延续了几代人的游戏授权仍然主要是从最新硬件的底层开发出来的。

有了一个短暂的代码库，就会出现有限的维护时间(即，必须修改代码的有限时间)。随着每次升级引擎的范围越来越大，以及游戏远未接近任务关键这一事实，改变代码所需的时间有限，因此没有绝对的迫切需要应用最详尽的单元和集成测试。如果未来的更改不进行，那么这样做对确保未来更改的完整性没有任何好处，如果一开始没有“遗留”，那么遗留代码库的单元测试和重构方面自然是无关紧要的。

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

也就是说，在最高/最粗级别上进行集成测试往往更有帮助。例如，许多游戏可能会利用一种方法来记录游戏状态是如何随着时间的变化而“重放”的。这种重放功能可以确保游戏是确定性的，并且还可以作为测试工具的一种形式来重放先前由其他人记录的游戏会话。

我还遇到过在小工作室工作的游戏开发者，他们为游戏编写机器人，让机器人以最大的速度玩游戏，运行模拟，最初在一两天后遇到一次模糊的碰撞，然后修复它，然后再运行一次模拟，直到连续运行了几周之后，也不再出现停止显示的事故。所以有一些有趣的实用方法，从游戏开发到测试他们的软件，但通常类似于最粗糙的集成测试和模拟，非常接近玩家与游戏的交互方式。

最后，这些AAA大型游戏引擎开始像一种完全不同的野兽:寿命更长，成功地将硬件抽象得更好，代码库更大，维护时间更长，而它们的级别编辑器开始类似于成熟的开发环境。我认为这些大型引擎可能需要更彻底的测试过程，特别是如果它们的代码维护时间大大增加的话。尽管如此，许多游戏工作室并没有编写巨大的AAA游戏引擎:他们要么授权它们，要么开发一个小型专有引擎，这个引擎的范围要小得多，而且要数年才能得到维护。