资深游戏测试总监详解质量管理工作的9个步骤｜游戏葡萄
游戏测试就是整天玩游戏的吧？
游戏测试还要招本科毕业的！！！不是逗我的吧？
游戏测试不就是拿鼠标或手指头随便点点么？
……
本文我们尝试对上述问题作出一点点专业解释，思路脱胎于2015年笔者在公司内部做的一次项目质量管理相关的分享。又将近1年时间过去了，在工作中，又有很多新的感触与心得。拿出来，跟各位读者分享下，抛块砖，引些玉。
无论是业内人员还是业外人员，在很多人眼里，游戏的质量保证基本上可以和功能测试划等号。这种思维是略有偏见的，我们先抛开测试的技术手段（黑盒，灰盒，白盒）不谈，其实在一款游戏的质量保证过程中，所需要做的工作非常多且杂。这里我大概总结了下常见的工作内容（可能不是太全），见下图：
看完这张图，诸位看官是否已经打消了游戏测试就是拿工资玩游戏的看法，呵呵。
一款游戏的质量保证工作基本围绕上图中的具体工作展开，为了保证测试任务的效率与质量，让项目组里的测试人员把上面所有工作全部承担，是不现实且耗费过多成本的。一个比较好的解决方案是：游戏项目组中的测试人员专注于功能及关联紧密的接口、日志等测试工作，与项目关联度相对弱化和可分离的内容放到平台测试组去完成。大致模型如下图：
这样的配置有两个优点：一是优化测试团队内部的资源分配，二是提升了项目自身的测试效率。专业的人做专业的事是整体的指导思路。
上面比较笼统的描述了下一款游戏项目质量保证的大致内容，以及如何优化配置测试团度资源。那么具体到实际的工作中，我们又该怎样去做好质量保证的管理呢？
这里笔者把质量管理工作拆解成了9个过程，我们逐一来谈一下每个部分的内容与重点。当然，无图无真相，诸位客官，图来了～
我们结合上图所，详细谈谈做好每个过程的正确姿势。
需求管理过程在整个质量保证过程中非常重要，但也是经常被很多读者忽略掉的一个过程。很多测试人员习惯拿过任务来就开始测试，甚至连需求文档都不看，从而出现了漏测或误测的现象。
对于需求管理过程，在正式开始测试之前，至少有3点是需要格外关注的。
01）评估需求的合理性。任何人的思维或设计都不可能尽善尽美，所以对策划人员提供的需求文档，我们也要抱有怀疑态度，在阅读需求的过程中，我们需要思考设计是否存在不合理的地方，是否有可以优化的地方。最忌照本宣科，不思考的认为需求是百分百正确的。
02）思考测试难度与测试周期。在阅读和梳理需求文档时，尽量考虑每个功能点的测试难度与测试需要的时间。如果遇到有不能测试或很难测试的地方，尽早的提出来，与开发人员一起沟通测试方案或者提出测试工具的开发需求。评估测试时间则是为了更加准确的预估测试周期内是否能完成任务，如有困难，尽早的提出，以方便整个项目做出进度上的调整或者协调其他资源来帮忙完成。
03）考虑关联度。游戏功能之间的关联度比较高，在需求阶段，需要考虑当前功能与其他功能是否有关联，思考新功能的添加是否对旧有功能产生影响。如果存在关联上的影响，需要在实际测试过程中测试这些关联功能。
在测试计划管理中，核心的关注点是时间，每个环节的时间预估的越准确，则项目进度可控性越高。反之，则会导致各种不可预估的延期情况，具体流程见下图：
在计划管理过程中，核心是时间，重点是计划一定要明确到个人，且需要跟进。任何计划都可能出现延期现象，不要放过，仔细分析延期原因，从而不断改进。
任务分配管理过程相对简单，需要考虑的点不多，我们还是以一张图来阐述，能上图就不BB，见下图：
很多结果导向的看官可能会忽视执行管理过程，结果固然重要，但要想获得一个理想的结果，请不要忽视执行的过程。在执行过程中，尽量关注和监督，了解执行的动态信息，如发现可能导致结果打不到预期的苗头出现，需要及时作出动态调整，如增加人手、调整任务或修改预期目标等。
好的管理未雨绸缪，烂的管理事后诸葛亮。不要当执行结果与预期有差距是去抱怨和牢骚，不如多花精力关注执行过程，动态调整和改进也许效果更好一些。
信息孤岛的出现会给项目带来潜在的风险，我们要尽量避免这种情况。及时主动的沟通反馈有助于团队之间信息通畅，不仅知道自己要做什么，也需要知道别人在做什么，也让别人知道你在做什么。具体内容见下图：
Bug管理最常见，也最容易被大家忽视。在这个过程中，我们需要关注八个方面，见下图：
对很多测试人员来说，测试工作就是发现bug，然后，就没有然后了。其实仅仅发现缺陷所在是远远不够的，笔者始终强调，发现bug仅仅是测试工作的开始。为什么我们不厌其烦的强调bug管理过程的八个部分，难道搞得这么复杂不会影响效率吗？可以明确的回答，不会，反而会提升项目整体效率。我们简单举两个例子来说明一下。
例子一：bug提报标准。很多人提bug就是一句话，这种习惯是非常糟糕的。看似很节省时间，实际上浪费的是其他人的时间。开发人员通过一句话可能根本不明白bug是什么意思或者很难找到复现方式，从而还得跟提报人反复确认，这样是对时间的极大浪费。所以一个好的bug应该有清晰的描述，有清晰的复现步骤，有清晰的期望结果，有相关的截图和日志。通过耗费测试人员的一点时间换来项目整体的效率提升。
例子二：bug的数据分析。数据分析也是经常被忽视的一个方面，通过对bug的数据统计分析，我们可以很清晰的了解到哪个模块容易出问题，哪个开发人员容易出bug，当前版本还有哪些紧急的问题需要修复等等。数据不会说谎也最具有说服力。测试驱动开发喊了很久，怎么去驱动？也许可以从这些点滴的小事开始做起。
版本管理过程在游戏运营阶段尤为重要，尤其是产品量级比较大的时候，做好了，万事皆顺，做不好，后患无穷。通过长期的实践总结，个人认为有3个要点需要关注。
01）版本内容。该进版本的内容必须进全，不该进版本的内容必须不进。这句看似废话的描述，实则是各种血泪史的控诉。版本中无论是少内容还是多内容，都会导致bug的出现。发版本前，多花一些时间，检查和控制好版本内容，则完全可以避免这一类问题的出现，做到防患于未然远比出了问题再修改要好的多。
另一点则是，任何内容的提交都需要经过测试，这条也是蹚了无数的雷才形成的流程。任何自认为代码没问题就提交而未经过测试的，往往是频繁出bug的地方。
02）版本时间。为什么版本时间这么重要？晚一天发布不行吗？真实的答案是不行。任何跨天的延期发布都可能导致游戏内众多的活动内容调整，官网内容调整，更不用说昂贵的广告费用打了水漂。所以版本时间一定要控制好，尽量提前预估好时间，留出充足的时间来准备发布。
03）其他。除了上述2点需要注意的，版本管理还需要注意兼容、版本纪录和版本发布后的线上监控等琐碎问题。
文档管理重要程度看似鸡肋，而往往则是这个鸡肋能关键时刻救你一命。一个项目周期越长，如果没有详细的文档纪录，还有项目人员的变动，可能到项目后期都没有一个人能清楚某些规则。对于测试也是一样，需要做哪些文档管理呢？见下图：
还是那句话，传承做不好的项目不是好项目。
在现在项目过程中，协调部门间的资源越发重要，这基于两点现实：一，任何个体都无法保证项目质量。二，资源具有稀缺性，需要协调一切可利用的资源为己所用。怎么做？一句话，沟通，不断沟通，玩命沟通。
踩过了无数的坑，才能明白做好项目的质量保证工作并非易事。趟了无数的雷，才能将一条条血泪总结成经验流程。
啰嗦了这么多，希望各位读者喜欢，希望能对读者们的工作有所助益～
作者简介
张敬峰，计算机专业科班出身，但代码能力是个战5渣。早年是光荣的钢铁工人，后来抱着对游戏的无限热爱，投身游戏圈，入坑较深。长期在项目一线做测试和测试管理工作，参与过《刀剑英雄》、《大决战》、《亚特兰蒂斯之龙》、手游版《英雄无敌》等众多项目的质量保证过程。