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

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