游戏项目中的自动化测试和持续集成

现在，许多游戏项目要么跳票严重，要不就是发布时Bug多多。当然，这样的现象并不仅存于游戏工业。例如，根据2001Standish集团发表的那份 声名狼藉的报告“极度混乱”所表述的，70%以上的软件项目要么被取消，要么严重的超时和超支。然而，游戏是软件开发复杂性的最佳代表，不同技能的人需要 协同工作，这也就是某些人所说的游戏项目中高风险因素所在。

　　软件项目延期、Bug满天飞和失败的原因是多种多样的，但看起来除了随产品特性不断变化之外，测试和品质管理是永恒的问题。以我们的经验来看，相当多数的游戏开发工作室完全依靠人工的方式来测试游戏引擎、开发工具和游戏代码，几乎没有采用自动化过程测试。很巧，在2002GDC的圆桌会议：游戏中的纯软件工 程，只有18%的与会者表示他们参与的项目采用了自动化测试。

　　在2000年，我们的客户，当时新成立的中间件公司对我们的3D引擎的稳定性和大量的BUG抱怨频频，我们第一次想到了自动化测试。直到那时，每当完成一 个新特征，我们还是依靠人工测试，并且使用这些特征开发出技术演示供市场部使用。我们在彻底分析了情况后得出以下结论，我们的软件质量问题主要和我们测试 方法有关：

　　*人工测试不够全面和彻底，因为它仅仅花费了很多时间。 代码在修改或添加之后，它本应运行预定义的人工测试集来保证修改不会产生新的问题。人工测试花费的时间越来越多，并给开发者带来挫折感，打击他们执行测试 的积极性。而且，测试的工作量使得开发者不愿意改进或优化现有的代码。

　　*当开发者测试他们自己的代码时，他们总是不愿意（潜意识？）执行最苛刻的测试用例，因此就导致了最有可能出错之处也是最不可能被全面测试到这样的情形。

　　因此，我们决定采用自动化测试，从开发一个新SDK部件开始。结果是鼓舞人心的，最终我们把它推广到所有的SDK部件开发中去。测试框架极限编程，由Kent Beck和Martin Fowler总结的一系列方法和经验，带来了自动化测试的流行。一般来说，自动化测试指无需用户干预，用来验证软件产品中的功能子集的代码和数据。它可以是用来测试某个特定类方法（通常称为单元测试），也可以是用来测试程序功能性的集成测试（功能测试）。

　 　为了促进自动化测试进程，有许多开源代码的单元测试框架，比如CPPunit（C++专用）或Nunit（.Net专用）。这些测试框架提供了GUI来 运行测试集并提供测试结果反馈。根据你的项目，也许需要根据你的游戏进行一些额外的功能扩展和自定义，例如支持跨平台。这些测试框架的内容，一个单元测试 对应一个函数，测试类由多个单元测试组成，并且包含一个开始和结束测试的方法（例如载入和卸载一幅地图）。这些测试类可以放在分离的执行文件中，例如 DLL文件，也可以与主项目在一起。除此之外，测试类应该存放在产品代码之外的文件中，这样的话，他们就可以很方便的从版本发布中移除。

　　物理引擎的简单测试代码，如果任何一个VTEST条件没有满足，那么测试就失败。该测什么？当要决定测试的范围时，实用第一。一般来说，为简单的功能编写单元测试是没有意义的，比如常见的getter和setter方法。为了让自动化测试物有 所值，被测试的代码至少应该是可能会产生错误的，比如，发射一束穿透游戏场景的光线并且返回它穿过的任何几何物体的方法（光线测试），然后将返回的结果与 编写测试用例的作者提供的预期结果作比较。

　　到底是只为类的公用 接口编写测试用例（黑盒测试）还是要兼顾类的私有成员（白盒测试），是一个有争议的问题。通常来说，黑盒测试比白盒测试粗糙，它们只能检查一个操作的最终 结果，不能检查内部中间状态，它们对于被修改的测试代码比较迟钝。刚才提到的光线测试功能可能被全部重写（比如原先的版本运行效率不够），但是它返回的结果没有变化。这时，白盒测试用例就需要跟着重写，然而黑盒测试可以继续用来检测代码修改后，所产生的结果是否与原先一致。

　　因此，我们认为自动化测试中，测试范围只要包括类的公有成员就够了，毕竟，类的内部修改比它接口修改要频繁得多。