关键字：游戏项目中的自动化测试和持续集成
现在，许多游戏项目要么跳票严重，要不就是发布时Bug多多。当然，这样的现象并不仅存于游戏工业。例如，根据2001Standish集团发表的那份 声名狼藉的报告“极度混乱”所表述的，70%以上的软件项目要么被取消，要么严重的超时和超支。然而，游戏是软件开发复杂性的最佳代表，不同技能的人需要 协同工作，这也就是某些人所说的游戏项目中高风险因素所在。 软件项目延期、Bug满天飞和失败的原因是多种多样的，但看起来除了随产品特性不断变化之外，测试和品质管理是永恒的问题。以我们的经验来看，相当多数的游戏开发工作室完全依靠人工的方式来测试游戏引擎、开发工具和游戏代码，几乎没有采用自动化过程测试。很巧，在2002GDC的圆桌会议：游戏中的纯软件工 程，只有18%的与会者表示他们参与的项目采用了自动化测试。
在2000年，我们的客户，当时新成立的中间件公司对我们的3D引擎的稳定性和大量的BUG抱怨频频，我们第一次想到了自动化测试。直到那时，每当完成一 个新特征，我们还是依靠人工测试，并且使用这些特征开发出技术演示供市场部使用。我们在彻底分析了情况后得出以下结论，我们的软件质量问题主要和我们测试 方法有关：
*人工测试不够全面和彻底，因为它仅仅花费了很多时间。 代码在修改或添加之后，它本应运行预定义的人工测试集来保证修改不会产生新的问题。人工测试花费的时间越来越多，并给开发者带来挫折感，打击他们执行测试 的积极性。而且，测试的工作量使得开发者不愿意改进或优化现有的代码。
*当开发者测试他们自己的代码时，他们总是不愿意（潜意识？）执行最苛刻的测试用例，因此就导致了最有可能出错之处也是最不可能被全面测试到这样的情形。
因此，我们决定采用自动化测试，从开发一个新SDK部件开始。结果是鼓舞人心的，最终我们把它推广到所有的SDK部件开发中去。测试框架极限编程，由Kent Beck和Martin Fowler总结的一系列方法和经验，带来了自动化测试的流行。一般来说，自动化测试指无需用户干预，用来验证软件产品中的功能子集的代码和数据。它可以是用来测试某个特定类方法（通常称为单元测试），也可以是用来测试程序功能性的集成测试（功能测试）。
为了促进自动化测试进程，有许多开源代码的单元测试框架，比如CPPunit（C++专用）或Nunit（.Net专用）。这些测试框架提供了GUI来 运行测试集并提供测试结果反馈。根据你的项目，也许需要根据你的游戏进行一些额外的功能扩展和自定义，例如支持跨平台。这些测试框架的内容，一个单元测试 对应一个函数，测试类由多个单元测试组成，并且包含一个开始和结束测试的方法（例如载入和卸载一幅地图）。这些测试类可以放在分离的执行文件中，例如 DLL文件，也可以与主项目在一起。除此之外，测试类应该存放在产品代码之外的文件中，这样的话，他们就可以很方便的从版本发布中移除。
物理引擎的简单测试代码，如果任何一个VTEST条件没有满足，那么测试就失败。该测什么？当要决定测试的范围时，实用第一。一般来说，为简单的功能编写单元测试是没有意义的，比如常见的getter和setter方法。为了让自动化测试物有 所值，被测试的代码至少应该是可能会产生错误的，比如，发射一束穿透游戏场景的光线并且返回它穿过的任何几何物体的方法（光线测试），然后将返回的结果与 编写测试用例的作者提供的预期结果作比较。
到底是只为类的公用 接口编写测试用例（黑盒测试）还是要兼顾类的私有成员（白盒测试），是一个有争议的问题。通常来说，黑盒测试比白盒测试粗糙，它们只能检查一个操作的最终 结果，不能检查内部中间状态，它们对于被修改的测试代码比较迟钝。刚才提到的光线测试功能可能被全部重写（比如原先的版本运行效率不够），但是它返回的结果没有变化。这时，白盒测试用例就需要跟着重写，然而黑盒测试可以继续用来检测代码修改后，所产生的结果是否与原先一致。
因此，我们认为自动化测试中，测试范围只要包括类的公有成员就够了，毕竟，类的内部修改比它接口修改要频繁得多。
回归测试
特别是在游戏开发领域，大多数情况下，把测试结果和用例编写者提供的数据手工作比较是不太现实的。例如，检测与复杂的几何体碰撞的交点，人工提供相关测 试数据几乎不可能。相反，将测试结果与早期代码产生的结果数据相比较，被称为“回归测试”。用例编写者可以评审参考数据，例如，使用简化图形的碰撞物体，如果被证实是正确的，它就可以一直用于测试。这样，自动化测试可以帮助你确认新代码产生的结果与原先的一致。
代码功能测试会生成非常复杂的输出数据，比如游戏的图形渲染引擎，回归测试是唯一可行的自动化测试。以图形渲染引擎为例，所有图形测试以输出最终平台相关的图形文件为结果。一旦自动化测试开始运行，渲染出来的图形文件与样本图形文件逐一像素的进行比较，如果有差异，那么测试失败。为了减少样本图形文件的存占用，你可以使用图形快照来进行测试。
图形回归测试的优势在于即使是肉眼难以发现的微小差异也不会被漏掉。除非人们对这个场景非常熟悉，否则很难会有人注意到场景中缺失的一个阴影或一个物体或者某个光源的R值与B值被错换了。而回归测试就不会放过任何一个这样的错误。
必须注意到，任何情况下，回归测试的样本数据都是自动生成的。样本数据也许是平台相关，特别涉及到渲染输出的时候，因此，它也许要被生成多次，即使是这样，当渲染通道发生变化导致生成的图形文件有所改变，样本数据也要重新生成。为了不打击开发者编写回归测试的积极性，要做到只需点击框架用户界面上一个按钮就可以重新生成新的参考数据。
如何把所有的整合在一起
包括游戏在内的所有应用，完整的测试集合包括单元测试和回归测试。单元测试适合于测试底层功能性、基础库文件和平台类库。上层的各种功能特征集成测试可以使用回归测试。根据结果，你可以有选择的重构或优化你的逻辑或引擎代码，回归测试一旦失败，你会马上发现出问题的地方，单元测试失败可以让你精确的定位出错之处。
知道代码被你编写的自动化测试覆盖得范围是非常有好 处的，你可以使用代码覆盖率调查工具（BullseyeCoverage/AQtime）。代码覆盖率分析会告诉你，你的代码哪些被调用，也可以提示你测 试集合中的疏漏之处。测试覆盖率应该是多少，无法精确定量，尽管它取决于被测试的代码。细小的方法无需测试，调试用的函数也不必测试。并且，几乎所有的项 目都会包括一些“死”代码，也就是不会被调用到的代码，那么，这些代码自然也不用测试。总而言之，现实中，我们见过的使用自动化测试的游戏和中间件项目中 测试覆盖率大致是55%到70%。
编写友好的测试代码
必须承认，并不是所有的代码都能使用自动化测试。以单元测试为例，严格的面向对象，良好的类和函数模块化封装设计可以大大提高它的测试效率。类的接口越多，为它编写的单元测试就越多。同样，过多的使用C++的友元也会增加编写的难度，甚至无法为该类编写（黑盒）单元测试用例。
在写代码的时候，要时刻牢记保持良好的测试性。在开发过程中，就会变成可行但是单调乏味的工作，有时候它需要很好的结构性。要在游戏开发中使用，以下几点必须牢记：
*所有的回归测试都取决于明确的行为。比如，使用随计算法的寻径系统可以提供一个初始化随机种子的公共方法使得角色的行动决策更复杂多变。这个方法在随后的测试中可以被用来确保角色始终选取同样的路径。
*同样，回归测试中要避免与帧数相关的情况；否则，有真实物理特性的物体或渲染输出也许会和以前的数据不同，特别是当结果来自不同的机器或者不同的编译条件（debug 和release）。在测试时，使用恒定的虚拟帧数就可以避免这样的问题。
* 严重依赖于用户输入的软件很难测试，比如游戏内置的编辑系统或者游戏工具。这样的话，把UI 和逻辑代码严格的区分开会有所帮助。在我们的游戏工具里， UI界面里每个用户动作会执行一条或多条简单的脚本指令。每条脚本指令可以很明确的重现用户的原意。这样，测试用例可以简单的执行这些指令并且与样本数据 作比较就可以（比如导出地形文件）。
也可以使用GUI捕捉工具来测试UI，但我们发现这并不是个好办法。UI会经常改变，哪怕一个按钮仅仅移动几个像素也会使捕捉软件失效，GUI捕捉工具也许会帮倒忙。
关于测试的疑问：我们真的可以节省时间么？
多数情况下，一个开发团队想要在开发过程中使用自动化测试，大多数成员都会对它抱以质疑的态度。毕竟，与其花这点时间写测试用例，还不如去写逻辑和引擎 的代码。根据我们在游戏和其他领域的工作中使用自动化测试的经验来看，编写测试代码会额外增加30%工作量。初看，在时间和资金上这也许是很大的开销，然而，你要意识到这样做，省去了人工测试所花费的时间。
自动化测 试可以看作在开发前期投入，在开发过程中赢利。大多数的代码修改，包括Bug修改，都可能会引入更多问题导致程序宕机。所以，理论上说，一旦代码有所改变，就必须测试所有可能被影响的代码。自动化测试无需人工干预就可以完成，它们缩短了开发过程。而且由于自动化测试可以简单快速的发现修改的代码是否能有效地运行，因此也就鼓励开发者优化和改进现有的代码。
对我们来说，自动化测试帮助开发者编写更稳定和可靠的代码。哪怕是一开始对它抱有怀疑态度的开发成员也欣赏它所提供早期反馈的特性，在开发过程中，它也可以更早的 发现Bug。开发者的工作压力和负荷随着项目的开展日益加大，尽早的发现和解决Bug也可以避免给开发关键时期带来额外的压力。
在开发Vision引擎的时候，我们收集了一些数据来研究为提高代码稳定性而实施自动化测试的有效性。2001年早期，全部依靠人工测试的引擎第一个 release版本开发完成，尽管我们已经进行了很全面的测试，但是每个月，我们的在线技术支持数据库依然会收到上百个来自客户的Bug报告。2001年 9月，我们对已有的引擎功能和新增的特征实施自动化测试。这样，即使我们现在的工作量很大，开发进展也很正常，每月Bug报告的数量锐减（现在大概是5到10个）。
必须强调，这些图表只是反映了单元测试用例数量和每月Bug数量两者之间的相互关系，不能将它理解为必然的因果关系。当然，从2001年到2004年，我们在如何编写健壮的代码上学到了很多，在这段时间内，开发团队的人数变动频频，但是，这些明显的差异足以说明稳定性的提升部分归功于使用了自动化测试。
游戏中自动化测试的局限性
尽管使用自动化测试对于游戏开发来说获益匪浅，但是也有其局限之处。显然，很难用它来测试游戏的平衡性，也不太可能用它来测试游戏性和画面的美观性。在这几年里，我们总结了一些编写自动化测试的要点，重点如下：
*测试最重要的模块（比如，最复杂和最常用的）。对那些最有可能出问题或者不会破坏原先设计的重构任务进行自动化测试，性价比最高。
*当上层功能性测试难以进行的时候，把精力集中在不同的子系统上。例如，你也许不能通过自动化测试来验证AI系统是否正常工作，但你可以测试当一个怪兽的体力低于一定数值的时候，它是否会“投降”。
*用压力测试来验证你的代码的强壮性。如果你的游戏在极端条件下运行的很好，比如，每秒有2000个怪兽出生和死亡，一个场景中同时放入500个有真实物理特性的物体，一幅地图轮流载入200次，那么玩家作一些异常操作时，宕机的可能性就会小很多。
*在修改Bug前，也为它编写测试用例。这样的话，可以确保这些Bug在今后的版本中不会重现。
*回归测试。例如，图像或状态比较的话，使用指定的测试场景要比使用产品地图更容易维护。如果你认为测试用产品数据可能会经常变动，那么你最好使用小的测试场景。否则，不断的生成新的参考数据会使得开发团队产生疲倦和厌烦的情绪。
* 测试用例越简单越好，不要奢望有非常大的覆盖面。搭建一个易维护和可扩展的自动化测试是一个长期的任务。一般来说，“底层”代码，例如算术、碰撞检测和渲染，更容易进行自动化测试，对于游戏性和完整的游戏测试来说，还是需要经过QA人员亲自测试。当然，QA部门的注意力也要从技术转移到与游戏性相关的问题上去。“到A房间后，因为通风口前面的箱子太高了，所以出不去”这样的报告就会取代“当我的角色转动的时候，屏幕上出现了很多扭曲的三角面”。
持续集成
在一个复杂的软件项目中引入自动化测试，你会发觉运行它也需要一定的时间，我们看到的一些项目甚至需要几个小时。如果让开发者在他们的开发用机上运行的话，测试会完全占用他们的机器，影响工作，那么结果就是他们不去运行测试用例，很显然，没有被运行的用例是没有任何价值的。
解决方法就是搭建一台或多台专用的自动化测试机。它同时还运行版本管理软件（Subversion/CVS/Perforce），一旦发现提交了新代 码，那么代码就会被Check out并编译，测试用例也会自动运行。最后，系统会将测试结果报告以email的形式自动发送给最近提交代码的开发者。
完全自动化、重复的 build和测试过程，这种过程每天运行多次，在极限编程中，我们把它称为：持续集成。为了更好的实行持续集成，像 Cruise Control或者Anthill这样的开源代码工具可以将版本管理软件和自动build工具，例如ANT，整合起来。使用这样的工具， 可以很轻松的搭建适合自己的持续集成系统。
我们发现搭建专用持续集成服务器使得开发过程变得更顺畅，开发者可以更专注于自己的工作。与此同时，测试可以被很好的运行，一旦提交了错误的代码，持续集成系统会自动通知开发者和项目经理，因此开发者也可不必为此分心
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
