包括游戏在内的所有应用，完整的测试集合包括单元测试和回归测试。单元测试适合于测试底层功能性、基础库文件和平台类库。上层的各种功能特征集成测试可以使用回归测试。根据结果，你可以有选择的重构或优化你的逻辑或引擎代码，回归测试一旦失败，你会马上发现出问题的地方，单元测试失败可以让你精确的定位出错之处。
知道代码被你编写的自动化测试覆盖得范围是非常有好 处的，你可以使用代码覆盖率调查工具（BullseyeCoverage/AQtime）。代码覆盖率分析会告诉你，你的代码哪些被调用，也可以提示你测 试集合中的疏漏之处。测试覆盖率应该是多少，无法精确定量，尽管它取决于被测试的代码。细小的方法无需测试，调试用的函数也不必测试。并且，几乎所有的项 目都会包括一些“死”代码，也就是不会被调用到的代码，那么，这些代码自然也不用测试。总而言之，现实中，我们见过的使用自动化测试的游戏和中间件项目中 测试覆盖率大致是55%到70%。
编写友好的测试代码
必须承认，并不是所有的代码都能使用自动化测试。以单元测试为例，严格的面向对象，良好的类和函数模块化封装设计可以大大提高它的测试效率。类的接口越多，为它编写的单元测试就越多。同样，过多的使用C++的友元也会增加编写的难度，甚至无法为该类编写（黑盒）单元测试用例。
在写代码的时候，要时刻牢记保持良好的测试性。在开发过程中，就会变成可行但是单调乏味的工作，有时候它需要很好的结构性。要在游戏开发中使用，以下几点必须牢记：
*所有的回归测试都取决于明确的行为。比如，使用随计算法的寻径系统可以提供一个初始化随机种子的公共方法使得角色的行动决策更复杂多变。这个方法在随后的测试中可以被用来确保角色始终选取同样的路径。
*同样，回归测试中要避免与帧数相关的情况；否则，有真实物理特性的物体或渲染输出也许会和以前的数据不同，特别是当结果来自不同的机器或者不同的编译条件（debug 和release）。在测试时，使用恒定的虚拟帧数就可以避免这样的问题。
* 严重依赖于用户输入的软件很难测试，比如游戏内置的编辑系统或者游戏工具。这样的话，把UI 和逻辑代码严格的区分开会有所帮助。在我们的游戏工具里， UI界面里每个用户动作会执行一条或多条简单的脚本指令。每条脚本指令可以很明确的重现用户的原意。这样，测试用例可以简单的执行这些指令并且与样本数据 作比较就可以（比如导出地形文件）。
也可以使用GUI捕捉工具来测试UI，但我们发现这并不是个好办法。UI会经常改变，哪怕一个按钮仅仅移动几个像素也会使捕捉软件失效，GUI捕捉工具也许会帮倒忙。
关于测试的疑问：我们真的可以节省时间么？
此文章共有6页 上一页 1 2 3 4 5 6 下一页
文章来源：中国项目管理资源网
 软件开发项目管理培训课程方案
|
Leadge.com首页 > 知识库 
