游戏测试流程思维导图

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

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

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

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

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

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

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

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

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

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

使用所学的用例设计方法针对需求而设计的测试用例，这是在制定测试计划后的首要目标，用例设计可以以Xmind形式输出也可以以Excel

如果时间充足的情况下，笔者还是建议大家使用Excel进行用例设计，相对于Xmind设计更全面，不容易遗漏

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

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

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