对于不可重现的缺陷如何处理？（09-3-16）（获奖名单已公布）

black_tulip

既然题目已经说了是“不可重现”，3楼的1；4楼的1，2，3；5楼的1就没必要再提了。除非是怀疑出题人的智商。人家说不可重现了，你说你再用我的方法试试。

7楼说不可重现的缺陷是非常严重的。不同意。缺陷的严重与否与其是否容易复现没有什么关系。

9楼，往往不可重现的bug多是一些意外状况的发生，意外发生前，没人会去记录。

11楼的版主回答带有其所从业的行业特征。

没什么新鲜的观点，基本上大家都认为必须记录下来，以备再次出现时参考。个人的经验，没必要太在意这种偶发的几乎不能再次复现的bug。在用户那里再次出现的概率也非常低，花费精力去研究它不合算。

我相信所有研发人员都会非常“痛恨”一个“敬业”的测试人员天天跑来跟他讨论不可重现的缺陷“可能出现的原因”。

[ 本帖最后由 black_tulip 于 2009-3-18 16:57 编辑 ]

black_tulip

3.对这些不可重现的缺陷进行过期作废的处理方式，这个可以根据测试周期进行安排，对于过期的缺陷不予以理会。

完全赞同bee先生的这句。

black_tulip

25楼第一名。结束。没什么好讨论的。各说各的，重复的内容也很多。几乎没有针对已有的回帖观点有评述。

black_tulip

原帖由 UU1983 于 2009-3-18 16:25 发表
对于不可重现的缺陷的处理方法
1找出不可重现的原因
俗话说无风不起浪，有因必有果，既然曾经有过这样的结果肯定是有原因的，好多测试人员都把不可重现的缺陷置之不理，这些测试人员中不乏经验较多的老测试人，因为他们觉得既然不可重现何必要找呢，其实这样的想法是错误的，如果经常出现这样的问题难道你还真的置之不理吗，量变达到质变
那我们如何下手呢，有心之人可发现不可重现无非是一下几种原因
1)开发人员改的过程中出现的
由于程序的不完全，就会出现怪异的现象，这个很常见
程序的不稳定造成的，由于程序的健壮性差一会这样一会那样，也会出现
网络延迟，这也是其中的一个原因
浏览器问题，有些程序不支持多浏览器每种浏览器表现都不一样
操作系统也是原因之一
2 找到原因，记录下来进行备案，以便以后的遇到相似情况进行相应的处理
3完善的规章制度
很多时候开发人员不管测试人员是否把这个测试完毕就乱改程序，及时你找到他，他就会说我还没时间呢我不改怎么办，所以完善的制度是必然的这也是开发人员和测试人员避免冲突的好办法

唉。

都经常出现了还不可重现啊。

有心之人发现的导致不可重现BUG的原因：

程序不完全，不完全能跑吗？
程序不稳定，如果程序都不稳定了，问题是会经常出现了，复现不难。
网络延迟，这是很容易复现的。
浏览器表现不一，这是很可复现的。
操作系统？唉，不可复现BUG的原因还是交给开发人员去分析吧。测试员就不要乱琢磨了。

完善制度是立足之根本，不是用来解决不可复现问题的。

black_tulip

原帖由 orange_10 于 2009-3-19 17:06 发表
OK，如果你认同以上的观点，并且重现是有必要的，就继续花力气去重现，待测代码是确定的，重现所要花费的工作量也就是覆盖率的问题了，只要你每个分支，路径都覆盖（当然这里还要考虑测试环境，测试数据和一些常量的），BUG一定可以被重现。当然不只白盒适用，黑盒也同样如此

请考虑多线程这个概念。当然，我不否认“一定”，只是最好给这个“一定”加上个期限。

black_tulip

原帖由 wangjingying 于 2009-3-19 15:18 发表
缺陷不可重现的情况有很多种，按照我个人的工作经验和理解可以分为一下几类。
1. 自动化工具执行回归测试发现缺陷，之后单跑一个测试用例不会无法重现
2. 自动化工具执行测试用例发现缺陷，之后手动无法重现问题
...

仔细看了下25楼的12345，针对4和5，我认为：

4 建议使用带有打印信息的版本重新FREE TESTING。
5 a-d的这个步骤，这是必须的。在完成这个步骤后还是无法重现的bug才称为不可重现的bug。