游戏开发项目管理：QA需要投入多少人力、时间和金钱？

项目规划是电子游戏开发项目中最重要也是最困难的一步。它将通过努力，时间和金钱去明确游戏的范围和功能。我将在此分享我和我们团队用于衡量QA需要多少人力，时间和金钱时所使用的一些窍门和技巧。 　　我们所依赖的最基本的外因规则是： 　　10%规则 　　QA/调试开发规则 　　我们所使用的主要内因技巧是“谜题技巧”，即包含： 　　游戏内容 　　功能重叠 　　“乘数法”（即正面和负面的QA项目/比例影响元素） 10%规则 　　10%规则是基于你分配给QA的预算值。之所以将其称作10%规则是因为大多数中等规模的项目分配给QA测试的钱便占据开发预算的10%。需要记住的是这一计算只是基于开发者和测试者的费用而并未将美术，音乐，市场营销，法务等考虑在内。下图便是基本的费用比例；10%是测试成本，20%是调试开发（注：基本上就是开发者去解决问题/调试，或者解决问题/调试所需要花费的时间，测试者所找出的问题），以及剩下的70%是你的核心开发团队在游戏中创造并执行技术资产的成本。

　　从根本上来看，如果一个项目越大，那么QA成本在总成本中的比例就会越低。原因如下： 　　当QA团队可以同时看到多种资产和功能时，即在较大型的项目中所拥有的条件，他们的生产力便会显著提高。 　　在长期发展的项目中，QA领导者将分配给测试者特定功能，让他们会随着时间的发展而变成专家并获得更多生产力。 　　在更大型的项目中，团队和角色通常都拥有明确的划分，即测试者负责测试而开发者负责开发，通常开发者的费用都是高于测试者。 　　以下便是成本划分指南。你们或许会抱怨你们的QA成本划分不同，但是要记住这只是一份指南，如果你所遇到的情况有所不同，那可能是因为你们的开发团队或者作为独立开发者的你会亲自执行测试工作而不是将其分配给QA团队。再或者是受到我所说的“乘数法”的影响，即它将会影响到QA的努力和成本（我将在另一篇文章进行具体说明）。

　　以下是来自一个开发者的例子。他的游戏花费了57.1万美元，其中QA便占据了将近20%的成本。

　　如果我们只是计算27.8万美元的开发预算（即开发和QA成本），那么测试成本便占22.3%，这便非常接近我们的预期。

　QA/调试开发规则 　　10%规则是基于支出，而QA/调试开发规则则是基于测试时所需要的人员数量。从根本上来看，你分配给项目的测试人员数量不能超过同一个项目中修改/调试漏洞的开发者的数量。除非是在测试开始后，即测试者开始理解你的游戏，并找到所有显著问题，以及当项目即将完结，游戏质量显著提高且测试者所找到的漏洞数量急剧变少时。这两中情况都是测试团队在项目一开始规模很小并在最后壮大的原因。 　　贯穿整个项目，之所以会有这一规则是因为测试者用于寻找一个问题所需要的时间与开发者用于调试同一个问题的时间一样。

　　在上面的例子中，我以同样的3个核心角色和10%QA团队成本为例。之所以是以18%的员工比例而不是之前说的10%是因为开发者的成本通常都是测试者的2倍。 　　你可以看到，测试者和开发者解决/调试问题的努力或容积值是相平衡的。在大多数项目中你总是希望能够创造这种平衡。如果失去了这种平衡，便会出现下面两种情况中的一种： 　　1.如果寻找漏洞的测试者人数超过解决漏洞的开发者人数： 　　1）QA团队将找到所有/大多数可找到的问题。 　　2）调试开发团队将不能在QA过程种解决所有/大多数所汇报的问题，如此便会累积更多问题并远超过调试开发团队的力所能及范围。 　　3）如果漏洞不能快速得到解决，QA团队的效能将逐渐下降，甚至会完全停止下来，如此便会浪费大量的时间和金钱。

　　我在几年前便曾遇到过这样的情况。一个大型发行商想和我们合作一个项目，他们中有2个人创建了一个非常出色的原型，所以该发行商想进一步去支持这一项目。在了解了他们的时间安排为6个月并且游戏大量的功能后，我们认为该项目大约需要5名测试者和2名开发者。但是在QA开始后3周，测试者仍然无事可做，所以我们建议停止QA直至开发团队修改了所有汇报过的问题并补充一些额外内容。我并不想在此细谈这件事，只是想说这个游戏项目最终花了超过2年的时间，远远长于最初计划的6个月！ 　　2.如果解决漏洞的开发者人数超过寻找漏洞的测试者人数： 　　1）QA团队将发挥100%潜能，因为在整个过程中将能够解决大多数找到的问题。 　　2）调试开发团队可能将没有多余可修复的漏洞，所以他们只能回去执行并创造游戏技术资产。

　　显然，如果你的开发团队的角色分配足够灵活，如果你的项目分配了足够多的测试者，那么第二种情况明显比第一种情况好多了。这也说明了当项目中没有漏洞可以进行修复时，你们可以相应地调整开发团队的角色。 　　以下是体积比例图表：

　　所以这便是计算QA需要多少资源的基本规则。 　　下面，我将讨论如何去使用谜题技巧，即针对于如何一步步地准备你的项目规划中的高级QA策略，并计算你的QA过程需要花费多长时间： 　　游戏内容 　　功能重叠 　　“乘数法”（即正面和负面的QA项目/比例影响元素） 　　这是你的游戏内容和功能打主要内部分析，将为你的项目提供一份有效的QA成本计算。 　谜题技巧 　　我将这一方法命名为“谜题技巧”是因为如果要有效应用这一技巧，你就必须将所有游戏功能和内容分解成一些较小的组件然后重新整合它们以呈现出所需内容的主要部分。一旦形成，这一谜题便是你的QA策略。你可以使用该QA策略去执行QA计划并最终使用该QA计划去落实测试案例。

　　就像上面提到的，它将基于特定顺序将游戏内容，功能重叠和“乘数法”含括在内。为了更好地进行说明让我们以过于简化的游戏和项目为例。再一次地，关于例子，初了游戏玩法外你并不需要进行有关复杂性，性能，第一方发行认证等等测试。让我们假设其它团队将负责这些工作。 　　现在让我们进行深入分析！ 步骤1:游戏内容 　　首先列出所有游戏内容/功能以及完成100%的内容需要花费多少时间。需要注意的是我建议刚开始不要深入过多细节。首先你会因此浪费大量时间，其次你应该将更多细节研究留给QA计划和测试案例。 　　在下面的例子中我们拥有这样一款游戏： 　　能够在大约5个小时内完成 　　花2个小时能够看到所有UI功能，包括菜单互动 　　花10个小时能够收集到所有可行道具 　　花24个小时能够获得所有成就 　　等等。 　　让我们使用所拥有的信息创造出以下图表：

　　小贴士：你同时需要注意我在最下面为破坏性测试添加了一行。这并非一个游戏功能。破坏性测试是一种没有脚本/探索型测试，通常是面向特殊的测试者。这类型测试者可以利用自己的直觉和聪明才智掌握如何在你所预料不到的情况下破坏游戏。这些测试者可以看到游戏中的不同功能并轻松地将不同内容组合在一起创造出意料之外的内容。对此我并不打算进行更详细的描述，不过我希望你们始终都能为破坏性测试留出一定的时间。 　步骤2:功能重叠 　　其次，着眼于你的功能列表并看看测试者可以同时，轻松地覆盖哪些内容。在下面的例子中，为了完成“成就”你将需要完成“进程”和“收集”。它们会重复出现在3个部分，所以如果你不这么做你将在同样的内容中浪费时间。关于“音频”，让我们假设所有的其它功能拥有100%的声音和音乐－－我们需要做的只是让测试者将音频作为另一个检查对象。在下面的图表中我们已经将总的58个小时所需时间减少到41个小时。

步骤3:乘数法 　　最后在你的游戏功能中使用正面和负面乘数法。 　　正乘数法是指任何能够提高测试者生产率的内容（注：例如游戏中有效的调试或作弊功能，游戏中没有任何大型阻碍因素，提供给QA团队像GDD或参考文件等有帮助的参考资料）。 　　负乘数法是指任何会降低测试者生产率的内容（例如随机出现或生成的内容，包括程序生成，或游戏中存在大型阻碍因素，QA团队没有明确的信息或指示，多人游戏检查需要多人参与等等）。 　　在下面的例子中让我们假设开发团队提供了一个基于作弊/调试要求的架构，将“成就时间”减少12个小时，但同时也存在一些随机敌人所以将增加3个小时去遭遇游戏中的所有敌人内容。我们还节省了另外9个小时。即比起最初的58个小时，我们最终将时间缩短到了32个小时。

　　尽管作弊/调试功能能够帮助QA进程，但你必须考虑到如果你不希望在候选版本（RC）中包含这些内容的话你便需要一些测试者在测试过程中不能使用它们，特别是在接近RC截止日期时。主要是因为作弊和调试功能可能会隐藏一些重要问题（如掠过一些主要阻碍因素）或创造出一些本不应该出现在非调试架构中的内容。 下个步骤 　　现在你解决了基本的谜题并了解第一个过程需要花费多少时间。就像之前所说的，现在你可以使用这些信息去明确你的基本QA策略，创造你的QA测试计划，并为你的测试者提供QA测试案例。基于游戏，项目或者你们所面对的情况的复杂性，你需要着眼于另外的一些内容。 　　下一个步骤便是在你的游戏项目中使用“项目限制模式”。最广为人知的模式便是三维限制或铁三角，而其最新的更新版本同时也是并不那么知名的模式便是项目管理之星。

　　关于使用这一模式的一些例子： 　　明确你的时间框架和预算，通常是每开发时间和预算。 　　明确你的质量/内容复杂需求，通常是每游戏内容和你的团队的质量期望值（游戏中有多少内容？我们需要什么类型的测试？我们的质量门槛是什么？我们何时会觉得游戏“足够优秀”了？）。 　　确保你能够做到上面两点内容，如果不行的话你应该尽可能在时间范围内做出最明智的决定，即关于QA以及你的其它游戏领域你想要花费多少成本，你想要传递多少内容以及传递怎样的内容。（如果你没有时间或金钱去测试你的游戏，你可能也没有足够的时间或金钱去添加音频，创造音乐，创造美术资产，翻译游戏等等，或者你可能想借此去缩减游戏内容/质量）。 　　明确你需要以及想要进行的QA支持过程（注：例如一致的团队，每个阶段变化的团队或周期性的等等）。 　　基于你的时间框架，预算和质量/内容需求以及项目阶段去明确团队规模。 　　如果是周期性的，明确你需要多少个QA周期以及多久为一轮。 　　如果是可适用的，明确每个项目周期或阶段的覆盖内容。（例如音频和UI在beta测试前不可执行且不能进行检测，在alpha测试前每周检测50%的内容，在beta测试时/RC阶段每周检测400%的内容等等）。 　　更多不同情况都取决于你的项目特性。 　　以下是我在几年前于一款AAA级游戏中创造的一个谜题/QA策略。所有的功能和功能类型在左边，然后是所包含的时间和执行日期，以及每个项目阶段每周的覆盖率，alpha测试前到发行后的执行和DLC的运行等等。从图表中我们可以看到每个阶段每周所需要的测试时间，每天所需要的平均测试者人数，以及该项目所需要的QA时间和费用。

　　就像你所看到的，如果你的游戏和开发规划很复杂，那么这些工作也就会变得复杂起来。但不要担心，我会在之后的文章中进一步讨论这些之后的步骤。我们将进一步着眼于利益共享者的管理以及QA Pareto概念，即能够帮助你更好地决定游戏的质量标准并根据KPI去决定何时结束QA过程。希望所有的这些内容能够带给你真正的帮助！