自动测试在游戏开发中有多普遍？[关闭]

游戏开发商是否使用其编写单元测试和集成测试？在拼图开发者中有多普遍？在MMORPG和FPS的开发人员中？

（我没有游戏开发的背景，也没有为使用它而感到困惑-这只是我一个疑问。因此，即使我已经喜欢编写自动化测试，也不必试图说服我编写它们。 ）

通常，游戏的单元测试和集成测试并不常见。这主要是因为游戏的渲染方面通常与其他游戏机制紧密相关，因此很难编写有效的单元测试。

也就是说，单元测试可以在游戏开发中进行，如果为其设置了代码，则可能会带来很多好处。但是，为游戏编写自动化测试通常更为常见，通常是以AI程序的形式，该程序可以以比普通玩家更高的速度有效地玩游戏。在这个有关自动化测试的问题中，有一些开发人员正是这样做的出色故事。这种自动测试可能会更好，因为单元测试可能不会捕获渲染引擎中的错误，但是自动测试更可能暴露出此类问题。

最后，这一切都取决于工作室。有些工作室会进行某种形式的自动化测试，而另一些工作室可能会在整个夏天雇用20个高中生来连续玩几个小时。

以我的经验，这不是很常见。

大多数情况下，不会进行单元测试，因为大多数游戏开发人员都来自这样的时代和文化背景，而这种情况尚未普及，因此，现在很难断定此类方法是必需的。近年来，随着用户能够在发布后修补自己的软件，这一点变得更加真实。

部分原因是游戏开发行业中的主导语言是C ++，这使得单元测试比其他语言更加繁琐。存在单元测试框架，但是它们不像使用更现代语言的类似系统那样易于使用，可以使用反射和类似技巧来加快测试用例的检测。

另外，这是因为游戏通常不适合进行单元测试-大部分逻辑取决于半确定性来源（例如图形硬件，输入时序，帧频），许多输出难以衡量（例如。屏幕上的图形，声音效果），还有一些在整个游戏环境之外几乎毫无意义（例如，复杂的反应式AI，物理模拟）。有例外-许多，如果您努力工作以这种方式编写代码-但总体上来说，游戏中的测试比大多数其他类型的软件要昂贵得多，因此成本/收益比更加可疑。

至于集成测试，我从未听说过在游戏开发中明确使用该术语，但是许多开发人员会在可能的情况下对整个系统进行自动化测试。猜想我可能说三分之一的专业开发人员会这样做，因为设置起来并不总是那么容易，而且由于几乎每个中型到大型开发人员（或其发布者）都拥有质量检查人员的事实而降低了收益将手动执行类似测试的部门。质量检查人员的薪水通常比开发人员低得多，因此将测试留给开发人员而不是为其花费额外的代码时间可能被认为是经济的。（有争议）

就测试而言，我看不出编写游戏与任何其他软件有何不同。应该测试该软件的每个组件，无论是触发定时事件，向游戏中角色发送命令还是按下菜单按钮，均应正确执行。

测试游戏是否有可能完成是另一回事，并且不会受到单元测试或集成测试的影响。

通常，自动化UI测试（即使在常规程序中）也比常规自动化难。因此，即使您可以为游戏编写单元测试，也很难测试实际的游戏。大多数公司都会使用人工测试仪来一次又一次地运行游戏。

例如，这里有一篇文章解释了他们如何在一个小型Game Studio（2个开发者）中做到这一点。根据我的阅读，似乎他们的验证不是很详细（自动启动游戏并记录任何错误/断言）。

但是，有些公司在半自动化方面非常成功（例如Microsoft Test Studios）。也就是说，开发人员或SDET可以构建工具，使测试游戏变得更加容易。在Gamefest上有过讨论，他们讨论了如何测试《 Crackdown》（例如《寓言》）。例如，他们仍然使用测试人员来验证每个对象都应该在该位置，但是他们使用的工具会对该位置进行快照，以便人类所做的所有操作都是在视觉上验证其是否存在而不必玩游戏。

这里有一个很好的演讲，介绍了他们构建/使用了哪些工具来测试游戏。它被称为“测试领导者宝石：在我们游戏日益复杂的面前脱身”

我敢打赌，但是MMO和多人服务器代码经过了更多的测试。

至少，自动回归测试很常见。我已经看到这些是在服务器启动期间作为整体健全性检查实现的，例如，确保在开始接受玩家之前确保正确配置了新的“云”服务器；在这种情况下，运行了大约3-4年的相当不错的回归套件运行了大约4秒钟，而从空白OS映像启动虚拟主机花费了将近10分钟，因此值得花时间。我们在Subversion存储库的“ tinderbox”（持续构建系统）上运行了相同的测试，以检查是否有一些讨厌的，相当常见的错误，这些错误很容易再次出现。特别是，多服务器功能有一个讨厌的习惯，即试图在传递对象时创建对象的副本：对象实例化，缓存，且网络传递代码的覆盖率接近100％；我们一直认为我们会考虑可以测试的所有内容，然后发现一些“有趣”的新案例。

在我从事过的多个MMO中，我们还将开发“存根客户端”以执行初始单元测试，并且通常会提供“操作员”命令来对新功能进行临时单元测试。这使我们能够在客户端准备好利用服务器代码之前执行服务器代码，并进行“不可能”的情况（例如，将玩家传送到墙壁内）以确保错误恢复处理程序能够正常工作。在服务器上在线启用一项新功能有时可能需要比客户端对其支持少几天的时间。相反，有时我们必须为客户端创建“虚拟”服务器方法，如果它们领先于我们，则返回假的但格式正确的数据。

但是，MMO的开发通常会遇到更多这类问题，这可能反映了环境。当我在嵌入式游戏系统上工作时，除了一些可重用的小部件代码（例如文本编辑器）以外，几乎没有听说过“测试”。

自动测试在游戏开发中不那么普遍的另一个原因是，对于大多数游戏来说，有很多Beta测试志愿者将游戏Beta的发布视为游戏的“优势”。自动测试当然是出于质量要求，但也超出了预算限制。因此，由于在游戏中有很多有经验的测试人员准备免费进行测试，所以这也许是自动化测试未普及的另一个原因。

我参加了GDC 2011上有关自动化测试的圆桌讨论。IIRC，房间里大约有60个人。有一次主持人对单元测试的覆盖范围进行了调查。有一个人声称代码覆盖率超过90％。所有人都笑到曾经达到1％的覆盖率的想法。如果该小组可以公平地代表整个行业，那么我会说自动化测试通常不会发生，甚至根本不会发生。

这里的其他答案给出了充分的理由。我只是认为拥有第一手帐户会很有用。