游戏测试流程.doc

游戏测试流程
需求分析→需求评审→测试计划→用例设计→编写用例→执行用例→提交bug→回归bug→编写报告

需求分析：
游戏内的需求来源大部分是通过市场调研或玩家的反馈。
需求文档是通过客户方提供（游戏的需求文档也有可能是策划提供的）,并告诉我们文档内对此软件的一些要求，以及此软件实现的功能。
并将文档内容转化为我们测试所需要的内容。
注意：需求文档的内容前提就要和客户鉴定清楚玩法、规则、算分等功能

需求评审：
产品最初设计阶段，产品专员的策划文档存在一些漏洞，需要三方(产品、开发、测试）沟通提出问题，修改问题，完善文档
1、吃碰杠特效问题:分析什么效果、要什么轨迹、还有效果展示是什么怎么样
2、规则需求：这个是客户提出差异最重要的，如果这块和客户确定不清楚,开发做出不仅浪费开发、测试、项目周期还会导致项目出现风险
3、鉴定清楚功能上的一些限制的要求：登录、密码等

测试计划:
测试经理会编写一份测试计划，包括测试内容，进度安排，测试资料，人员要求等.
测试计划编写六要素（5W1H)
1。why——为什么要进行这些测试;
2.what—测试哪些方面，不同阶段的工作内容；
3。when-测试不同阶段的起止时间；
4。where-相应文档，缺陷的存放位置,测试环境等；
5.who—项目有关人员组成，安排哪些测试人员进行测试
6.how—如何去做,使用哪些测试工具以及测试方法进行测试。

用例设计：
用例设计是检验一个测试人员是否合格的重要指标
常规测试方法也是一个重要技能,需要在面试时体现出来
用例设计之前，先对需求文档内容进行分析测试点（通过思维导图或流程图）
用例设计需要注意的地方：
1。考虑问题的全面性
2.逆向思维：例如游戏的吃碰杠、海底捞月、天胡、过碰、还有特殊玩法、断线重连等
3.用例设计中必不可少的模块        例：前提条件、操作步骤、预期结果
4。运用所学到的一些测试方法

编写用例：
运用所学到常用基本的黑盒测试方法：
1.等价类划分
2.边界值分析法
3。场景法

用例评审：
为了避免个人思考问题的片面性，用例设计完毕后，测试人员,需要对完成的用例进行评审，提出用例中的错误、遗漏、冗余，根据评审结果修改测试用例

执行用例：
1。测试的依据是测试用例
2。根据测试用例,测试产品，做好记录（执行通过/执行不通过/堵塞/未测试）
3.测试过程中通过使用工具提高测试效率
☆测试过程中可能会发现测试用例没有覆盖的地方,及时补充测试用例,或者用例编写错误的地方，也要及时修正。用例执行完毕之后，要对版本进行随机测试。

提交BUG：
1。在BUG禅道系统上提交BUG
2.在BUG标题处要体现BUG的现象，精简准确
3。BUG内容要描述BUG的重现步骤(如果操作才能出现BUG）,最好配有截图
4。BUG修复后的预期结果
5.记录BUG的严重程度, BUG需要修复的优先级,出现的版本号，对应的系统，IE版本（webgame比较多），修复BUG对应的开发

BUG的分类：
通俗来讲就是BUG的严重等级
1.致命：导致系统崩溃(程序闪退）
2.严重：大模块的功能缺失，影响到模块下其他功能
3.一般:小模块的功能缺失
4。提示:涉及到界面，文字,图层等显示
5.建议：对软件本身的一些建议
BUG生命周期：
新建
打开   
验证
解决
关闭

回归BUG：
1。BUG修复后，开发会提供修复版本
2。用开发提供的版本，验证之前提交的BUG（版本到手后先做冒烟测试）
3。BUG验证完毕后，产品在全部简单的执行一遍
4.没有问题就可以发布
☆此时最容易引入新BUG，因为开发在修复BUG的同时,可能会导致相关功能出现问题，所以一个好的测试，了解修复BUG的方法时，会思考此BUG可能会引起其他哪些功能出问题
注意：在稳定版本

编写报告:
测试报告的内容可以总结为以下目录:
首页
引言(目的、背景、缩略语、参考文献）
测试概要(测试方法、范围、测试环境、工具）
测试结果与缺陷分析（功能、性能)
测试结论与建议(项目概况、测试时间、测试情况、结论性能汇总)
附录（缺陷统计、测试通过标准）