测试陷阱：开发人员在测试游戏时最常犯的错误有哪些？

我们继续发布来自“游戏产业”会议的报告解读。这次是来自GostTeam公司测试部门负责人阿廖娜·卡拉谢娃的发言。她介绍了在测试游戏产品时最常遇到的问题。

在这个报告中，我将分享一些我自身经验的案例。

不过首先我来简单介绍一下自己。我进入IT行业已有25年，那时我还是一名工程系学生。在游戏开发领域已经有20年的经历，其中从事测试工作15年。

在“GostTeam”公司，我从零开始建立了QA部门，并将其人数增加到250人。

我和团队参与了游戏的测试，包括AAA级别的游戏和面向儿童的程序，还有各种非游戏解决方案（如在线收银机、在线视频平台等）。

在这个报告中将讨论:

• 需求的工作;
• 测试策略的工作;
• 测试文档的开发。

我不会深入测试本身的主题，因为它实在太广泛了。

需求的工作

这可能是任何测试团队工作中最困难的阶段，因为在此阶段涉及最多的沟通。

在这一阶段重要的有：

• 确定需要测试哪些元素;
• 指定需要进行的测试类型;
• 不能遗漏任何细节，也不能丢失沟通;
• 在研究需求时，明确并解决不清楚的问题和争议。

往往第一阶段，就会出现问题。

我遇到过这样的情况：客户团队要求我们测试，却没有项目文档。有时他们告诉我，文档其实在一位几个月前离职的专家脑子里。

因此，我们需要自己分析项目，准备相关的文档，然后就每个元素或功能请求客户确认我们的理解是否正确。

有时，文档存在但只是一堆分散在不同专家手中以不同格式和不同完成度的文件。通常这是因为客户没有统一的平台来维护文档。通常的处理方式是：

• 文档的部分章节由一个专家开发;
• 另一部分由另一个专家开发;
• 一旦任何一个专员完成工作，他们就会将文件发送到一个统一的沟通渠道;
• 结果是团队收到多个同名但内容不同的文件。

下一个问题就是路线图。

但首先需明确：路线图是为管理层和总监准备的指导方针或参考标准。

常见的情况是，收到路线图文档，然而实际上——不仅时间表已经改变，开发中的功能完全不同，并且文档的更新没有进行。

在需求工作的这一阶段遇到的另一个问题是：未明确游戏平台。

例如，客户过来跟你说：“给你一个游戏，你需要完成训练，游览地图，收集战利品，击败敌人，查看产生哪些缺陷并在缺陷报告中记录下来。”当开始询问某个功能如何操作时，却发现所有的项目文档都缺席。最终经过与开发专家的讨教，才弄清楚具体元素应该如何运作。这时发现游戏不仅需要功能测试，还需要确定系统要求，测试性能，另外关键是进行回归测试。

为什么需要回归测试？因为产品正处于开发的活跃阶段，新的冲刺正在不断地引入和验证新功能，而没有人去检查更新后旧功能的运作——回归测试被忽视了。

可能的解决方案是什么？

首先需要选择一个统一文档和数据存储平台。

共同对文档工作的协同简化了所有部门的工作：分析部门，营销部门，当然还有QA部门，其工作人员能立即看到功能拥有者及其功能运作的方法。

自然地，极力推动文档规范化。维护文档可帮助找出测试需求上的差异。

在项目文档中常见的情况是，有比如25个章节。章节N1描述功能的工作，而章节N25则引用该功能，但提供了其不同的描述。

测试部门的一项任务就是分析这些情况，识别参数的不一致之处，确认实际情况，并指出功能拥有者的歧义之处。

如此一来，QA部门不仅能发现功能缺陷，还能协助调整路线图的功能启动，更新路线图，从而明确当前工作中的哪个方面更值得关注。根据需要调整任务的资源配置与量。

以上内容带来下一个阶段。

测试策略的开发

这对任何团队来说都是非常重要的阶段，因为它决定了开发所需资源的量。

在游戏发布集中，我们遇到过这样的情况，每月发布一个新功能，但缺乏测试计划及对需测试内容的清晰理解。

曾有客户只留给QA部门两到三周时间进行发布前测试。在测试过程中发现游戏存在大量关键性错误，以至于不得不推迟发布时间。

如何避免此类情况？

必须清晰地知道在此开发周期中需要进行哪些类型的测试以及它们的目的，设定优先级。

例如，有一次被要求在原型阶段进行性能测试。这在经济上是不合算的，因为项目的重要目标是吸引投资者以获得额外开发资金。我们解释了给客户，并建议集中在功能测试上。

当然，还建议制定测试计划，方便确定测试预算。

下一个深刻影响测试计划预算的阶段是测试环境的确定。

我已经提到过，有些客户根本没有考虑到测试应该在哪个平台和设备上进行。

例如，曾有客户找上我们，他们一直在开发一个网页项目。他们以为他们的游戏主要会在桌面设备上加载，因此只想在Windows和Mac几个浏览器中进行测试。

在讨论中发现，客户不知道当前非常大的网页流量是由移动设备驱动的。因此，我们的配置组合增加了一倍，需要在移动设备上进行测试。

在我的实践中，经常有客户希望节省成本。他们建议为测试收集最小可能的配置。意思是让专家立即进行功能测试并评估性能。

这导致了什么？

测试人员在最低配置设备上启动游戏。加载时间长达三分钟。性能如同幻灯片展示。专家捕捉的不是错误，而是不停的冻结现象。结果导致测试时间延长，预算也随之增长。

什么结论：不要在测试环境上省钱。是的，低配设备也需要，但作为单独测试中的测试机，只需在两周一次测试中检核游戏变化对性能的影响。

接下来是测试工具的使用。

在项目开始时，由于制裁选择工具变得非常困难（你不知道工具在半年或一年内能否在该国家工作）。此外，这些工具的成本普遍较高。

谈到成本，我并非无缘无故提起。让我分享我们的一个案例。大约三年前，一支开发团队找上我们，希望在一年内测试某项产品的兼容性和性能。他们为此测试预留了大约100小时。同时，他们想使用某个特定的非常小众的工具，该工具可以对游戏进行特定的测量。许可证费用为5000美元。

后来发生了什么？

公司花费资金购买了100小时的测试以及这款工具。此年末我们提供了报告，但团队并不需要这一报告。

因此，我建议在收集数据并花钱之前，权衡所有的利弊，仔细思考是否真的需要这些数据。

同时，在制裁背景下，我建议关注本土工具以降低风险。

测试阶段

测试阶段本身是多方面的，包括许多个步骤。

我想强调一下质量管理，在游戏产品测试中我们团队遇到的困难。

我们经常遇到的问题是没有设定产品的质量标准。我们不得不自行创建验证矩阵，确定哪些是项目发布的阻碍。

另一个问题是：没有同步进行两个分支的工作——开发分支和稳定分支。理想情况是：功能开发在开发分支中进行。发布后构建意义上的新功能则进入稳定分支。不幸的是，许多开发者没有这样做。

忘记承担决策表的实践也很常见。这是一张列出需要测试的具体对象以及已经测试过的对象的表格。

关于忽视回归测试我们已经讨论过。在活跃开发的过程中，团队通常没有时间去回顾和查看游戏中维护的其他内容部分。他们把更多的关注放在新功能上，这反过来可能会影响其他已经实施的元素。为了防止这种情况发生——必须分配时间和资源进行回归测试。

在专注于功能测试的时候，有些人忘记了游戏首先应当具有吸引力。正是因为这个原因去进行焦点测试。它也应该被包含在计划中。并且确定目标受众，了解功能是否对设计针对的用户感兴趣。

普遍的问题还包括开发人员忽视测试文档的更新工作。很多人认为这无关紧要，声称没有时间，认为不如修复错误。因此，这些文件最初几个月没有更新，然后是几年没有更新。结果是当新的技术人员加入时，发现文档与现实世界没有任何关系，不知道该从哪方面着手。

还应说明的是，需定期审核测试计划，因为任何项目都是动态的。任何新内容出现，新功能出现，它都要求测试计划的变更。

我也经常碰到客户不分析收到的报告。原因不明，可能是害怕延迟发布时间。经常需要提醒他们：大家伙，看看这里，你们有这些问题，需要解决。

在质量管理框架下，接下来一个问题是沟通。

最近一个案例是：测试团队在项目的八小时工作时间中，有五小时用来开会讨论。导致工期延误。

还经常碰到，开发团队在每次会议中集结所有——开发人员、分析师、市场人员和设计师，浪费大量时间讨论细枝末节。

不过，也有相反的情况，完全没有互动。团队拒绝会议并讨论任何事情，这同样对项目不利。管理层不知道产品的进展。测试员不知道游戏元素如何工作。开发者不知道该做什么，该修正什么。

为了避免这些情况：

• 明确每位团队成员的沟通渠道和互动形式;
• 事先确定在哪些会议上讨论哪些问题，并且与谁讨论。

这样一来，减少了沟通时间，任务能更快得到解决。不会再有花费半天时间讨论任务的情况。

如此，也确保了详细的缺陷报告的彻底准备。报告越详细，开发功能的专家就有越少的问题。

我就说到这里。非常感谢大家的关注。