软件测试人员遇到发现的bug不能重现怎么办?【转】

上一篇 / 下一篇  2013-06-05 10:25:55 / 个人分类:测试管理

微博上抛出一个讨论话题:下午一testlead问到,有些测试的bug会在A版本里出现,然后记录它;但开发人员在当前B版本试图重现时发现不能重现,故reject它。那么测试就郁闷了,待到下一轮回归测试可能是C版D版本,如果再出现自然reopen,但如果不复现是否真的应该关掉它吗?各位对这种sometimes bug怎么处理的啊?

  这个问题可能每个测试人员都会遇到,我说说我个人观点,供大家讨论。

  1、在A版本发现的bug应该在A版本进行重现

  我们知道,有很多原因会导致A版本的bug可能不能在B版本重现:1)开发人员自己偷偷解了bug,以免受到KPI考核;2)环境差异,可能B版本的代码在A版本的环境也会出问题,但是在开发环境可能就不能复现;3)代码变更,也许是其他的代码引起的bug,B版本时其他开发已经修改,此类可以归纳为相关联功能引起的bug;4)AB两版本进行复现的前置条件及步骤已不同。

  既然有这么多可能性,那我们就应该排除影响,让问题简单化,保持环境和代码一致的情况下进行复现。A版本的bug如果在B版本不能复现,时间和条件允许的话,那就回退代码到A版本,有个前提不用回退,那就是已准确定位问题了,并且确定在B版本已经解决它了。

  2、项目时间允许的情况下,开发人员应大力协作复现bug

  对于”疑难杂症“,开发人员应大力配合测试人员进行复现:1)如果对于不好调试的代码就打印更多log;2)可以通过连接测试环境数据库并回滚代码到A版本,根据获悉的已有情况添加断点调试代码;3)做更细致的code review等等方式。在自己负责的那部分代码确定完没有问题,这时候就需要考虑到接口,是否在接口数据处理上的问题,就需要其他开发人员配合。而测试人员需要尽最大努力来还原当时的场景:环境,数据,前置条件及测试步骤等。

  3、测试人员要再次确认用例设计的覆盖度及周密性

  有几种情况会导致不可复现:1)环境;2)代码;3)数据。而数据又可以归纳到代码容错性处理上,环境其实是可以很好还原的,那出现不容易复现的bug就大多数是归于代码和数据上了,对于测试而言,用例设计的覆盖不够,不够严谨就会导致bug不在我们的掌握中。

  这个时候,我们有两种情况:一是原本用例就没有好好设计过,未经评审过,大家测试时就很随意,勿容置疑,赶紧把用例好好琢磨琢磨,再叫上项目相关人员进行评审,这么做的目的也是为了保证测试用例得到了项目相关人员的认可,各种情况大家都讨论过,保证在需求上大家的一致性,保证软件覆盖度能满足本次项目需求的要求,做到需求100%覆盖,开发人员若再提出更多建议,那也可以弥补一些黑盒测试时可能遗漏的情况;二是该项目已经经过严格的需求评审及用例评审了。当然,即便如此也不能避免漏测以及对特殊情况的考虑。

  当然,要这么做的前提是这个bug很严重,影响了版本的发布,有必要召集大家协力解决掉它。

  4、绞尽脑汁,它仍然不能复现时,保持关注

  我相信,通过以上步骤的努力,仍然不能复现的bug一定是优先级不高的,那就再评估重要度,若通过项目组决定不影响版本发布,就密切关注此bug,在发布后验证时也重点关注下。而且该bug不能关闭,依次往以后版本中顺延,并且每轮测试时都要尝试再次复现。那何时可以关闭呢?也许3,5个版本发布后,没有出问题就可以决定关闭它了。

  5、思考测试流程及测试规范,及时更正走过的弯路,制定提交bug的规范,便于开发及我们自己复现

  有一次,就会有第二次,我们应该及时响应,即便不能亡羊补牢,也要防患未然。 提交bug的规范,这个可能每个公司情况不一样,有些公司木有限制,提交的bug也是千人千面,这对于开发人员理解bug和复现bug无疑增加了难度。而规范了bug提交,若记录了此bug的前置条件,使用的数据及操作步骤,可能会大有益处。当然,此处不是说每个bug都这么详细。


TAG:

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

Open Toolbar