SunStrike Studios的游戏项目中外部QA团队的工作经验案例
SunStrike公司的专家——安东·塔塔里诺夫和伊利亚·扎哈罗夫与App2Top分享了他们在外部测试方面的经验。
安东·塔塔里诺夫, QA负责人, 伊利亚·扎哈罗夫, QA主管
在这篇文章中，我们分享的案例是完全真实的，就像我们在设立流程时遇到的挑战一样。只是由于保密协议（NDA）的关系，我们不能透露公司的名称和项目。
一切始于一家市场知名公司联系了我们SunStrike，希望借助我们的帮助建立外部QA，并在项目全球上线前进行测试。
审计
在开始工作之前，我们需要进行审查。因此，首先参与项目的是我们的QA主管。他需要完成三项任务。
- 分析项目的当前状况，包括文档、团队及其工作流程，以及使用的工具。
- 根据测试需求和项目特性制定和协商对工作流程的修正。
- 建立外部测试与开发团队的沟通渠道。
不需要花太多时间来分析现有的工作秩序，因为团队已经对某些任务执行中的方面表示不满。我们发现了以下弱点：
- 任务跟踪软件中任务和错误卡片的不良记录，导致混乱，有时甚至导致一些功能和修复的丢失；
- 项目使用工具的文档不够详尽；
- 开发团队与测试团队缺乏合作流程。
在反馈收集和审计之后，我们开始描述和调整工作流程。决定采用瀑布模型的开发方式，这是我们认为最合适的。
在我们的案例中，瀑布模型包括几个步骤。
- 任务创建后进入“计划”栏（实际就是待办事项）。在此阶段，任务应该包含简要说明要实现的内容，并提供设计文档中特定页面的链接。
- 然后，当某位专家（取决于任务分配人）开始处理该任务时，任务会被移至“进行中”列。
- 完成后，任务转至“审查”列，在此部门领导检查任务结果是否与最初描述一致。
- 之后，完成的功能被送去测试，任务相应地转为“测试中”列。
接下来是分岔路。
- 如果测试中发现不一致或错误，则按协商好的流程创建票据。所有团队成员在想要解决错误时应该遵循这个流程。票据进入“计划”栏，并指派给做最初任务的人。任务会被标记一个“旗帜”，队员了解到任务在等待修复。
- 如果测试中未发现任何错误，任务就转为“完成”状态。
我们用于类似项目的看板板
在调整工作流程的过程中，我们发现有关项目技术栈的信息不足。简而言之，没有关于开发团队所用工具的文档。为了提高QA团队对流程的整体把握并减少未来的澄清时间，这是必要的。
常规测试
在工作流程调整达成一致后，该是时候安排实际的测试了。我们从测试规划开始，确立：
- 我们面临哪些任务；
- 何时及如何开展这些任务；
- 在哪个阶段进行哪些活动。
同时需要制定bug优先级的要求，准备bug和功能的报告模板。此外，重要的是，我们要明确哪些部分不进行测试以及原因。
测试计划示例
然后我们开始实际的测试。我们对新功能及此前发现的错误修复进行迭代测试。整个过程涉及四项活动。
- 一小时以内的简短冒烟测试。其目的是在测试开始前尽早发现阻碍性错误。
- 功能测试。每个功能的测试分析和设计方法可能不同。无论采取何种方法，在功能进入编译版本之前，需为其准备文档和参考。有些功能用测试案例描述，有些用核对清单，甚至有时只需一张表即可。
- 回归测试。我们并不是每个迭代都应用回归测试，因为这类测试耗时较多。重要的是，不论多频繁进行回归测试，在每个迭代中都需根据新增功能或更改更新检查清单。否则，待用时可能发现此前准备的检查清单或测试案例不再适用。
- 直觉测试（Ad-hoc测试）。对于每一个新功能，最好用空余时间进行一般游戏体验。不刻意寻找错误，只是单纯进行游戏。常常，直觉测试中，测试员以普通用户的身份体验，可能导致功能或UI的修改。
发布前的重要测试项目
当游戏接近发布时，必须进行另外三种测试：
- 如果准备上线的是在线项目，需进行网络测试；
- 兼容性测试；
- 性能测试。
在任何一个阶段，都可能遇到意外情况。
在我们这一案例中，只进行了兼容性和性能测试。
兼容性测试我们选择通过不同形态的设备进行验证。即在大量流行设备上进行操作测试，这些设备在操作系统版本、UI外壳（若为安卓）、分辨率、纵横比及配置等方面有所不同。
在每个设备上，重要的不仅是启动应用，还要进行冒烟测试，触及游戏里可能包含的所有功能。尤其是第三方SDK和操作系统。
我们SunStrike拥有庞大的设备库，因此这方面没有问题。
用于兼容性和性能测试的设备列表
性能测试情况相似。但这里我们更多关注具体的CPU、GPU和RAM。基于这些参数，我们将设备分为三类：高性能、中等性能和低性能。
RAM / FPS / 网络 / CPU性能测试的游戏会话（注意到FPS波动）
FPS性能测试的游戏会话（注意到波动）