The Game Producer's Handbook（游戏制作人手册）-第11章 ...

文创印刷材料

质量保证（QA，Quality assurance）与玩法测试（Gameplay testing）是在商业发行前把视频游戏变成成品的两个很重要的步骤。事实上，我可以进一步说它们是在任何软件产品发行前必须考虑的两个最重要的步骤。QA和玩法测试能确保产品如设计那样，且提供了足够的功能性、易用性和乐趣去吸引住评论家和终端用户。假如跳过或者匆匆忙忙地完成这些步骤，那产品可能就会在发行后有一大堆Bug影响它的功能性和可玩性。
这些步骤让制作人能确定团队在过去数个月的成果，了解到他们做出来的东西是否如目标一致，且是否能产生对用户有价值的交互体验。匆匆忙忙地度过QA过程是有很多风险的，无论是崩溃的Bug还是游戏和很多软件硬件发生冲突都是一件很可怕的事。
本章会谈一下制作人应该采用的一些常用和有用的测试流程及方法。往往优秀的制作人都有着QA背景，而本章也会解释为什么这类背景对制作人来说是很有用的。往往出色的制作人都在QA上有着一定背景，本章也会解释一下为什么这类背景对制作人是有用的。它还会谈谈如何清晰地勾勒出游戏测试的各项职责，如何对游戏提供有意义且有价值的反馈。
最后，本章还会谈谈不充足的QA和玩法测试流程带来的关键风险。跳过这些步骤无疑是不可能毫无风险的，所以制作人能做到的只是确保有充足有效的流程。
QA团队流程

制作人与QA团队的关系到底是怎么样呢？测试一个游戏的最佳办法是每天玩一下，了解游戏里每一个单独的部分。在开发周期的后段里，维护一个可运行的游戏必须是团队里最高优先级的事情。每日玩游戏能让制作人尽早地与QA团队配合起来，建立起有效的测试流程。
QA流程包括建立起一份测试计划和报告、纠错、跟踪、验证和关闭Bug的方法。在编写这本书的过程中，我发现不同工作室有着不同的方法，但没有一种方法是能应对所有情况的。在这部分里我会谈谈在建立测试计划和管理Bug流程上以前用得比较好的一些方法。
什么是测试计划

编写测试计划通常是QA团队的职责。但制作人能保证这项工作尽早开始，且游戏设计文档的各个更新版本尽可能早（通常是在最终版本前的6～8个月）地提交到QA主管手上，让测试计划尽可能完整。QA测试阶段的目的是测试游戏，看看它是否满足设计里限定的标准。
这份书面测试计划必须描述了在以下每一个阶段和测试过程中要测试哪些内容：

• 游戏玩法功能性。测试计划的这部分需要确保游戏提供的游戏用户体验是如设计文档中描述的那样的。
  
• 单位/角色功能性。这部分要涵盖单位和角色的功能性以及它们在游戏环境中的行为表现。
  
• 故事进展。故事进展测试需要确保游戏如设计那样进展，且游戏里的故事和关卡都是连贯且条理清楚的，里面包含了所有必需的过场和动画。
  
• 用户界面。用户界面测试需要保证用户界面如设计那样有效、直观且与玩法互补。
  
• 音乐音效。音乐音效测试需要确保所有需要的音乐音效事件都如设计那样触发了。
  
• 兼容性。兼容性测试需要确保游戏满足最低配置要求，同时（如果是一个电脑游戏的话）其功能性能适用于最广的硬件组合。
  
• 最终版本/最终校验清单。这是最后的测试流程，用于确保游戏准备好生产或提交给家用机生产厂商验证了。这个最终流程是很关键的，它能保证最后几个月的工作没有被一些粗心的问题和忽漏损害到。
  

在这每一个游戏测试阶段里，你都要保证最终更新的设计文档提交给测试团队了。假如没有这些文档，QA主管建立的测试几乎是几乎不可能既准确反映出策划的意图，同时还平衡好产品的易用性方面的职能的。
职责的分配

测试一个视频游戏的过程可以划分成多个职责领域。在QA流程中的职责划分如下所示：

• QA主管。这个角色主要负责测试计划的建立和QA团队的监管。QA主管职位会直接联系负责Bug修复指派的助理制作人。他还会和QA测试经理（部门经理）紧密协作，确保游戏经过完整的测试。QA主管要负责在测试计划里加入设计文档中涵盖的测试用例和用例情景。
  
• QA主管助理。QA主管助理会在QA主管不在时与QA团队一起协作，它作为QA人员体系中的二把手存在。
  
• QA人员（测试员）。测试员会寻找游戏里的Bug并编写Bug报告。通过根据设计文档中定义的功能来测试程序团队编写的代码，测试员能找出所有设计实现的问题。他们要按指示去玩游戏，按着所有可能的路径去尝试破坏游戏。
  
• 制作人（Bug解决人）。在QA流程上，制作的职责在于倾听、学习，并对项目里的Bug报告提供各种决定。他的职责在于改良，而不在于抵抗。
  
• 助理制作人（Bug指派人）。在与QA团队协作过程中，助理制作人的职责在于与QA主管确立起良好的合作关系，把各种Bug指派到合适的团队成员或者团队主管上。
  
• 兼容性测试员。兼容性测试往往是靠外部公司完成或者由QA主管完成的。制作人和助理制作人也需要关注于QA主管，确保如期准备好版本用于兼容性测试，且该版本里包含了游戏里需要的所有针对硬件的特性。他们还需要安排并提供各种硬件，供程序员去修复兼容性测试过程中找出来的bug。要修复一个“兼容性bug”，程序员往往需要具备出现该bug的硬件来辅助。
  
• 日常游戏测试人员（Playtester）。日常游戏测试人员可以是团队中的任何人，包括策划、程序、美术、制作人，乃至外部聘用的专门玩游戏和提供评估的人。从项目中段开始，尤其是在最后几个阶段，游戏测试是很有价值的，它需要专门的日常游戏测试人员去核对实现出来的成果。
  

对于这些分配的职责，制作人能带来的帮助是理解并尊重他们在项目完成过程中的重要性。制作人应该在不同部门和不同开发团队间促成有效的团队合作。
团队合作

团队合作在游戏开发中的每个阶段里无处不在，尤其是在QA过程中表现得最为关键。大多数的测试人员都喜欢玩游戏，他们对自己在做的事情也很有热情，他们往往会在回家后还玩游戏直到深夜。作为制作人，你应该鼓励他们去分享他们的意见和想法。建立一种容易表达出有建设性的评论和批评的氛围。把你作为制作人所了解到的知识分享给测试人员，因为他们往往都想学习如何能在职业生涯中成长。一个公开公正的环境是测试游戏的最理想的环境。假如你能和QA团队高效地合作，那会有助于你的游戏准时且低于预算发布，并且是一个高质的产品。
以下的建议有助于你建立起健康的团队合作氛围。

• 奖励测试人员。免费的午餐、礼券，或者是公开的表扬都会让他们感觉很好。
  
• 分析竞争产品。测试人员应该意识到自己的产品和市场上的其他产品相比之下是什么样的。你需要鼓励测试人员去了解最新的竞争产品。
  
• 观察与倾听。制作人能从观察别人玩游戏的过程中得到最大的收益。在用户与产品交互时，你能从中看到游戏里哪些地方是有效和无效的。
  
• 摒弃不好的遗留问题。这意味着测试人员应该把他们看到有问题的一切都作为bug提交上来。有些bug会因为技术问题、时间不允许，或者引擎不支持而无法修复。但如果测试人员因为总听到“游戏就是这样设计的”而不去报告问题，那各种遗留问题就会很快堆积起来。
  
• 保持新鲜感。往往测试团队会因为把同一个游戏玩上一遍又一遍而变得烦躁。当他们急着去把工作完成时，各种问题也容易被忽漏下来。你可以通过让测试团队里的人员轮流去测试来保持新鲜感。同时幽默与笑声也能让工作变得更有趣，因此允许团队成员不时“离开位置”，让他们不时可以出去喝点东西。
  
• 尊重人员的意见。制作人很容易会为他做了这么久且花了这么多心思的游戏抵抗各种意见，但切记测试人员的意见是无价的。即使在你不认同他们时也要尊重他们的意见。你会从中学到不少东西的。
  
• 把你的“武器”拿开。制作人常常要“抽出武器”来为团队以及游戏抵抗。但当QA部门给出一些尖锐的反馈意见时，你该去倾听他们所说的内容。他们说的更有可能是一种解决方案，因此你能从他们的建议里得到很多信息。当然，假如建议是“把整个游戏重新做一遍”，那就毫无帮助了，你可以置之不理。但如果反馈是“这个游戏真的很没趣”，那就得进一步看看为什么这么说了。
  
• 混搭硬件。往往团队都会使用相似的硬件。这意味着游戏肯定能在这些机器上跑，但QA团队也能为你提供各种类型的硬件去测试游戏。一些不常见的硬件配置能在产品发行前把各种bug提前暴露出出来。
  

跟踪与关闭Bug
任何想如期完成项目的团队都应该崇尚边制作边修Bug。如果你是在整个开发过程中修Bug的，那整个团队都会相对能确保有一个可玩的游戏，且代码在一个可靠的基础上不断演化。
假如你等到项目结束时才去修bug，那你可能就要花更长的时间才能修复，并且会在项目的关键阶段（最终版本发布和商业发行前）产生更多的bug。Bug在程序员刚写好代码，脑子里一切还新鲜的时候的修正成本是最廉价且最省时的。引用Jamie Fristom在http://Gamasutra.com上说过的一句话：“评估一个功能的实现时间比评估一个bug的修正时间要容易多了”。
在更复杂的情况下，假如你做的游戏没运行几分钟就崩溃了，那团队是无法知道自己实现的新功能是否真正完成的。在实现了新功能后，一旦游戏不断崩溃就很难看到功能运作得对不对，因为几乎不可能知道最近实现的哪些东西让游戏出现崩溃了。通过在游戏开发过程中不断减少bug，实际上能给你更多时间去制作和精调玩法。
以下几种方法能确保QA和玩法测试过程能尽早有效地开始。

• 尽早跟踪bug。展开流程去不断跟踪团队内部的各种bug。你可以通过MS Excel表或者一个成熟的bug跟踪数据库。但要在开发周期中尽早开始这个流程。
  
• 确保一个自动版本管理系统。这能让制作人和团队尽早且轻松地找出各种bug，即使游戏崩溃了，你还能尽快从另一个完整版本上继续测试。你要确保这个过程是自动化的。保证清楚定义好从哪里取到版本，以及以何种形式通知团队。这使得团队里有人签入某些文件后使得游戏崩溃时有迹可循，大家都知道该如何去修正。团队能从源码控制中得到最新的数据，同时在有人破坏了版本后还能自动编译出一个新的版本。
  

跟踪与记录所有反馈
你要确保项目里各种Bug跟踪的解决方案和流程都有着一定的灵活性，让其能包含QA部门任何人的反馈。不断跟踪和记录所有的建议、评论、意见和Bug，这是游戏开发中很重要的一部分，它能确保各种有价值的反馈能记录下来并得到管理。
Alpha阶段

游戏开发过程中对Alpha阶段的定义在不同情况和不同场合下都有不同，因此我在这里的定义只是常见的适合于最近一些项目的定义。通常来说，游戏的Alpha版本是各种功能和资源已完成了，但还有着不少bug存在的状态。下面是对这个定义的详细描述，我经常会把它用在游戏行业的各种合约里：
“‘Alpha版本’是指功能和核心都依照设计和技术设计文档那样100%整合了，不过游戏里还有一些已知的bug。Alpha版本应该包含了100%的特性和功能，包括前端菜单和用户界面、开始和结束动画、游戏过场动画、初步的音效以及初步的音乐。”
Beta阶段

游戏开发周期中的Beta阶段定义是所有资源都整合到游戏，且产品在bug上经过了检验和测试的阶段。我常听到这个定义里还包含“没有引起崩溃的bug”的约定，但要达到这种状态真的很难。崩溃bug在家用机游戏里很少出现，它们在电脑产品中就常见得多了。但即使是在开发家用机游戏时，你都会遇到游戏引起崩溃的情况。
以下是在行业里一些顶级发行商对Beta阶段（包括Close Beta和Open Beta）的技术定义：
“‘Close Beta版本’代表设计和技术文档上定义的产品特性和代码都已经完成了90%了。Close Beta版本应该继续改良和Debug，直到版本里没有任何已知的会引起产品崩溃或死机的A类bug（也就是相当于没有已知的严重的A类bug）。A类bug代表（1）在产品运行过程中出现的没有预料到的事件或行为，导致产品停住或者完全不能运行，且这个bug是可重现的；（2）产品与设计和技术设计文档中的需求出现不一致；（3）对版本里视觉表现、声音或者功能的损害；（4）数据系统、存储设备或者机制上的破坏和崩溃。”
假如出现这种情况，则团队也不可能出现进一步的里程碑许可测试，因为所有人都必须把注意力放在尽快修复这些bug，继续能玩游戏且测试游戏的工作上。一旦发行商提供了兼容性的报告结果后，团队的职责是确保他们能修正尽可能多的兼容性问题。Close Beta一般只会由发行商或开发商的雇员来完成，并且在完成前是不能向公众发布的。接下来就到最终测试阶段了，我们称为Open Beta阶段。
Open Beta
在Open Beta阶段，游戏数据中的一小部分以及完整的游戏引擎会提供给一群核心的人（从Mod社区或者游戏的其他粉丝里挑选而来），他们是消费者市场中的一部分。虽然Open Beta不会对所有人开放，但它能极大地有助于游戏开发团队提前鉴别出产品的各种毛病，而不用在消费者真正开始购买游戏、发现各种Bug，并把产品返还或者不断打电话给技术支持中心时才发现。
但也要警惕一点，当你把一个还没完成的产品放到市场时，它有可能会泄露到公众里面，假如此时游戏玩法是还没成型或者不够有趣的，那是很容易招来连片的骂声的。
以下是对Open Beta的合理定义。
“‘Open Beta版本’意味着产品特性和代码都依据设计和技术文档100%完成了，但可能还有某些内容在测试上未经保证的。产品此时可能已经包含本土化版本了，其数据也用本土化工具生成过了。Open Beta版本还会继续改良和Debug，但它应该已经不含有任何已知的会导致产品崩溃或死机的A类Bug了（也就是相当于没有已知的严重的A类bug）。”
内部QA团队vs外部QA团队

在每个项目里都需要尽早且经常地测试游戏。无论开发团队是否自己去担负起这个挑战，还是他们谋求测试团队里的其他人帮忙，制作人都需要去找到合适的QA支持。开发团队应该不断玩自己的游戏和测试自己的成果，而一个优秀的制作人会确保开发团队尽早具备必需的测试资源支持。以下是可以在开发过程中引入的能对游戏开发带来帮助的测试资源。
开发测试（Development Testing）

开发测试通常指开发团队有了一个可玩版本后的测试过程，该版本只实现了有限的特性，或者只有临时的游戏世界和关卡。参与测试的内容只是游戏中刚实现好的一部分。
开发测试应该和游戏测试区分开来。

备注
尽可能在替代的音效实现出来后就开始测试声音上的实现。团队的音效总监会经常测试音效和音乐，但只要能把作曲家和声音设计师也尽可能加入进去，那这个过程就会快得多。确保声音设计师和作曲家都对QA主管提供了足够的文档了，这样在测试计划里才能加入专门针对声音实现的测试工作。

游戏测试（Play Testing）

游戏测试是在游戏可玩，并且体验中的娱乐性也能构成一个整体来测试时（又或者是游戏中的特定元素充满乐趣）。游戏测试是为了鉴别出游戏体验中的元素是否有趣以及是否正确实现而设的。尽早且经常进行游戏测试能确保游戏在开发早期就保持有趣，当开发继续下去时，随后的各种决策都是基于一个稳固可靠的基础进行的。
我推荐制作人每几周就组织一些人进行“玩家测试”，这些参与测试的人不由负责游戏开发的人组成，而设由游戏主体受众中的代表组成。玩家测试能让团队亲身见证和了解到消费者在第一次玩这个游戏时会做什么。这些人能为你找出各种bug和设计问题，同时也能提供有价值的反馈和建议，让你借以提升游戏体验。玩家测试可以在游戏有了可玩版本后就开始，这个做法可以持续到QA过程中的Beta阶段为止。这样做能保证各种有价值的反馈尽早进入到项目里，不会等到无法再更改时才发现。

荣誉名单（Credits List） 荣誉名单包含了对游戏制作带来或多或少贡献的每个人的名字。不幸的是这些人往往在游戏到达测试的最后阶段，团队面临着各种各样的挑战时离开了。以下的建议能让给予人员荣誉的过程变得更简单和更有效。 - 先建立一张荣誉名单的初稿，只用一个文本文件，没有任何的格式。这会让它看起来非常标准，没有任何人比其他人显得更重要。然后把这张名单传阅，如果可以的话让每个人在上面签名。这能保证每个人都可以查一下自己的名字有没有拼错，上面写的是什么样的荣誉，以及他在名单上的位置。你可以亲身去跟进这个过程。每个团队成员大概只要花上2分钟，但以后能省去将近20个小时的各种让人头痛的问题和冲突。 - 一旦这张名单完成以后，把这个文本文件发给美术人员去负责把它做成影片，假如你打算用屏幕上的滚动文字来显示，那要确保在其他人看到之前自己先测试过。 IDGA在这方面给了一些不错的建议。你可以从IDGA的荣誉标准委员会（Credit Standards Committee）那里得到标准的指南文档。荣誉标准委员会的目标是解决荣誉标准化中的各种问题，确立起所有工作室和发行商都能使用的通用准则。你可以发邮件到credits@igda.org来联系这个委员会。

匆忙完成QA阶段的风险

在任何软件项目里，匆忙完成QA过程的风险是极大的。当你觉得在时间上有压力且想要匆忙完成时，不妨考虑以下的风险。

• 到处可见bug的软件。一个游戏如果到处是bug会一直被玩家记住的。但只有很少人会记住某个产品是如期发布的。
  
• 不兼容。游戏可能会不兼容于某部分的市场。这个兼容性问题的涉及面越广，产品最终的情况也越糟糕。
  
• 高昂的技术支持成本。Bug会耗费钱，这是再简单明白不过的。所有的技术支持电话在每一次想起时都会直接耗费掉你5美金的成本。
  
• 退回成本和销售上的负面影响。当产品到处都是bug且不能玩时，它就会退回到零售商处，零售商也会把产品退回给发行商。产品的退回率在多于20%后，它在商业上就寸步难行了，耗费的钱比发行一个未完成的游戏更高。
  
• 在最终媒介里包含病毒。别笑。想象一下如果在发布产品时是包含病毒的，那你就必须从货架上回收这些产品并销毁掉了。假如你由于匆匆忙忙赶过QA流程而漏掉了最后检查病毒的一步，那这种事就很有可能发生。
  
• 在最终媒介里包含未保护的源码或者数据。即使是家用机开发商也会没有保护好源码和数据，没有用一个大文件系统或者别的封装就把它们放到最终媒介里了。假如你是匆忙经过QA流程的，这种事也很有可能发生。
  
• 盗版。匆忙度过QA阶段的产品可能在出来后更容易被盗版，因为它们缺乏了足够的拷贝保护手段。
  
• 本土化问题和全球同步发行。假如外文版还没完成，还没整合，还没在它们所属市场上测试过，那即使匆忙赶制产品也是无助于产品更快走入市场的。
  
• 生产制造商拒绝。假如产品没有通过家用机生产制造商（索尼、任天堂、微软）的最终QA流程，那它们往往会拒绝一个产品好几次，不让它进入批量生产。所以你最好确保QA过程不是匆忙赶场的，这样产品才能在第一次提交时通过家用机制造厂商的QA流程。
  

备注
当制造厂商看过产品甚至通过产品以后，通常建议的做法是依旧继续测试。在最终发布前尽可能多做几次测试，这样各种bug和游戏性的问题都能找出来，同时能在产品进入到市场前找出解决方案。建立一份bug的优先级清单，让团队能先修正最高优先级的bug，这样即使版本被制造厂商拒绝，下一次重新提交也会更快和更容易。

总结

在开发和测试软件的过程中，几乎每一个问题都是人为造成的。我们没有理由让它们再次发生。你要让你的组织从过去的问题里找方法。同时对bug清单进行优先级排序，确保能有效地依次解决游戏里各种关键问题。尽力去找出并修正bug，其重要性和尽量不犯错不引起bug是等同的。