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

游戏项目中的自动化测试和持续集成 现在，许多游戏项目要么跳票严重，要不就是发布时Bug多多。当然，这样的现象并不 仅存于游戏工业。例如，根据2001Standish集团发表的那份 声名狼藉的报告“极度混乱” 所表述的，70%以上的软件项目要么被取消，要么严重的超时和超支。然而，游戏是软件开 发复杂性的最佳代表，不同技能的人需要 协同工作，这也就是某些人所说的游戏项目中高 风险因素所在。 软件项目延期、Bug满天飞和失败的原因是多种多样的，但看起来除了随产品特性不断 变化之外，测试和品质管理是永恒的问题。以我们的经验来看，相当多数的游戏开发工作室 完全依靠人工的方式来测试游戏引擎、开发工具和游戏代码，几乎没有采用自动化过程测试。 很巧，在2002GDC的圆桌会议：游戏中的纯软件工 程，只有18%的与会者表示他们参与的项 目采用了自动化测试。 在2000年，我们的客户，当时新成立的中间件公司对我们的3D引擎的稳定性和大量的BUG 抱怨频频，我们第一次想到了自动化测试。直到那时，每当完成一 个新特征，我们还是依 靠人工测试，并且使用这些特征开发出技术演示供市场部使用。我们在彻底分析了情况后得 出以下结论，我们的软件质量问题主要和我们测试 方法有关： *人工测试不够全面和彻底，因为它仅仅花费了很多时间。 代码在修改或添加之后，它 本应运行预定义的人工测试集来保证修改不会产生新的问题。人工测试花费的时间越来越 多，并给开发者带来挫折感，打击他们执行测试 的积极性。而且，测试的工作量使得开发 者不愿意改进或优化现有的代码。 *当开发者测试他们自己的代码时，他们总是不愿意（潜意识？）执行最苛刻的测试用 例，因此就导致了最有可能出错之处也是最不可能被全面测试到这样的情形。 因此，我们决定采用自动化测试，从开发一个新SDK部件开始。结果是鼓舞人心的，最 终我们把它推广到所有的SDK部件开发中去。测试框架极限编程，由Kent Beck和Martin Fowler总结的一系列方法和经验，带来了自动化测试的流行。一般来说，自动化测试指无需 用户干预，用来验证软件产品中的功能子集的代码和数据。它可以是用来测试某个特定类方 法（通常称为单元测试），也可以是用来测试程序功能性的集成测试（功能测试）。 为了促进自动化测试进程，有许多开源代码的单元测试框架，比如CPPunit（C++专用） 或Nunit（。net专用）。这些测试框架提供了GUI来 运行测试集并提供测试结果反馈。根据 你的项目，也许需要根据你的游戏进行一些额外的功能扩展和自定义，例如支持跨平台。这 些测试框架的内容，一个单元测试 对应一个函数，测试类由多个单元测试组成，并且包含 一个开始和结束测试的方法（例如载入和卸载一幅地图）。这些测试类可以放在分离的执行 文件中，例如 DLL文件，也可以与主项目在一起。除此之外，测试类应该存放在产品代码之 外的文件中，这样的话，他们就可以很方便的从版本发布中移除。 物理引擎的简单测试代码，如果任何一个VTEST条件没有满足，那么测试就失败。该测 什么？当要决定测试的范围时，实用第一。一般来说，为简单的功能编写单元测试是没有意 义的，比如常见的getter和setter方法。为了让自动化测试物有 所值，被测试的代码至少 应该是可能会产生错误的，比如，发射一束穿透游戏场景的光线并且返回它穿过的任何几何 物体的方法（光线测试），然后将返回的结果与 编写测试用例的作者提供的预期结果作比较。 到底是只为类的公用 接口编写测试用例（黑盒测试）还是要兼顾类的私有成员（白盒 测试），是一个有争议的问题。通常来说，黑盒测试比白盒测试粗糙，它们只能检查一个操 作的最终 结果，不能检查内部中间状态，它们对于被修改的测试代码比较迟钝。刚才提到 的光线测试功能可能被全部重写（比如原先的版本运行效率不够），但是它返回的结果没有 变化。这时，白盒测试用例就需要跟着重写，然而黑盒测试可以继续用来检测代码修改后， 所产生的结果是否与原先一致。 因此，我们认为自动化测试中，测试范围只要包括类的公有成员就够了，毕竟，类的内 部修改比它接口修改要频繁得多。 回归测试 特别是在游戏开发领域，大多数情况下，把测试结果和用例编写者提供的数据手工作比 较是不太现实的。例如，检测与复杂的几何体碰撞的交点，人工提供相关测 试数据几乎不 可能。相反，将测试结果与早期代码产生的结果数据相比较，被称为“回归测试”。用例编 写者可以评审参考数据，例如，使用简化图形的碰撞物体，如果被证实是正确的，它就可以 一直