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


 

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

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

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

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

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