起航学习网

刚刚进入测试的童鞋们,想必都遇到过提出的bug,开发要求重现之后,但是在系统上已经重现不了的情况吧。

那么碰到这样的情况,不管开发还是测试都很纠结,开发考虑,如果拒绝,万一单子打回之后又出现了这个问题,那还要给我返回来;测试也会考虑,老是碰到无法重现的bug,总是给我打回来,我也觉得挺郁闷的。

那么碰到这样的bug应该如何处理呢?

Sometime的bug真的要打回吗?测试人员碰到了应该怎么去做?接下来我们就一起讨论一下这种运气成分的bug。

首先,如果在在当前版本发现了bug,一定要在A版本进行bug重现。

如果出现了更换版本,那么在这个过程中,开发人员可能会偷偷修改bug,提升绩效考核。而且换了版本也有可能出现环境的不一致性,那么原环境的bug就不能在另外的环境上进行复现。

再就是可能出现在环境中的热补,导致代码有改变,所以引发的bug无法重现。因为有这么多不确定性,才可能导致了我们的bug无法重现或者运气化重现。

知道这些问题之后,就需要排除这些影响,在我们当时出现bug的环境下进行bug的重现。如果必要再在另一个版本上重现bug,而且时间允许的话,可以考虑回退到之前的版本。

其次,就是项目时间允许的情况下，开发人员应大力协作复现bug。开发人员在自己负责的那部分代码确定没有问题之后，这时候就需要去考虑接口，是否在接口数据处理上存在问题，同时也需要其他开发人员进行配合。

而测试人员也需要尽最大努力来还原当时的场景：包括环境，数据，前置条件及测试步骤等。

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

对于测试而言，用例设计的覆盖不够，步骤和设计不够严谨也会导致bug不在我们的掌握中。

这个时候,测试人员要注意两种情况。

一是原本用例就没有好好设计过，未经评审过，大家测试时就很随意，这样的话就要抓紧时间,赶紧把用例好好重新设计一下，再叫上相关人员进行评审，这么做的目的也是为了保证测试用例得到了项目相关人员的认可，只有这样,才能保证软件覆盖度能满足本次项目需求的要求;

第二就是是该项目已经经过严格的需求评审及用例评审了。当然，即便如此也不能避免漏测以及对特殊情况的考虑。

如果经历了以上三个步骤之后,绞尽脑汁，仍然不能使bug复现时，对这个bug进行关注,可以这么理解:经历了各种步骤的努力之后,仍然不能复现的bug一定优先级别不高，那就需要重新评估重要度。

如果项目组统一决定不影响版本发布，就密切关注这个问题，在发布后进行验证。而且该bug不能关闭，延期进行跟踪,如果之后的几个版本连续没有出现问题,那么就可以关闭问题单了。

最后,是考虑公司的整体性情况,是否针对提交bug的规范上存在需要完善的地方,那么针对这种出现的问题进行公司规范的改善,对公司流程还有测试人员素质的提升,效果都是事半功倍的。

免责声明：文章内容转载自公开网络，如有侵权，请联系我们删除。

软件开发测试人才四大魅力元素

——就业竞争小

——高薪没商量

——就业质量高

——无性别歧视

套用狄更斯那句话说：对于急需软件开发测试人员的企业来说，这是一个最坏的时代，但对软件开发测试人才来说，这是一个最好的时代。“随着软件市场的成熟，人们对软件作用的期望值也越来越高，软件的质量和功能可靠性也正逐渐成为人们关注的焦点。”

文章出自：http://qh.itpxw.cn/jyzn/202179897.html

文章标题：提交的bug不能重现怎么破

免责声明：本站文章均由入驻起航学习网的会员所发或者网络转载，所述观点仅代表作者本人，不代表起航学习网立场。如有侵权或者其他问题，请联系举报，必删。侵权投诉