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

　 　特别是在游戏开发领域，大多数情况下，把测试结果和用例编写者提供的数据手工作比较是不太现实的。例如，检测与复杂的几何体碰撞的交点，人工提供相关测 试数据几乎不可能。相反，将测试结果与早期代码产生的结果数据相比较，被称为“回归测试”。用例编写者可以评审参考数据，例如，使用简化图形的碰撞物体，如果被证实是正确的，它就可以一直用于测试。这样，自动化测试可以帮助你确认新代码产生的结果与原先的一致。

　 　代码功能测试会生成非常复杂的输出数据，比如游戏的图形渲染引擎，回归测试是唯一可行的自动化测试。以图形渲染引擎为例，所有图形测试以输出最终平台相关的图形文件为结果。一旦自动化测试开始运行，渲染出来的图形文件与样本图形文件逐一像素的进行比较，如果有差异，那么测试失败。为了减少样本图形文件的存占用，你可以使用图形快照来进行测试。

　　图形回归测试的优势在于即使是肉眼难以发现的微小差异也不会被漏掉。除非人们对这个场景非常熟悉，否则很难会有人注意到场景中缺失的一个阴影或一个物体或者某个光源的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年，我们在如何编写健壮的代码上学到了很多，在这段时间内，开发团队的人数变动频频，但是，这些明显的差异足以说明稳定性的提升部分归功于使用了自动化测试。