关于bug的生命周期的几个阶段
对于一名测试人员,bug的生命周期一般分为:发现bug → 提交bug → 验证bug → 关闭bug
具体可分为三个阶段:
第一阶段:发现bug
场景:
"测试不就是发现bug吗,有什么技术含量?”
思考:
当发现一个bug,除了尽快报告问题以外,我们还能做哪些事情?
回答:
测试人员发现bug,花些时间细细品味
1) 这个bug复现的必要条件是什么?
2) 除了发现bug的这条路径,是否还有更多的路径也会导致相同的问题?
3) bug是否存在可能影响其它数据或者其它应用的副作用?
4) 其它功能模块是否也存在类似问题?
5) bug的复现路径是否在用户可达之路上?
6) 复现bug的路径是否在测试用例中?有没有可借鉴性?
通过以上分析,我们可能获得以下额外收获:
1) 通过bug的定位,确认必现路径、可能的原因,帮助开发快速定位、解决问题
2) 通过bug的路径、影响范围等分析,发掘更多的隐藏bug
《探索式测试》-恶邻测试法:重灾区往往会有更多的bug
3) 通过分析操作路径,补充测试用例,扩展测试用例范围、思路
第二阶段:提交bug
场景:
测试人员提交bug,没有详尽说明,开发无从下手,并找不出bug原因,决定不与修改
思考:如何才能提交一个有效的bug?
回答:
1. 确保bug有效。
1)不要因为环境问题或者是操作错误引起“bug”
2)不要提交一些重复的bug
2. 写好bug描述。
1)bug描述精确、没有歧义,详细简洁的测试步骤。
2)保证各个字段内容与实际现象一致。比如:版本、复现率等
3)对于复现率低的问题,尽可能提供一些可参考信息:截图、视频、日志、可能的步骤、可能原因等(如果你能通过各种手段定位到问题的原因,开发大神也会对你刮目相看的)
4)对于特殊的测试场景,附带相关的数据,比如1024kb的图片等
第三阶段:验证bug
场景:
对于测试新手而言,对于bug验证,往往是按照步骤验证复现,如果没有问题就关闭了
思考:如何做好bug的回归验证?
回答:
1. 确认好bug的复现前提及操作步骤。
2. 确认bug产生的原因及修复方法。
1) 明确bug产生的原因,触类旁通,分析其他模块可能存在的问题
2 ) 通过bug产生的原因,积累测试经验,扩展测试思路
3) 通过bug的修改方法,分析修改是否能修复问题?是否回引发其他问题?
4) 积累bug经验,在后续相关问题发现时,快速定位问题,提供解决思路
3. 确认bug的回归范围及用例。
在了解清楚bug产生的原因及修复方法基础上,再根据业务关联、功能模块关联确认回归范围,确保bug修复全面且没有引起新的bug
第四阶段:关闭bug
如果测试人员经过再次测试之后确认bug 已经被解决之后,就将bug的状态设置为“Closed”