游戏测试流程

一、游戏测试与软件测试流程的区别

1.1 区别对比

   游戏测试的流程与软件测试流程的区别大同小异，但仍然会根据公司的情况做出不同的策略和应对方式，在体验方面会存在较大的差异

   （这里只单纯阐述流程上的区别，不细分延展，如想要了解其他区别，详情可以查看前面发布的第二章）

  

1.2 比例占比

   游戏行业的体验占比要远高于软件体验，往往能够非常注重细节的公司都是互联网大厂或行业巨头，而中小型公司通常为了赶工期上线发布，逐渐忽视掉了用户体验。而有专业体验研究的软件公司更是寥寥无几。

  

二、游戏测试流程

2.1 需求相关流程

  严格来说，游戏测试人员第一步真正意义上的介入是在需求阅读阶段

  第一步_阅读需求：

  阅读一份需求是测试人员在整个测试流程中最先碰到，也是测试工作的首要目标，我们可以通过阅读需求来了解即将要开发的功能、策划设计的思路与理念。

  第二步_理解需求:

  如何理解需求？多读，多想，多看，用现有的游戏逻辑与实际情况结合需求进行理解，从而考虑测试点、异常点，可能影响到其他模块的风险点（集成），能够大致通过需求阅读预估测试工时并制定测试计划

  第三步_需求评审：

  需求评审是测试流程中的重中之重，需求评审多为三方评审（开发、策划、测试）或四方评审（开发、策划、测试、美术），需求评审也能保证测试质量？需求评审阶段测试人员应该做些什么：

  需求评审阶段应该做些什么？

（1）熟悉该需求相关内容，提前考虑到需求风险，及时反馈需求风险，让开发人员在研发过程中注意，避免产生更多的Bug

（2）分析需求漏洞，及时反馈设计缺陷，需求评审会议时可以立刻修改策划案或会议后修改，避免研发后大量修改或重做

（3）在三方、四方人员对于需求看法的讨论过程中大致确认部分需求的负责人，明确处理人，方便后续的Bug提单

（4）在评审讨论的过程中通过开发人员、策划所描述的逻辑以及实现方式，考虑可能会出现的代码逻辑漏洞以及配置漏洞

（5）对于需求中存在疑问的地方及时提出，让策划方解答问题，为后续的测试用例编写以及测试做准备

（6）可以帮助策划提供一些需求上的建议内容、以及后续的优化，分析玩家群定位，也可以避免研发需求后大量修改或重做

（7）根据讨论的各类要素判定，从测试用例的编写以及测试流程的结束所使用的测试时长，以把控需求风险及测试质量

  

  

2.2 制定测试计划

  为何要制定测试计划？

  制定测试计划的原因无非是为了保证测试工作能够如期进行，防止及规避需求所带来的发布风险，制定测试计划也能够避免我们手忙脚乱，能够井然有序的进行测试工作。

  第一步_需求估时：

  需求估时顾名思义是对需求进行充分性的评估所给出的预计测试时长，其中包括用例设计与执行的所需时间以及功能点划分等如何安排人力资源、所需的测试环境以及需要准备的测试设备

  第二步_资源准备：

  除了用例相关的测试时长预估，我们还需要准备测试环境以及测试设备，如果是管理人员还会涉及到人力资源的分配等（软件测试的标准流程对于测试计划制定非常严格，除了上述提及的以外，可能还需要测试工具、甚至是工具的版本等）

  第三步_信息同步：

  当测试负责人已经初步制定了测试计划后，应主动同步至leader负责、跨部门开发、策划及PM，让大家更好的清楚测试进度，其他人也能够根据测试所提供的信息进行风险把控

  

2.3 用例相关流程

  为何要进行用例设计及评审？

  用例设计的目的主要是记录执行点，防止漏测，通过用例的形式进行管理与交叉测试执行，评审也是如此防止漏测，设计用例的根本目的还是为了保证产品质量

  第一步_用例设计：

  用例设计顾名思义就是使用所学的用例设计方法针对需求而设计的测试用例，这是在制定测试计划后的首要目标，用例设计可以以Xmind形式输出也可以以Excel，如果时间充足的情况下，笔者还是建议大家使用Excel进行用例设计，相对于Xmind设计更全面，不容易遗漏

  第二步_用例评审：

  用例设计后就是用例评审了，用例评审分为两种，一种是“组内评审”，一种是“三方评审”

  组内评审：组内评审顾名思义就是由测试负责人完成用例设计后，由测试负责人在测试组内发起的评审，会由测试组成员进行组内评审

  三方评审：通常由开发、策划、测试三方进行跨部门用例评审，评审主要的目的也是为了保障用例的完整性，避免遗漏设计导致漏测

  通常而言先行进行组内评审，再进行三方评审，主要的目的是更加完善测试用例，在面对跨部门的时候可以节省一些沟通时间，其次嘛…怕遗漏太多，其他人会怀疑专业能力，组内评审过了，在进行三方评审，格局不就出来了嘛？…笔者个人通常是先行组内评审再次进行三方评审，不是怕遗漏，主要是习惯了这种方式，建议大家也是采用这种方式哦~

  第三步_用例补充：

  当测试用例评审完成后，测试负责人需要将用例进行完善补充，补充后不用特别再次同步，只要确保无遗漏补充即可（组内评审需要补充一次，三方评审需要补充一次）

  

2.4 测试与跟进流程

  第一步_执行测试用例

  拥有一份完整的测试用例后，就可以直接开始正式执行，执行测试用例的过程中也需要注意及时同步测试进度哦~

  第二步_记录执行结果

  执行测试用例后标记执行结果，确保已执行的测试用例能够明确的给出执行结果，同时能够保证不会重复执行，标记方式可以随意使用，自己能记住即可，如果公司有用例管理平台就更棒了~

  第三步_反馈并提交Bug

  拥有执行结果后，确保Bug能够及时反馈提单，交付开发或策划进行修复，修复过程中无论执行工作进度是否为100%都应该给予一定精力进行Bug跟进，确保Bug能够及时修复

  第四步_风险反馈及评估

  执行测试用例后能够根据现有的Bug以及修复情况等综合来判断风险，进行简易评估，评估后及时反馈风险

  

2.5 游戏体验

  测试人员也需要找游戏体验的问题吗？

  从严格的角度来讲，是的，测试人员也需要去寻找暴露体验问题，软件测试行业亦是如此，但随着时间的变化，很多公司更注重测试人员的技术能力而忽视寻找体验问题的能力或认为体验问题的发现不应由测试人员来做，但实际上测试人员是需要承担一部分体验问题发现责任的，无论你所在的公司是否需要寻找体验问题，在你的简历中写明能够发现体验问题，在中小型公司是非常能够受欢迎的哦~

  游戏体验不分步骤，对于一款已经完成且无重大Bug的需求内容就已经可以开始介入体验工作了，体验主要从以下几个维度来发现（这里只简单举例，在后续的文章会详细介绍如何进行游戏体验）：

1、剧情观、世界观、价值观

2、美术品质（包括动画、场景、特效）

3、音乐及音效

4、用户熟练度、理解程度以及习惯性行为操作

5、是否破坏或影响到其他玩法、系统上的体系

2.6 输出测试报告

  报告也不分步骤，通常而言包括几个重要内容即可，报告针对的项目或版本需求、所使用的测试环境、测试用例条数与执行条数，测试结果、测试质量情况、测试过程中遇到的瓶颈与问题

（具体根据个人与公司自身情况适当增加或删除即可）

  

  

三、知识小课堂

    问题一：游戏领域与软件领域的差距主要是在体验方面吗？  

    答：是的，领域差距主要是在体验方面，其他的流程大同小异，上述文章所提及的内容为普遍的标准流程，未做到的公司可以很明确的说是流程不标准，只不过可能影响很小，大部分公司依据版本、人力、财力等多方面考量简化制定了一套符合他们公司的流程标准罢了。  

  

    问题二：阅读需求后发现需求不明确，是否要及时询问策划？

     答：阅读需求的过程中如果发现需求不明确，笔者建议有多个问题的时候一起询问，避免频繁询问策划可能导致的沟通口角，当发现需求不明确的内容与策划同步后，提醒策划将遗漏内容同步到需求文档中再次同步给三方

  

    问题三：我们公司是小公司，很难有制定测试计划的流程和时间，我应该如何做能够保证测试工作顺利进行？

     答：如果没有充分的时间进行测试计划的制定，我们可以简单的列举内容项，并根据列举内容逐一完成来确保顺利进行测试工作，例如：

1、需求阅读理解：2h

2、测试用例编写：6h

3、测试用例执行：1d …

    当你梳理了你应该要做的内容并规划好了时间，其实就是一份简易的测试计划了，如果你的规划整体时间符合预期时间，按照计划逐一执行即可。如果不符合或者很紧凑，需要做适当调整，必要时请求人力支援。

  

    问题四：我自制了简易的测试计划，难免工作中会被打乱计划，穿插一些新工作或者临时去开会了，当计划被打乱时，怎样快速重新规划？提升工作效率？

  

    答：首先心里要有一个底，在未知的情况下计划忽然被打乱，优先要处理其他内容，我们要确保我们现有的工作进度是正常的，可以从很多维度保证工作顺利开展，例如共同点可以一起执行处理，及时反馈同步让各部门一起高效合作等等。

    为了能让大家更加清楚的理解，笔者用自身来举例：

    当我负责一个系统或玩法时，需要设计用例，设计过程中可能因为你曾经提交过某些Bug，或者和别人沟通过某些事情没有完成，在或者有一些紧急事情临时找到你，你不得不终止你现阶段的工作，当你反应过来的时候已经过了两三个小时了，这个时候我通常会变换我的思路去整理用例的设计：