软件测试人员遇到发现的bug不能重现怎么办？
刚刚进入测试的童鞋们,想必都遇到过提出的bug,开发要求重现之后,但是在系统上已经重现不了的情况吧.
那么碰到这样的情况,不管开发还是测试都很纠结,开发考虑,如果拒绝,万一单子打回之后又出现了这个问题,那还要给我返回来;测试也会考虑,老是碰到无法重现的bug,总是给我打回来,我也觉得挺郁闷的.
那么碰到这样的bug应该如何处理呢?
Sometime的bug真的要打回吗?测试人员碰到了应该怎么去做?接下来我们就一起讨论一下这种运气成分的bug.
首先,如果在在当前版本发现了bug,一定要在A版本进行bug重现.
如果出现了更换版本,那么在这个过程中,开发人员可能会偷偷修改bug,提升绩效考核.而且换了版本也有可能出现环境的不一致性,那么原环境的bug就不能在另外的环境上进行复现.
再就是可能出现在环境中的热补,导致代码有改变,所以引发的bug无法重现.因为有这么多不确定性,才可能导致了我们的bug无法重现或者运气化重现,知道这些问题之后,就需要排除这些影响,在我们当时出现bug的环境下进行bug的重现.如果必要再在另一个版本上重现bug,而且时间允许的话,可以考虑回退到之前的版本.
其次,就是项目时间允许的情况下，开发人员应大力协作复现bug.开发人员在自己负责的那部分代码确定没有问题之后，这时候就需要去考虑接口，是否在接口数据处理上存在问题，同时也需要其他开发人员进行配合。而测试人员也需要尽最大努力来还原当时的场景：包括环境，数据，前置条件及测试步骤等。
再就是测试人员要再次确认用例设计的覆盖度及周密性.
对于测试而言，用例设计的覆盖不够，步骤和设计不够严谨也会导致bug不在我们的掌握中.
这个时候,测试人员要注意两种情况.
一是原本用例就没有好好设计过，未经评审过，大家测试时就很随意，这样的话就要抓紧时间,赶紧把用例好好重新设计一下，再叫上相关人员进行评审，这么做的目的也是为了保证测试用例得到了项目相关人员的认可，只有这样,才能保证软件覆盖度能满足本次项目需求的要求；
第二就是是该项目已经经过严格的需求评审及用例评审了。当然，即便如此也不能避免漏测以及对特殊情况的考虑。
如果经历了以上三个步骤之后,绞尽脑汁，仍然不能使bug复现时，对这个bug进行关注,可以这么理解:经历了各种步骤的努力之后,仍然不能复现的bug一定优先级别不高，那就需要重新评估重要度.
如果项目组统一决定不影响版本发布，就密切关注这个问题，在发布后进行验证。而且该bug不能关闭，延期进行跟踪,如果之后的几个版本连续没有出现问题,那么就可以关闭问题单了。
最后,是考虑公司的整体性情况,是否针对提交bug的规范上存在需要完善的地方,那么针对这种出现的问题进行公司规范的改善,对公司流程还有测试人员素质的提升,效果都是事半功倍的.