游戏开发项目管理：QA需要投入多少人力、时间和金钱？（下）
文：Mathieu Lachance
项目规划是电子游戏开发项目中最重要也是最困难的一步。它将通过努力，时间和金钱去明确游戏的范围和功能。我将在此分享我和我们团队用于衡量QA需要多少人力，时间和金钱时所使用的一些窍门和技巧。
我们所依赖的最基本的外因规则是：
· 10%规则
· 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过程。希望所有的这些内容能够带给你真正的帮助！