Bug详解
发现bug仅仅是测试工作的开始
bug的界定标准
与需求设计不符
违背常识
bug提报标准
标题【模块】+简短描述
测试环境:版本,系统,服务器,账号
描述:详细描述
重现步骤:重新啊bug的详细流程步骤及复现概率
希望结果:修复后结果
备注:log,截图
bug验证标准
严格按照复现步骤验证
去除测试环境的影响
验证标注:注明时间
扩展:是否对其他肝功能有影响,做简单回归
注意点:验证不能只看前段展现,更应关注后端数据
bug的跟踪与推动
有责任跟踪
及时与开发沟通,了解修复状态病提供修复过程中的支持
不修复的bug需要与开发和上级确认
bug修复后,需要及时验证
BUG详解(发现BUG仅仅是测试工作的开始)
BUG 的界定标准;1.与需求设计不符 2.违背常识
注意点
优先级P0 致命 立即修复
p1 严重 紧急修复
p2 一般 允许一段时间内修复
p3 提示 允许延期修复
bug的提报标准
回去确认,神清气爽
这个例子挺烂的 信息明显不全
怎么听都是小厂干的事 责任不明, 流程不明
BUG的验证标准
BUG的提报标准
BUG的生命周期
游戏测试BUG
BUG的跟踪与推动
1、每个人都有责任跟踪自己的BUG修复状态
2、及时与开发沟通,了解修复状态并提供修复过程中的支持
3、久不修复的bug需要与开发和上级确认如何处理
4、bug修复后,需要及时验证
BUG的验证标准
1、严格按照复现步骤验证
2、去除测试环境的影响
3、验证标注:需要注明验证的版本、服务器等
4、拓展:是否对其它功能有影响,做简单回归
5、注意点:验证不能只看前端展现,更应关注后端数据
BUG的提报标准-一个bug的例子
BUG的提报标准:
1、标题:[模块名称]+简短描述
2、测试环境:标明测试用的版本,系统,服务器,账号等
3、描述:bug的详细描述
4、重现步骤:重现bug的详细流程步骤及复现概率
5、期望结果:希望bug修复后的结果
6、备注:log、截图等
BUG的等级划分
1、P0:致命错误,需要立即修复,如宕机、重启性报错等
2、P1:严重错误,需要紧急修复,如功能流程错误、数值错误等
3、P2:一般错误,允许一段时间内修复,如功能的简单错误、界面错误等
4、P3:无关紧要的错误,允许延期修复,如文字错误、某个像素点缺失等等
BUG验证标准
BUG汇报标准2
BUG汇报标准1
BUG等级划分p0——>p3
BUG的提报标准例子
BUG的生命周期
BUG的定界标准
Bug的详解:
1.Bug的界定准则:是否符合需求和是否违反常识
2.Bug的生命周期:发现bug->和开发人员反应,修复bug->验证bug->通过后 关闭bug意味bug死亡(若是在验收bug时bug仍未修复,则重复以上步骤)
3.Bug的等级划分:一般4或5个等级(P0致命错误P1严总错误P2一般错误P3无关紧要错误)
4.Bug的提案标准:
a.标题:【模块名称】+简短描述
b.测试环境:标明测试试用的版本,系统,服务器,账号等
c.描述:bug的详细描述
d.重现步骤(重要):重现bug的详细流程步骤及复现概率,让开发人员节省时间
e.期望结果:希望bug修复后的结果
f.备注(不重要):日志信息(log),截图信息等
5.Bug验收标准:
a.严格按照复现步骤验证
b尽量使用发现bug时的测试环境
c.验证标注:需要注明验证的版本、服务器等
d.拓展:尽量思考,是否对其它功能有影响,做简单回归
e.注意点:验证不能只看前端展现,更应该关注后端数据。(比如前端显示的数据正确,但后端的数据库不正确)
5.BUG的跟踪与推动:
a.每个人都有责任跟踪自己的bug的修复状态
b.及时与开发沟通,了解修复状态并提供修复过程中的支持(比如需要bug的详细信息)
c.久不修复的bug需要与开发沟通,如果开发认为bug问题不大可以和需求确认如何处理,若真的问题不大就可以直接关闭bug了
d.bug修复后,需要及时验证
6.最好课以做个bug的数据分析,比如项目中bug等级的统计,各开发人员中未修复bug的统计等等
BUG详解
发现BUG仅仅是测试工作的开始
BUG的界定标准:与需求设计不符;违背常识
BUG的生命周期:发现bug;提交给开发;开发修复;测试验证(不通过继续指派给开发);通过后关闭;上线前回归
BUG的等级划分:
P0:致命错误,需要立即修复,如宕机、重启性报错等;
P1:严重错误,需要紧急修复,如功能流程错误、数值错误等;
P2:一般错误,允许一段时间内修复,如功能的简单错误、界面错误等;
P3:无关紧要的错误,允许延期修复,如文字错误、某个像素点缺失等等
bug的报错标准
标题:[模块名称]+简短描述
测试环境:标明测试用的版本,系统,服务器,账号等
描述:BUG的详细描述
重现步骤:重现bug的详细流程步骤及复现概率
期望结果:希望bug修复后的结果
备注:log,截图等
bug举例:
标题:〔士兵〕打开士兵技能升级页面报错
测试环境:内网测试服,V1.1.0版本,iOS系统,账号:ykl02
详细描述:当我们在游戏中打开士兵升级页面时,系统提示报错信息
重现步骤:1、进入游戏。2、打开士兵技能升级页面。3、系统报错。
期望结果:能够正常升级士兵技能,打开升级页面不报错
备注:报错信息见下面截图
BUG的验证标准:
严格按照复现步骤验证;
去除测试环境的影响,尽量使用提交BUG时的注明的环境;
验证标注:需要注明验证验证的版本、服务器等
拓展:是否对其它功能有影响,做简单回归
注意点:验证不能只看前端展现,更应关注后端数据
(比如购买道具,花了100,但是只扣了50;如果修复之后,前端确实显示扣了100,但是数据库中只扣了50,这就是“BUG的伪修复”)
BUG的跟踪与推动:
每个人都有责任跟踪自己的bug的修复状态;
及时与开发沟通,了解修复状态并提供修复过程中的支持;
久不修复的bug需要与开发和上级(需求人员)确认如何处理;
bug修复后,需要及时验证
BUG的数据分析:
根据bug优先级看各个优先级的bug数量;
根据项目人员看各个开发人员的bug数量;
根据功能模块看各个模块的bug数量
BUG详解
发现BUG仅仅是测试工作的开始
BUG的界定标准:与需求设计不符;违背常识
BUG的生命周期:发现bug;提交给开发;开发修复;测试验证(不通过继续指派给开发);通过后关闭;上线前回归
BUG的等级划分:
P0:致命错误,需要立即修复,如宕机、重启性报错等;
P1:严重错误,需要紧急修复,如功能流程错误、数值错误等;
P2:一般错误,允许一段时间内修复,如功能的简单错误、界面错误等;
P3:无关紧要的错误,允许延期修复,如文字错误、某个像素点缺失等等
bug的报错标准
标题:[模块名称]+简短描述
测试环境:标明测试用的版本,系统,服务器,账号等
描述:BUG的详细描述
重现步骤:重现bug的详细流程步骤及复现概率
期望结果:希望bug修复后的结果
备注:log,截图等
bug举例:
标题:〔士兵〕打开士兵技能升级页面报错
测试环境:内网测试服,V1.1.0版本,iOS系统,账号:ykl02
详细描述:当我们在游戏中打开士兵升级页面时,系统提示报错信息
重现步骤:1、进入游戏。2、打开士兵技能升级页面。3、系统报错。
期望结果:能够正常升级士兵技能,打开升级页面不报错
备注:报错信息见下面截图
BUG的验证标准:
严格按照复现步骤验证;
去除测试环境的影响,尽量使用提交BUG时的注明的环境;
验证标注:需要注明验证验证的版本、服务器等
拓展:是否对其它功能有影响,做简单回归
注意点:验证不能只看前端展现,更应关注后端数据
(比如购买道具,花了100,但是只扣了50;如果修复之后,前端确实显示扣了100,但是数据库中只扣了50,这就是“BUG的伪修复”)
BUG的跟踪与推动:
每个人都有责任跟踪自己的bug的修复状态;
及时与开发沟通,了解修复状态并提供修复过程中的支持;
久不修复的bug需要与开发和上级(需求人员)确认如何处理;
bug修复后,需要及时验证
BUG的数据分析:
根据bug优先级看各个优先级的bug数量;
根据项目人员看各个开发人员的bug数量;
根据功能模块看各个模块的bug数量