游戏测试是整天玩游戏的吧？
　　游戏测试还要招本科毕业的！！！不是逗我的吧？
　　游戏测试不是拿鼠标或手指头随便点点么？
　　……
　　本文我们尝试对上述问题作出一点点专业解释，思路脱胎于2015年笔者在公司内部做的一次项目质量管理相关的分享。又将近1年时间过去了，在工作中，又有很多新的感触与心得。拿出来，跟各位读者分享下，抛块砖，引些玉。
　　无论是业内人员还是业外人员，在很多人眼里，游戏的质量保证基本上可以和功能测试划等号。这种思维是略有偏见的，我们先抛开测试的技术手段（黑盒，灰盒，白盒）不谈，其实在一款游戏的质量保证过程中，所需要做的工作非常多且杂。这里我大概总结了下常见的工作内容（可能不是太全），见下图：


　

　　　看完这张图，诸位看官是否已经打消了游戏测试是拿工资玩游戏的看法，呵呵。
　　一款游戏的质量保证工作基本围绕上图中的具体工作展开，为了保证测试任务的效率与质量，让项目组里的测试人员把上面所有工作全部承担，是不现实且耗费过多成本的。一个比较好的解决方案是：游戏项目组中的测试人员专注于功能及关联紧密的接口、日志等测试工作，与项目关联度相对弱化和可分离的内容放到平台测试组去完成。大致模型如下图：

　　这样的配置有两个优点：一是优化测试团队内部的资源分配，二是提升了项目自身的测试效率。专业的人做专业的事是整体的指导思路。
　　上面比较笼统的描述了下一款游戏项目质量保证的大致内容，以及如何优化配置测试团度资源。那么具体到实际的工作中，我们又该怎样去做好质量保证的管理呢？
　　这里笔者把质量管理工作拆解成了9个过程，我们逐一来谈一下每个部分的内容与重点。当然，无图无真相，诸位客官，图来了～

　　我们结合上图所，详细谈谈做好每个过程的正确姿势。
　　一、需求管理过程
　　需求管理过程在整个质量保证过程中非常重要，但也是经常被很多读者忽略掉的一个过程。很多测试人员习惯拿过任务来开始测试，甚至连需求文档都不看，从而出现了漏测或误测的现象。
　　对于需求管理过程，在正式开始测试之前，至少有3点是需要格外关注的。
　　01）评估需求的合理性。任何人的思维或设计都不可能尽善尽美，所以对策划人员提供的需求文档，我们也要抱有怀疑态度，在阅读需求的过程中，我们需要思考设计是否存在不合理的地方，是否有可以优化的地方。忌照本宣科，不思考的认为需求是百分百正确的。
　　02）思考测试难度与测试周期。在阅读和梳理需求文档时，尽量考虑每个功能点的测试难度与测试需要的时间。如果遇到有不能测试或很难测试的地方，尽早的提出来，与开发人员一起沟通测试方案或者提出测试工具的开发需求。评估测试时间则是为了更加准确的预估测试周期内是否能完成任务，如有困难，尽早的提出，以方便整个项目做出进度上的调整或者协调其他资源来帮忙完成。
　　03）考虑关联度。游戏功能之间的关联度比较高，在需求阶段，需要考虑当前功能与其他功能是否有关联，思考新功能的添加是否对旧有功能产生影响。如果存在关联上的影响，需要在实际测试过程中测试这些关联功能。
　　二、计划管理过程
　　在测试计划管理中，核心的关注点是时间，每个环节的时间预估的越准确，则项目进度可控性越高。反之，则会导致各种不可预估的延期情况，具体流程见下图：

　　在计划管理过程中，核心是时间，重点是计划一定要明确到个人，且需要跟进。任何计划都可能出现延期现象，不要放过，仔细分析延期原因，从而不断改进。
　　三、任务分配管理过程
　　任务分配管理过程相对简单，需要考虑的点不多，我们还是以一张图来阐述，能上图不BB，见下图：

　　四、执行管理过程
　　很多结果导向的看官可能会忽视执行管理过程，结果固然重要，但要想获得一个理想的结果，请不要忽视执行的过程。在执行过程中，尽量关注和监督，了解执行的动态信息，如发现可能导致结果打不到预期的苗头出现，需要及时作出动态调整，如增加人手、调整任务或修改预期目标等。
　　好的管理未雨绸缪，烂的管理事后诸葛亮。不要当执行结果与预期有差距是去抱怨和牢骚，不如多花精力关注执行过程，动态调整和改进也许效果更好一些。