Book：Charles P. Schultz, Robert Bryant, Tim Langdell, Game Testing All in One（周学毛等译, 清华大学出版社）, Thomson Learning
为着这学期软件工程课8000+字的Term Paper看的这书。前日去图书馆原是想借些正经软工书的，翻了满架子的书竟是本本写得都像畅销书，还真如众人所说的，真水。想看些架构设计的书，竟也没找着。稍有些质感读起来也不太枯燥的，就只有一些游戏方面的书，有图，还有些我知晓的例子。那便看吧。
为着这学期软件工程课8000+字的Term Paper看的这书。前日去图书馆原是想借些正经软工书的，翻了满架子的书竟是本本写得都像畅销书，还真如众人所说的，真水。想看些架构设计的书，竟也没找着。稍有些质感读起来也不太枯燥的，就只有一些游戏方面的书，有图，还有些我知晓的例子。那便看吧。
测试为什么重要呢？因为游戏会出错，出各种各样的错，并且即使经过了漫长的尽可能全面的测试，游戏依旧会出错。但这恰恰说明在发布前的测试是十分必要的，不管是对于游戏出版商，还是对于开发团队而言。一款出色的游戏会得到褒奖，而一款充满Bug频频跳闸的游戏则会给开发团队带来漫天的骂声，销售额和利润也随之蒸发。
测试为什么对于游戏尤其重要呢？其实测试对于任意一款应用软件都是相当重要的，但是没有一款应用软件像游戏这样拥有庞大、多样、富有压力的客户群。不要指望玩家规规矩矩地按照手册上写的点击菜单，你永远都无法完全预测到每一个玩家所有可能的变态操作——他们可能在物品交易的过程中突发奇想地丢掉正在交易的物品，而导致玩家数据错误。因此，游戏测试是任重而道远的。
- 游戏测试员的任务
作为一名出色的游戏测试员，需要从一名游戏玩家开始，但绝不仅止于此。游戏测试员需要诀窍来发现问题、记录并报告Bug、报告测试进展和帮助开发者发现并确定Bug具体位置。在游戏发布之前，测试员需要反复地做以下这些事情：
1）Play：游戏测试员的“玩”较普通玩家是少有选择性的，测试方案从一开始就规定了测试的目的和步骤，如查探某一游戏中的地图、检查某个特定的原则是否得到执行、或者寻找某一类特殊的问题。有些测试甚至是十分具体的，比如对游戏界面的测试，就依赖于敏锐的观察和对细节的注意，并且往往需要循环重复一些枯燥的按钮和下拉动作，以确定是否存在某些不合理或错误的操作响应。
2）Identify：游戏测试有两个目的，一为找到游戏代码或设计中的缺陷，二为说明游戏中的各个部分能否正常运行。当在测试过程中发现了问题，游戏就相对地“失败”了，这时需要测试员详细地描述发生该问题的过程和结果。
当测试游戏的同一部分时，不是每个测试员都能发现同样的缺陷。心理学上认为这是由人的不同性格造成的，并给出了有效的性格测试工。这个工具可以识别一个人是裁判还是感知者。裁判善于组织和作计划，喜欢井然有序和可预测的测试环境，专注于测试内容的细节，提供详尽的测试报告，适合测试用户手册、脚本；感知者则喜欢采用非常规的游戏玩法，测试多种可能和游戏的真实体验，往往不受计划约束，却能发现一些意想不到的珍贵Bug。这两种人是互补的，因此在一个测试团队中往往需要这两种人。
3）Amplify：这里的“放大”指的是尽可能地使缺陷在第一次被发现时就完全暴露出来，以减少用在这个问题上的时间和成本，这对开发者通常是有益的。为了达到这个目的，通常需要做到两点。首先，尽可能早地执行测试，如当一些新的人物、关卡、功能或子系统第一次被引入时就应当马上进行测试；第二，当在测试过程中发现某个Bug时，应当检查每一个可能触发该Bug的地方，如代码中所有调用包含缺陷的关卡、功能或子系统的地方。
4）Notify：当测试人员发现问题且能描述它影响游戏的方式时，就需要记录此信息并就此向开发人员通报。这一过程通常通过缺陷追踪和管理软件实现，如业界常用的DevTrack。一份完整的通报包括以下几个重要部分：
a. 标题：一个描述性强的标题通常很有用，它帮助开发人员快速地定位此缺陷的大致内容。好的标题通常需要包括一些重要的要素，如事件、人物、方式等。这就和撰写报纸的标题一样，像“杭州地震了”这样的标题是不适用的，它让人产生迷惑。而“5月22日杭州发生里氏8级大地震”这样的标题则合格得多，它恰当地表达了这则新闻的重要性和爆炸性。有时还需要更多的细节，如“造成90人死亡”和“城中30余处房屋倒塌”等。
b. 描述字段：这里包括测试员能及的所有有帮助的细节，人物（战士）、事件（嵌入到内墙的上部）、地点（训练厅）、时间（拜访符咒训练者后）和方式（跳跃）。有时，如果可以，还会描述问题可能的解决方法等。
c. 缺陷的优先级：优先级的名称和含义对项目而言可能各不相同，但概念是相同的，都是根据其重要性对缺陷进行划分，从而决定它是否被优先处理。“紧急”的Bug可能导致玩家信息的丢失、终止或异常中断游戏等重大缺陷；一个“高”优先级的Bug通常是导致某些严重后果的缺陷，如提交了请求但不能得到请求的东西；“中等”缺陷导致明显的问题，但不会危及玩家的奖励或关卡；“低”优先级的Bug则是正对非常微小的缺陷而言，如一些不容易发觉的拼写错误。但应当注意的是，Bug的严重性等级和优先级是有所区别的，比如主菜单中的拼写错误并不会导致什么严重的后果，但却是一个急需改正的Bug。因此，大多数游戏公司会在对Bug订正排序时联合使用严重性和优先级。
d. 缺陷的类型：包括需求修改、文档问题、矛盾报告、进一步增强、微小改进、新特征、第三方错误等，对确定缺陷的路径和处理缺陷而言有重要的意义。通常缺陷管理软件会提供一些可选的分类。
e. 备注：这确保测试员通过添加文件的形式，提供所有有帮助的内容或信息，包括日志文件、包括Bug的录像、操作系统的弹出窗口和错误代码等。
5）Testify：游戏测试员的工作只是发现并通报缺陷，而真正区分缺陷的优先级的权利则掌握在变更控制委员会（CCB）手中。CCB监督和促使最要紧的缺陷得以完成修复，从而在项目期限到时能交付一个最符合要求的游戏。其成员一般包括来自发展部门、测试部门和项目管理部门的代表，他们对Bug进行仔细检查，对其优先级打分，再交付修改。值得一提的是，这里涉及到游戏测试中另一个重要的原则——有选择的（Optional），有时因为项目期限的临近，使得许多团队放弃修复一些有难度的缺陷。
6）Verify：这一步指的是在Bug被修复好之后，有测试人员再次对性测试一次，以确定其是否被完全和有效地改正。
- 游戏缺陷的类型
由IBM公司开发的正交分类（ODC）系统定义了多种软件缺陷的分类方法，其中与游戏较相关的大致有八类。每一种缺陷类型或者是执行结果不正确，或者是缺少代码。
1）功能（Function）：功能错误是一种影响游戏性能及用户体验的错误，可能由提供这一功能的代码丢失或不正确造成，如，在触发某一人物技能后，显示技能停留剩余时间的时间条的缺失。
2）赋值（Assignment）：赋值错误指程序所使用的值被错误地初始化或设置，多数发生在游戏开始、进入一个新关卡或一种游戏模式时，典型地如在策略游戏中，对开始的位置单元和可用资源的初始化。错误的赋值将导致对游戏平衡性的破坏。且有时这种错误是隐藏的，难以有程序员发现的，只有通过测试才能找到。
3）检查（Checking）：当代码在被使用前缺少适当地验证数据时，就可能产生检查类型的缺陷，简单地如边界比较，使用<=代替<。
4）时间控制（Timing）：时间控制缺陷与资源的共享、资源的实时管理相关。良好的时间控制应当在加载某些大型资源时，给出进度条，显示正在进行的操作。通常RPG游戏中在人物启动某项特殊技能的时候会给出一个短小的动画，但往往技能切换完成得会比动画快得多，这时错误或缺失的代码讲导致在动画完成前，技能就被启动，这是违反游戏的世界观原始设定（比如关于念魔咒隐身），这是一个典型的时间控制缺陷。
5）构造/包装/合并（Build/Package/Merge）：这类缺陷是由于配置游戏源代码库系统，变更游戏文件管理，或版本识别和控制引起的错误。良好的版本管理和习惯约定能减少或避免出现这类缺陷。
6）算法（Algorithm）：算法缺陷包括一些计算过程或者选择结构中出现的有关时间复杂度或正确性的问题，主要涉及逻辑控制、AI、数值计算、渲染控制等方面。这类缺陷都大部分涉及到游戏功能，其中一些还是隐藏功能，因此大多会考虑写一个专门针对某一算法缺陷的查找脚本，做连续地测试，而不是一个一个地手动测试。
7）文档（Documentation）：文档缺陷不是由不适宜的代码导致的，而是存在于从文件中重新得到的字节型数据或定义的常量，比如在屏幕上显示的文字、音频或供函数调用的读入参数。这些缺陷只能通过仔细地阅读文本、听音频、检查文件和图形，才能被检测到。
8）接口（Interface）：接口缺陷可能在任何一个信息被转移或交换的地方发生。但通常，它的存在是由于模块之间的调用方式有误，比如被传入的参数与调用例程不匹配，或者在传入时使用前没有做合适的数值范围或类型检测等，都可能导致接口缺陷的产生，而且这些缺陷往往是细小且不容易发现的。
- 测试阶段与过程
虽然游戏的大小不等，开发周期也各不相同，小到只需数周就可完成的手机游戏，大到一些大型的MMORPG或平台游戏，有时需要几年的开发时间，甚至屡屡跳票（如暗黑3）。但不管游戏有多大、生产周期有多长，其测试始终遵循相同的基本结构。
1）试生产阶段：对测试可能的认知是认为测试是在游戏的一个成功部分被开发之后的某一个时间开始的，但事实上，测试始于项目开始之时。许多发生在项目的早阶段的事情，将会为以后测试的好坏定下基调。最好能在项目一开始，就将较多的努力和技术应用于测试活动来修正错误，而不是后来对其做更多的测试，来努力修正它们。
在这一阶段，需要制定合理的测试计划，包括：决定测试的范围、任命测试主管、决定阶段验收标准、参与游戏设计检查、建立缺陷追踪数据库（关键）、起草测试计划草稿和测试设计。除此之外，还要对游戏原型作模块测试，并且根据测试要求招募或雇佣额外的团队成员。这一阶段的测试结果往往是不成熟的，但却对未来的测试工作有着深远的影响。
2）测试的开题阶段：这一阶段分为两个部分，测试员准备和开题会议。测试员准备的步骤和开题的议程都记录在测试开题的清单上，可以看到，测试员需要在开题前通过阅读说明书或文档了解被测试的游戏特征，需要测试所需的设备、文件和程序，最后需要阅读由测试专家书写的测试文案。
开题会议是一个交互式的会议，每个测试的开题都是改善对测试的理解、测试质量和测试执行的机会。通过会议当中的讨论，能提前发现一些在未来的测试过程中可能遇到的问题，并找到补救措施。有统计表明，开题会议实际上节约了测试时间，开题测试的速率是非开题测试速率的1.4倍。
3）α测试阶段：在α阶段的游戏是成型的，游戏的特征已经被测试和校订了，各种素材也被整合过了。这是整个游戏第一次完备的测试，因此，这一阶段的测试是最繁忙的，也因此严格坚持测试套件中的内容是十分关键的，它能让整个测试过程井然有序。在α阶段，游戏的所有模块至少应该被测试一次。业界有公认的详细的α阶段测试入口标准，涉及代码的平台TRC通过率、QA要求、软硬件相容指标和美术要求等，只有符合该标准才能进入α测试阶段；类似的，也有β测试入口标准和最终测试入口标准等，这对整个游戏的测试阶段起到良好的规划作用。
4）β测试阶段：此时，开发团队已经在极大程度上停止创造新代码和新素材，而将关注点转移到如何使游戏更完美，也就是到了识别和修正Bug的时候了。在β测试的早期阶段，会有团队以外的玩家参与测试，但大部分的时间会被花在报告Bug并测试装载上。
这里有一个值得一提的时间点，称为“设计锁定”。当设计锁定状态被宣布后，游戏大方面的测试都已经结束，平衡问题也得到了最好的解决，团队的关注点变为反复地通过实际测试案例来检验版本。在这一状态到来前，项目组需要作出一些重大的决定，如是否要执行最后时刻的特征强化（引入设计师的新构想）、是否砍掉似乎不那么有趣的关卡、哪些Bug将被忽略（难以决定，但时间是有限的）。
5）最终测试阶段：进入这一阶段的游戏出于典型的发布状态，所有的已知一级Bug（崩溃、暂停、主要功能失灵）和大多数的二级、三级Bug被修复。游戏被宣布处于“代码锁定”状态，测试员充当游戏者和项目组的最后防护线。测试团队将最后一次，在时间允许的条件下，尽可能多次执行所有测试套件。任何在最后阶段中发现的严重缺陷都将导致候选版本被拒绝，Bug修正后最终测试必须从头再做一次。此时，整个团队都处于极度的疲倦中，但唯有大踏步地前进才是最好的取得胜利的方法。
6）发布证明阶段：这一阶段的测试通常是由平台制作商（任天堂、索尼）来完成的。其测试游戏的代码是否符合TRC，其功能性和稳定性是否合乎标准。通常，此时还会有一些Bug被发现，然后开发商将会与平台经理的客户就Bug进行讨论，开发团队将被要求修复那些“必须被修复”的Bug。这一过程有时会反复多次，直至候选版本被平台制造商认可，成为“正式版”。
7）公布后测试阶段：游戏发布后，测试依旧不会停止。这也就是我们通常看到的开发商不断公布补丁的时刻，但并不是所有的补丁都用于修复Bug，有时它们是用来为游戏添加新特征的。这一过程会一直持续到游戏的生命周期结束。
No comments:
Post a Comment