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

　　游戏项目中的自动化测试和持续集成[2]   软件测试

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

　　图形回归测试的优势在于即使是肉眼难以发现的微小差异也不会被漏掉。除非人们对这个场景非常熟悉，否则很难会有人注意到场景中缺失的一个阴影或一个物体或者某个光源的R值与B值被错换了。而回归测试就不会放过任何一个这样的错误。

　　必须注意到，任何情况下，回归测试的样本数据都是自动生成的。样本数据也许是平台相关，特别涉及到渲染输出的时候，因此，它也许要被生成多次，即使是这样，当渲染通道发生变化导致生成的图形文件有所改变，样本数据也要重新生成。为了不打击开发者编写回归测试的积极性，要做到只需点击框架用户界面上一个按钮就可以重新生成新的参考数据。

　　如何把所有的整合在一起

　　包括游戏在内的所有应用，完整的测试集合包括单元测试和回归测试。单元测试适合于测试底层功能性、基础库文件和平台类库。上层的各种功能特征集成测试可以使用回归测试。根据结果，你可以有选择的重构或优化你的逻辑或引擎代码，回归测试一旦失败，你会马上发现出问题的地方，单元测试失败可以让你精确的定位出错之处。

　　知道代码被你编写的自动化测试覆盖得范围是非常有好 处的，你可以使用代码覆盖率调查工具(BullseyeCoverage/AQtime)。代码覆盖率分析会告诉你，你的代码哪些被调用，也可以提示你测 试集合中的疏漏之处。测试覆盖率应该是多少，无法精确定量，尽管它取决于被测试的代码。细小的方法无需测试，调试用的函数也不必测试。并且，几乎所有的项 目都会包括一些“死”代码，也就是不会被调用到的代码，那么，这些代码自然也不用测试。总而言之，现实中，我们见过的使用自动化测试的游戏和中间件项目中 测试覆盖率大致是55%到70%。

　　编写友好的测试代码

　　必须承认，并不是所有的代码都能使用自动化测试。以单元测试为例，严格的面向对象，良好的类和函数模块化封装设计可以大大提高它的测试效率。类的接口越多，为它编写的单元测试就越多。同样，过多的使用C++的友元也会增加编写的难度，甚至无法为该类编写(黑盒)单元测试用例。

　　在写代码的时候，要时刻牢记保持良好的测试性。在开发过程中，就会变成可行但是单调乏味的工作，有时候它需要很好的结构性。要在游戏开发中使用，以下几点必须牢记：

　　*所有的回归测试都取决于明确的行为。比如，使用随计算法的寻径系统可以提供一个初始化随机种子的公共方法使得角色的行动决策更复杂多变。这个方法在随后的测试中可以被用来确保角色始终选取同样的路径。

　　*同样，回归测试中要避免与帧数相关的情况;否则，有真实物理特性的物体或渲染输出也许会和以前的数据不同，特别是当结果来自不同的机器或者不同的编译条件(debug 和release)。在测试时，使用恒定的虚拟帧数就可以避免这样的问题。

　　* 严重依赖于用户输入的软件很难测试，比如游戏内置的编辑系统或者游戏工具。这样的话，把UI 和逻辑代码严格的区分开会有所帮助。在我们的游戏工具里， UI界面里每个用户动作会执行一条或多条简单的脚本指令。每条脚本指令可以很明确的重现用户的原意。这样，测试用例可以简单的执行这些指令并且与样本数据 作比较就可以(比如导出地形文件)。

　　也可以使用GUI捕捉工具来测试UI，但我们发现这并不是个好办法。UI会经常改变，哪怕一个按钮仅仅移动几个像素也会使捕捉软件失效，GUI捕捉工具也许会帮倒忙。

　　关于测试的疑问：我们真的可以节省时间么?

　　多数情况下，一个开发团队想要在开发过程中使用自动化测试，大多数成员都会对它抱以质疑的态度。毕竟，与其花这点时间写测试用例，还不如去写逻辑和引擎 的代码。根据我们在游戏和其他领域的工作中使用自动化测试的经验来看，编写测试代码会额外增加30%工作量。初看，在时间和资金上这也许是很大的开销，然而，你要意识到这样做，省去了人工测试所花费的时间。

原文转自：http://www.ltesting.net