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

havards

人为重现BUG性价比低并且收效甚微：
1.作为一个测试人员，作为一个人，出现不可重现BUG的缺陷是不可避免的，因为我们不是录音机或者摄像机，不可能把之前做过的工作或者步骤都记的一清二楚。
2.如果每出现一个BUG，都去人为的重现BUG，如果此BUG严重性非常高的话，这样或许还有点性价比，但是如果严重性不高，还花费1个上午或者1天来重现一个BUG，太不合算。

所以，我想到了自动化测试。
虽然具体的步骤记不清，但是大概的步骤应该都知道，毕竟是自己发现的BUG，把这些编译成脚本，借助自动化测试工具，使其自动执行编写的步骤。
这里就需要一个数据，就是执行的次数，自动执行100次或者1000次，相信这个数据拿给领导看，也比较有说服力。

再者，我们得结合我们国内的软件开发方式，就我所知，国外的一些测试比较规范，发展比较好的公司，1个beta可能只做一次完整的测试。
而我们国内的就算比较厉害的软件公司，1个beta可能都需要好几个版本来支持，当然了这里面可能是由于版本控制的原因，这里暂且不提。就算这个build里没有重现出这个BUG，下个build遇到可以再报嘛，不发beta还不都一样。

havards

突然想到一个问题：
对于不可重现的缺陷的处理是主题，但是要是延伸下，如果用例设计的完善，细致的话，是否可以最大程度的避免不可重现问题的产生呢？步骤详细的话，基本上在其中一步出错了的话，之前的动作就全清楚了。
当然我指的是按用例测试的情况，而不是freehand，相信测试出来的BUG大多数应该是通过用例产生的，而不是freehand产生，这样不好跟踪。