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

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

　　自动化测 试可以看作在开发前期投入，在开发过程中赢利。大多数的代码修改，包括Bug修改，都可能会引入更多问题导致程序宕机。所以，理论上说，一旦代码有所改变，就必须测试所有可能被影响的代码。自动化测试无需人工干预就可以完成，它们缩短了开发过程。而且由于自动化测试可以简单快速的发现修改的代码是否能有效地运行，因此也就鼓励开发者优化和改进现有的代码。

　　对我们来说，自动化测试帮助开发者编写更稳定和可靠的代码。哪怕是一开始对它抱有怀疑态度的开发成员也欣赏它所提供早期反馈的特性，在开发过程中，它也可以更早的 发现Bug。开发者的工作压力和负荷随着项目的开展日益加大，尽早的发现和解决Bug也可以避免给开发关键时期带来额外的压力。

　　在开发Vision引擎的时候，我们收集了一些数据来研究为提高代码稳定性而实施自动化测试的有效性。2001年早期，全部依靠人工测试的引擎第一个 release版本开发完成，尽管我们已经进行了很全面的测试，但是每个月，我们的在线技术支持数据库依然会收到上百个来自客户的Bug报告。2001年 9月，我们对已有的引擎功能和新增的特征实施自动化测试。这样，即使我们现在的工作量很大，开发进展也很正常，每月Bug报告的数量锐减(现在大概是5到10个)。

　　必须强调，这些图表只是反映了单元测试用例数量和每月Bug数量两者之间的相互关系，不能将它理解为必然的因果关系。当然，从2001年到2004年，我们在如何编写健壮的代码上学到了很多，在这段时间内，开发团队的人数变动频频，但是，这些明显的差异足以说明稳定性的提升部分归功于使用了自动化测试。

　　游戏中自动化测试的局限性

　　尽管使用自动化测试对于游戏开发来说获益匪浅，但是也有其局限之处。显然，很难用它来测试游戏的平衡性，也不太可能用它来测试游戏性和画面的美观性。在这几年里，我们总结了一些编写自动化测试的要点，重点如下：

　　*测试最重要的模块(比如，最复杂和最常用的)。对那些最有可能出问题或者不会破坏原先设计的重构任务进行自动化测试，性价比最高。

　　*当上层功能性测试难以进行的时候，把精力集中在不同的子系统上。例如，你也许不能通过自动化测试来验证AI系统是否正常工作，但你可以测试当一个怪兽的体力低于一定数值的时候，它是否会“投降”。

　　*用压力测试来验证你的代码的强壮性。如果你的游戏在极端条件下运行的很好，比如，每秒有2000个怪兽出生和死亡，一个场景中同时放入500个有真实物理特性的物体，一幅地图轮流载入200次，那么玩家作一些异常操作时，宕机的可能性就会小很多。

　　*在修改Bug前，也为它编写测试用例。这样的话，可以确保这些Bug在今后的版本中不会重现。

　　*回归测试。例如，图像或状态比较的话，使用指定的测试场景要比使用产品地图更容易维护。如果你认为测试用产品数据可能会经常变动，那么你最好使用小的测试场景。否则，不断的生成新的参考数据会使得开发团队产生疲倦和厌烦的情绪。

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