许多游戏项目有显著延迟或者是存在许多bug的状态。当然这不只是游戏这一个行业。例如根据The Standish Group （美国的一个机构）在2001年发布的名为“Extreme chaos” 的调查报告：所有的 软件项目中有超过70%的或者被取消或者大大超过他们计划的开发时间和预算，然而，由于游戏是一个非常复杂的软件开发案例，所以它需要熟悉不同学科的人一起合作，有些人可能会认为，游戏开发项目的风险特别高。

　　延迟，bug的存在，甚至项目的失败是多方面的原因，但似乎，除了开发，代码，测试和质量保证是反复出现的主题。以我们的经验，很多开发工作室完全依赖于底层游戏引擎的手工测试，他们的生产工具，游戏代码本身，虽然只有很少采用自动化过程。同样的在2002的GDC圆桌会议中讨论的主题：《游戏的坚实的软件工程》只有18%的人提到他们呢正在使用自动化测试项目。

　　我们第一次面对自动化测试的概念是在2000年，我们的客户当时还很年轻，中间公司抱怨在我们的3D引擎中还存在稳定性问题和bugs。直到那时，我们依然必须依靠手工测试，由开发商进行实施后的新特征，和在我们的内部演示作家的报告他们用这些特征创建用于市场营销目的的技术演示。在深入分析现状，我们的结论是：我们的质量问题与我们测试方法息息相关。

　　手动测试没有进行彻底，因为它需要花费太多时间，每当一些代码更改，或增加新的代码。这就有必要去执行一组定义的手动测试以确保修改了的其他地方没有问题。手动测试花了更多的时间，这导致开发商一边的挫折，减少他们的动机来执行测试，此外，测试在工作中的价值，开发商不愿改善或优化现有的代码。

　　当开发人员手动测试他们自己的代码，他们往往表现出一定的，为了避免最重要的测试用例（潜意识？）趋势，这样的场景的一个问题是最有可能发生的不可能测试的情况。

　　因此，我们决定采用自动化测试，从一个新的组成部分的SDK，我们刚刚开始发展，结果是令人鼓舞的，所以最后我们扩大了我们的实践自动化测试所有SDK的组件。

　　测试框架

　　试验Frameworks Automated测试已成为流行的极端。收集方法和最佳做法由Kent Beck和Martin Fowler推广，一般来说，自动化测试的参考代码或是用来验证的子集的数据的功能的一个软件产品有没有任何用户交互的数据。这可能会对某一个人的方法测试范围类（通常称为单元测试，集成测试）对整个程序的功能（功能测试）。

　　为了便于自动化测试的创作，有一些开源的单元测试框架，如CppUnit（C代码）或NUnit（的.NET代码）。这些测试框架选择试验提供了一个图形用户界面运行并提供关于测试结果的反馈。根据你的项目可能有必要将这些框架，为你的游戏所需要的额外的功能，如对多个目标平台支持。

　　在这样一个测试框架的上下文，一个单元测试对应的一个函数，和多个单元测试集中在测试类，随着初始化和初始化的测试方法（例如，加载和卸载的地图）。这些测试的类可以被放置在单独的可执行文件，例如当被测试的代码驻留在自己的DLL或在主要项目本身。

　　不管这个，测试类都应该被存储在不同的文件，比你的产品代码，所以他们可以方便地被建立用于部署。