文档介绍：游戏测试流程需求分析→需求评审→测试计划→用例设计→编写用例→执行用例→提交bug→回归bug→编写报告 需求分析:游戏内的需求来源大部分是通过市场调研或玩家的反馈。需求文档是通过客户方提供(游戏的需求文档也有可能是策划提供的),并告诉我们文档内对此软件的一些要求,以及此软件实现的功能。并将文档内容转化为我们测试所需要的内容。注意:需求文档的内容前提就要和客户鉴定清楚玩法、规则、算分等功能 需求评审:产品最初设计阶段,产品专员的策划文档存在一些漏洞,需要三方(产品、开发、测试)沟通提出问题,修改问题,完善文档1、吃碰杠特效问题:分析什么效果、要什么轨迹、还有效果展示是什么怎么样2、规则需求:这个是客户提出差异最重要的,如果这块和客户确定不清楚,开发做出不仅浪费开发、测试、项目周期还会导致项目出现风险3、鉴定清楚功能上的一些限制的要求:登录、密码等 测试计划:测试经理会编写一份测试计划,包括测试内容,进度安排,测试资料,人员要求等。测试计划编写六要素(5W1H)——为什么要进行这些测试;—测试哪些方面,不同阶段的工作内容;—测试不同阶段的起止时间;—相应文档,缺陷的存放位置,测试环境等;—项目有关人员组成,—如何去做,使用哪些测试工具以及测试方法进行测试。 用例设计:用例设计是检验一个测试人员是否合格的重要指标常规测试方法也是一个重要技能,需要在面试时体现出来用例设计之前,先对需求文档内容进行分析测试点(通过思维导图或流程图)用例设计需要注意的地方::例如游戏的吃碰杠、海底捞月、天胡、过碰、还有特殊玩法、        例:前提条件、操作步骤、   编写用例:运用所学到常用基本的黑盒测试方法: 用例评审:为了避免个人思考问题的片面性,用例设计完毕后,测试人员,需要对完成的用例进行评审,提出用例中的错误、遗漏、冗余,根据评审结果修改测试用例  执行用例:,测试产品,做好记录(执行通过/执行不通过/堵塞/未测试)☆测试过程中可能会发现测试用例没有覆盖的地方,及时补充测试用例,或者用例编写错误的地方,也要及时修正。用例执行完毕之后,要对版本进行随机测试。 提交BUG:,精简、(如果操作才能出现BUG),, BUG需要修复的优先级,出现的版本号,对应的系统,IE版本(webgame比较多),修复BUG对应的开发    BUG的分类::导致系统崩溃(程序闪退):大模块的功能缺失,::涉及到界面,文字,:对软件本身的一些建议BUG生命周期:新建打开   验证解决关闭        回归BUG:,,验证之前提交的BUG(版本