不可重现的原因多了去了...
有可能是当时的网络原因造成的
有可能是程序BUG
有可能是数据库问题
有可能是人为原因
有可能是IO
只有先记录下来操作流程,等手上别的工作都做完了,再来详细的发觉这个"不可重现"的问题
反复的实验,尽量的找其规律........
(等这一轮的测试结束了还未找到的话,就只有等下个版本在来回顾这个问题了)
偶在测试中经常遇到这种情况，公司是这样处理的：
看这个Bug的严重性和测试阶段，如果是在系统测试的初级，且严重性在一般以上（含一般）是要提的，把当时的环境和操作步骤详细写清楚。然后跟踪3个版本，回归时对于复现率的阶段测试的次数有所不同，一般是20次。3个版本上都没复现的话就closed
其实偶觉得这样处理也太好，因为有时候还会遇到在3个版本以后出现，这时将它reopen,开发也不太重视的。偶的想法就是一直open，直到产品上市一段时间以后closed比较合适的。
不可重现的bug其实并不多，如果出现了，也不一定都是很严重的问题。万一出现了这样的Bug，最好还是把它先记录下来，如果在一定的时间内（比如几个月）没有再次出现，那么就认为这个bug可以关闭了。
其实不可重现的BUG比较常见,特别是在性能测试中,你用几天,一周甚至一个月来收集数据,相信大家不会为了再次证明数据是确实错误而再去运行一次的.所以此时分析就显得十分重要了.
缺陷不可重现的情况有很多种，按照我个人的工作经验和理解可以分为一下几类。
1. 自动化工具执行回归测试发现缺陷，之后单跑一个测试用例不会无法重现
2. 自动化工具执行测试用例发现缺陷，之后手动无法重现问题
3. 手动执行测试用例发现缺陷，之后无法重现
4. Free Testing发现缺陷，之后无法重现
5. QA的环境发现BUG，DEV无法重现
对于第一类情况：
我会先把这单个测试用例用自动化工具跑上3-5遍，这样能够帮助我基本确定这个缺陷是随机发生的还是（暂时）不能重现。
对于前者，我会它当作一个正常的缺陷来处理。
对于后者（暂时不能重现的），我会用自动化工具把这个测试用例以及其前几个相关的测试用例一起重新跑一遍，这样我也许能够找到这些测试用例间隐藏的关联性而造成的缺陷.
如果这样还不能够重现的话就比较麻烦了，按照项目的进度，我会选择先把它放在一边或者做以下尝试和分析
a. 分析自动化工具运行时生成的log文件（可能第一次脚本在运行时进入了一个奇怪的分支）
b. 把回归测试从头到底再跑一次（工作中确实还碰到一次只有从头运行回归测试才能重现的情况）
c. 搭建全新环境，用自动化工具执行测试用例（有些缺陷只有在第一次才会发生）
d. 自动化工具与被测软件之间有冲突（可能性相当之小...）
对于第二种情况:
我会先降低自动化工具执行测试用例时的速率或修改一些相关参数（毕竟人点的速度赶不上自动化工具吗）。如果没有进展，我会通过分析自动化工具运行时生成的脚本，或者肉眼看自动化工具执行用例的过程来检查自动化过程与手动测试用例有无区别。如果仍没有收获，我可能会做以下尝试
a. 找出一些能够获取或者阅读dump file的工具，从接近DEV的角度尝试去分析自动测试与手动测试的不同之处
b. 自动化工具与被测试软件之间有冲突（我永远相信自动化工具是有问题的....^_^）
对于第三类情况:
一定要严格执行测试用例!!!否则还不如去做free testing!!!
回忆一下发现缺陷时与无法重现时在操作上有啥区别。如果没有的话，那么继续严格执行测试用例多次，以防缺陷为随机发生。若还没有进展，把情况如实记录下来,以备日后分析用
对于第四类情况:
这就比较复杂了，也许是重现步骤不对，也许是随机缺陷的原因，个人想不出太好的办法.....不过对于经常能够在free testing当中发现问题但无法重现的人，可以考虑在做free testing的时候用录像工具进行记录！！！
对于第五类情况:
俺熟悉的DEV，基本都是神一般的人。他们的桌面上总是放满了
形形色色的工具图标，任务栏上永远是20+个对话框.......所以俺心中对于DEV的DEBUG环境总是怀着一个大大的问号与感叹号.....
如果DEV不能重现问题，我一般会做下面这些事情
a. 确认DEV重现步骤是否正确（DEV好像经常会弄错步骤的说-_-|||）
b. 如果步骤正确，查看软件版本号（DEV好像比较喜欢用最新codeline进行DEBUG）并请DEV使用与QA相同的版本进行DEBUG。如果这个缺陷在老版本中能重现在新版本中不能，那么需要DEV分析这一段时间内codeline里面的changelist,把可能与此缺陷相关修改及信息记录在缺陷管理工具中。
c. 如果DEV使用QA测试的版本还不能重现，那么查看DEV用的是DEBUG build还是RELEASE build并请DEV使用后者重现缺陷。
d. 如果还不行...我会考虑新建一个标准测试环境来为DEV重现缺陷,或者直接让DEV在测试机上重现缺陷跟踪及定位。
个人看法，轻拍
不可重现的BUG；大致可以分为：
1. 实在是不可重现
a. 测试人员误操作导致 -- 结束，并且在以后的工作中要注意不要犯类似的错误
b. 开发人员自己发现错误并且偷偷改正 -- 应该跟开发人员沟通好，这样偷偷改正会对测试带来一些噪声，应该避免。
2. 偶然出现，但是没有规律
a. 由于使用的被测软件版本不一导致 -- 通过改进测试流程来避免
b. 真都有BUG，但是不能100%重现 -- 尽可能地找出真正的原因，因为计算机软件的行为其实都是确定的，只是在不用的环境下（测试数据，操作系统，版本等……）下导致行为错误行为不能百分百重现。作为一个优秀的测试人员，应该努力把导致BUG出现的步骤找出来，不能说是“我现在找到个BUG，有时候出现有时候出现不了，你们自己找吧，肯定有问题的”。
总之，对于测试人员来说，发现一个偶然出现的问题，就一定要把它当作一个肯定存在的问题，然后运用自己的知识，经验，找出其中的原因，“不以恶小而为之”，放过任何一个可能存在的问题。:lol
25楼第一名。结束。没什么好讨论的。各说各的，重复的内容也很多。几乎没有针对已有的回帖观点有评述。
本公司遇到这种情况，首先是争取能够截到图，最重要的是把执行的步骤给记录下来
然后再备注重说明，大概的说明，这种情况发生的概率等等
然后让开发人员对应，开发人员当然是项目经理等对该问题进行判断
首先判断该BUG的严重程度，作用不累述了
其次，积极地借鉴白盒测试的方法论，我们从代码角度去看问题。
个人见解：
其实任何BUG，只要你看到了，就不可能不能重现，只是你的输入、环境、也就是广义上的input 参数有不同而已，所以我一直不认同“不可重现的缺陷”这样的说法，最多只能说是“难以重现”
OK，如果你认同以上的观点，并且重现是有必要的，就继续花力气去重现，待测代码是确定的，重现所要花费的工作量也就是覆盖率的问题了，只要你每个分支，路径都覆盖（当然这里还要考虑测试环境，测试数据和一些常量的），BUG一定可以被重现。当然不只白盒适用，黑盒也同样如此
最后还有一种可能，就是人为的误操作，脏数据等造成的，但是运用以上的方式也是一样可以重现。
我的建议是：
1、问题第一次出现时就问题的相关信息都记录下来并记入缺陷库（暂不提交），包括出页面截图等。
2、重现问题，如果尝试多次都重现不了则在备注里面说明，提交缺陷；
3、对不可重现的问题要持续跟踪，设定一定的级别，达到一定时间没重现，就把缺陷降一个级别再跟踪，直到问题没的级别来降。
这样做的优缺点：
1、不会错过缺陷
缺点：
1、非问题率有可能会上升
根据操作步骤，多次重复执行，以确定bug是否不可重现；（执行次数固定为5或10，这样可以给出一个重现几率）
然后将bug描述记录下来，最好是附上截图或操作录像之类的文件，更加直观；
至于bug是否该修复，可先与开发人员沟通，然后再和PM沟通。
1.要考虑这个BUG对系统造成影响，比如是导致系统崩溃的BUG，必定要探索测试，来定位这个BUG，要是对系统的影响不大，比如不能影响系统的整体功能，像楼上的说的就不要死钻牛角尖在这上面花费精力了。
支持bht2000，因为不可重现的BUG严重性是不好判断的，2000的三不做法很有道理
根据我的体会，对于不可重现的缺陷处理不当，很多都源于绩效考核手段不当，但凡绩效考核里牵涉到bug数的，不可重现缺陷肯定是没人跟踪的。。。
其实说白了就两点：记录+跟踪
至于具体流程怎么做，各个项目组情况不同不能一概而论。
我是还没入行的新人，学习学习。顶你们的肺
是不是应该叫不易于重现的缺陷比较准确一些啊~~
一般对于这样的缺陷，我是这样处理的：
1.对出现缺陷的情况进行截图，保留错误的信息；
2.仔细回忆刚刚造成这样缺陷的所做的操作并把开发人员叫到一起，尝试着重现这样的缺陷；
3.如果仍不能重现的话，仍需要将缺陷提到缺陷管理系统中，毕竟这个缺陷出现过，记录缺陷的详细信息，可适当将此缺陷的优先级降低；
我比较赞同楼上几位说的，当出现异常时，首先想到的是截图，把这个图给截下来，其次，把刚才具体的操作步骤回忆记下来，然后，再次按着这个步骤来操作一遍，如果不能重现，那在提交BUG时，要注明，可能再次操作时不能重现。
另外，也要试一下和这个异常相关的其他的操作，看会出现什么样的现象，也把这些问题一并提交上去。
这样可能有助于开发人员确定问题
我觉得对于一个不可重现的bug:
a.首先应该看看这个bug的severity,若是这个bug造成影响很严重,系统crash,或是软件crash了,在这种情况下,我的处理方法跟大家都差不多;
1.先回忆操作steps,做个20次边上,没碰到的话,记下了,在之后的build上做测试时.用心留意下,做相同的steps后,会不会在出现.若是一直都没出现过,就不管了.
2.就是问问跟你一块测试的同事,看看他们有没有遇到,把你操作的steps告诉他们,看他们可能遇到.
3.找类似的测试环境,包括你用的配置,用的软件,操作环境等等,在做相同的steps,大概20次边上,若没遇到的话,就不管了,
b.若是这个bug severity很低,在用户可接受的范围内,建议你别管了,不比浪费太多的时间在这方面,利用这段时间去找其他你没cover到的测试吧,提高整体效率.
原帖由 UU1983 于 2009-3-18 16:25 发表 http://bbs.51testing.com/images/common/back.gif
对于不可重现的缺陷的处理方法
1找出不可重现的原因
俗话说无风不起浪，有因必有果，既然曾经有过这样的结果肯定是有原因的，好多测试人员都把不可重现的缺陷置之不理，这些测试人员中不乏经验较多的老测试人，因为他们觉得既然不可重现何必要找呢，其实这样的想法是错误的，如果经常出现这样的问题难道你还真的置之不理吗，量变达到质变
那我们如何下手呢，有心之人可发现不可重现无非是一下几种原因
1)开发人员改的过程中出现的
由于程序的不完全，就会出现怪异的现象，这个很常见
程序的不稳定造成的，由于程序的健壮性差一会这样一会那样，也会出现
网络延迟，这也是其中的一个原因
浏览器问题，有些程序不支持多浏览器每种浏览器表现都不一样
操作系统也是原因之一
2 找到原因，记录下来进行备案，以便以后的遇到相似情况进行相应的处理
3完善的规章制度
很多时候开发人员不管测试人员是否把这个测试完毕就乱改程序，及时你找到他，他就会说我还没时间呢我不改怎么办，所以完善的制度是必然的这也是开发人员和测试人员避免冲突的好办法
唉。
都经常出现了还不可重现啊。
有心之人发现的导致不可重现BUG的原因：
程序不完全，不完全能跑吗？
程序不稳定，如果程序都不稳定了，问题是会经常出现了，复现不难。
网络延迟，这是很容易复现的。
浏览器表现不一，这是很可复现的。
操作系统？唉，不可复现BUG的原因还是交给开发人员去分析吧。测试员就不要乱琢磨了。
完善制度是立足之根本，不是用来解决不可复现问题的。
原帖由 orange_10 于 2009-3-19 17:06 发表 http://bbs.51testing.com/images/common/back.gif
OK，如果你认同以上的观点，并且重现是有必要的，就继续花力气去重现，待测代码是确定的，重现所要花费的工作量也就是覆盖率的问题了，只要你每个分支，路径都覆盖（当然这里还要考虑测试环境，测试数据和一些常量的），BUG一定可以被重现。当然不只白盒适用，黑盒也同样如此
请考虑多线程这个概念。当然，我不否认“一定”，只是最好给这个“一定”加上个期限。
