游戏测试用例及游戏测试bug详解
游戏测试⽤例及游戏测试bug详解游戏测试⽤例
测试⽤例设计步骤
天龙八部 演员表⼀、需求⽂档分析
1、⽂档阅读
切忌不阅读需求⽂档，上来直接写⽤例，⾄少读3遍⽂档。
细致理解功能设计意图和设计思路 。
避免粗略理解带来的⽤例遗漏。
⼀些重要数据可能隐藏在不起眼的语句中 。
加深对功能的理解，否则随着时间推移，可能会遗忘很多内容。
2、功能细节沟通探讨
不明⽩的地⽅需要及时确认，切忌脑补想当然 。
尽早确认细节，最好在开始写之前就确认完毕。
关注需求变更，需求变更后，⼀定要跟程序和策划确认
3、逻辑梳理
⽂档不⼀定是按照流程顺序写的，⽽且经常存在功能交叉的地⽅。
梳理出框架后，逐步细化。
汽车电瓶如何充电4、功能拓展思考
设计缺陷思考
测试难点思考（领取奖励后刷新）
关联度思考（领取道具存储位置、道具重复问题）
特殊情况思考（领取道具过程中断⽹断电情况）
5、兼容相关思考
版本兼容（⼀种服务器两种版本中的交互）
功能兼容（⽼功能基础上增加新的内容）
操作系统版本兼容
分辨率兼容
⼆、功能模块划分
1、功能模块划分原则
⾼内聚、低耦合
重整体、清局部
2、模块划分⽅法
功能流程法：将功能的基本流程画出来，根据流程的每个⼤的环节进⾏模块划分，然后再细化和查漏补缺。
层次划分法：按照逻辑层次逐层细化出模块的过程，⽐较适⽤于UI划分，⼤的系统模块划分等。
类型划分法：按照功能包含内容的不同类型进⾏划分。
注：
不同的划分法适⽤不同的场景，要具体问题具体分析 有时候⼀个功能需要结合多种⽅法进⾏划分。
里约是哪个国家的
划分⽅法不重要，划分原则更重要⼀些。
划分完毕后，要结合需求⽂档重新梳理，确保模块清晰、覆盖完整。
三、测试⽤例编写
1、格式
清晰的格式为何如此重要
让⽤例的脉络更清晰明了 。
⽅便需求变化后的更新维护 。
⽅便执⾏⼈员快速⼊⼿。
⾸页内容
⽤例名称
⽤例对应的游戏版本
编写⼈、修改⽇期、修改备注
需求⽂档的链接或地址
正⽂页内容
功能逻辑图（如果有）
⽤例id
模块功能名称
测试先决条件
输⼊信息
输出结果
备注信息
注：
尽量保证逻辑清晰。
尽量保证⼀个输⼊只对应⼀个输出。
保证每次更新⽤例后都有明确的记录标注。
尽量保证⼀个⽤例内格式统⼀。
2、常⽤的测试⽤例编写⽅法
（1）等价类
等价类：指的是⼀个输⼊集合内，任何输⼊数据对于输出的验证来讲都是等效的，此刻我们就可以选取少量代表性的测试数据来代表整体数据。
有效等价类：是对输出来讲有意义的输⼊集合，可以验证程序的正常功能和流程。
⽆效等价类：是对输出⽆意义的输⼊组合，⽤于验证⾮正常流程输⼊对输出的影响。
（2）边界值
边界值：对输⼊或输出的边界值进⾏分析的⼀种⽅法。
边界值的确定：⼀般选取正好等于，刚刚⼩于和刚刚⼤于3种情况作为测试数据。
通常适⽤的范畴：数值测试、字符串测试、数据类型测试等。
（3）因果图&判定表
因果图：简单的来说就是输⼊与输出之间因果关系的⼀种关系图。
判定表：可以通过因果图来⽣成的⼀种结果判定表。
因果图常常与判定表⼀起使⽤，通过因果图⽣成判定表，通过判定表来书写测试⽤例圣诞节2022年是几月几日
（4）正交实验法&场景法
3、测试⽤例编写注意事项
输⼊条件要单⼀明确，尽量不⽤容易引起误解的词，⽐如：可能、⼤概等。
输出要判断且明确，最好不⽤“显⽰正确”这种词汇。
测试步骤要可执⾏
保持尽量稿的覆盖度。
能抽象的尽量抽象出来，避免⽆意义的冗余。
四、测试⽤例整理与维护
需求变化后需要及时更新⽼的测试⽤例，并写清修改情况的备注（修改内容，产品和开发负责⼈。
测试⽤例应该尽量避免冗余，如果遇到重复的⽤例，需要根据实际情况进⾏修改。
注意测试⽤例的备份，写完后最好⾃⼰本地也备份⼀份，避免线上被⼈误删。
游戏测试bug详解
五、BUG的界定标准
1、与需求设计不符
一个人就好2、违背常识
六、BUG的⽣命周期
发现bug
提交给开发
开发修复
测试验证
win8升级win10通过后关闭/不通过继续指派给开发
上线前回归
七、BUG的等级划分
P0：致命错误，需要⽴即修复，如宕机、重启性报错等。
P1：严重错误，需要紧急修复，如功能流程错误、数值错误等。
P2：⼀般错误，允许⼀段时间内修复，如功能的简单错误、界⾯错误等。
P3：⽆关紧要的错误，允许延期修复，如⽂字错误、某个像素点缺失等等。⼋、BUG的提报标准
标题：【模块名称】+简短描述
测试环境：表明测试⽤的版本，系统，服务器，账号等。
描述：bug的详细描述
重新步骤：重现bug的详细流程步骤及复现概率。
期望结果：希望bug修复后的结果 。
备注：log，截图等。
九、BUG的提报标注——⼀个bug例⼦
标题：[⼠兵]打开⼠兵技能升级页⾯报错 。
测试环境：内⽹测试服，v1.1.0版本，IOS系统，账号：zjf01。
详细描述：当我们在游戏中打开⼠兵升级页⾯时，系统提⽰报错信息。
重现步骤：（1）进⼊游戏。（2）打开⼠兵技能升级页⾯。
（3）系统报错。
期望结果：能够正常升级⼠兵技能，打开升级页⾯不报错。
备注：报错信息见下⾯的截图
⼗、BUG的验证标准
严格按照复现步骤验证 。
去除测试环境的影响。
验证标注：需要注明验证的版本、服务器等。
⼗⼀、BUG的验证标准
拓展：是否对其它功能有影响，做简单回归。
注意点：验证不能只看前端展现，更应关注后端数据。
⼗⼆、BUG的跟踪与推动
每个⼈都有责任跟踪⾃⼰的bug的修复状态。
及时与开发沟通，了解修复状态并提供修复过程中的⽀持。
久不修复的bug需要与开发和上级确认如何处理。
Bug修复后，需要及时验证。
九、BUG的数据分析

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。