51Testing软件测试论坛

标题: 对于不可重现的缺陷如何处理？（09-3-16）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2009-3-16 15:20
标题: 对于不可重现的缺陷如何处理？（09-3-16）（获奖名单已公布）
你在测试过程中对于不可重现的缺陷如何处理？请大家畅所欲言！

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	wangjingying	当当购物卡50元	25#
二等奖	mr.bee	300论坛积分	17#
二等奖	search_happy	300论坛积分	38#
三等奖	angelna	100论坛积分	4#
	havards		8#
	zm_027		10#

作者: kesaly 时间: 2009-3-16 17:20
我对于这个问题，就是再次按着上次的步骤再试几次，如果再也不出现就只能暂时搁置，等待下次的出现~！

作者: qinxiaocang1202 时间: 2009-3-16 19:54
1、重复操作，看能否重现；
2、不能重现的问题也要记录下来，以备后用；

作者: angelna 时间: 2009-3-16 21:08
1、可以先记录问题，详细的描述下来，如果有机会，可以抓图
2、检查一切可能存在的问题，因为只有有这个BUG，一定是可以重现的，尽力的模仿当时的操作，比如点鼠标的速度，刷新速度，还有数据的填写
3、可以检查一下配置，是否自己的机子上安了什么时候软件哪些导致这个问题的出现
4、如果所有的方法都试过了，还是不能实现，哪么可以把它放到配置管理中，让它置为遗留状态，并且提交缺陷报告
5、也可以发一份邮件件给开发人员，让他帮你分析一下

作者: yhfeifei 时间: 2009-3-16 23:39
这对于测试来说是很常见的事情，如果处理不当，很容易造成产品质量事故：

1.当发现不能重现bug时，立即回忆当前经过什么操作，并马上做出记录。【这时候如果有比较深入了解系统，可能会找出原因，所以这里强调下，多思考问题的重要性】
2.在自己仍然不能重现此bug时，和身边同事（测试同事和软件开发同事）沟通下问题可能出现的原因。【和同事空闲时沟通此类bug其实是会很开心的一件事情】若还是不行，将此bug提交至缺陷管理软件（如bugfree上），将之前做的记录写上，并注明bug为偶发性问题，测试负责人及质量负责人跟踪此bug。
3.产品进入到发布之前的一段时间，回归测试时，针对不能重现的问题进行全面扫除，如再不能重现，入档，并跟踪市场反馈。

作者: kico 时间: 2009-3-17 09:40
对于所有出现的bug最好截图保存并及时和开发人员沟通
当发现bug不能再次重现时应及时补充相关问题出现的场景并提交至bug清单，反馈给开发协助其找出问题所在

作者: zynuage 时间: 2009-3-17 10:59
首先，不可重现的缺陷是非常严重的，虽然测试只在测试时出现了一次，以后有可能就再也没出现，但是不能保证该缺陷在用户手里就不出现，对于不可重现的缺陷，要看其严重性。要是非常严重，就要时时关注此问题。一般式将该缺陷的所有输入值重现筛选出来，就一定保证能重复该缺陷的。

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

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

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

作者: lisa_520 时间: 2009-3-17 13:51
我觉得作为一个测试人员，一旦发现有bug，第一反应就应该截图，并且把操作步骤记录清楚！
因为有些bug很难重现，所以在验证它是否能重现之前一定要做好相关记录。
如果当时没有记录，而缺陷又不能重现，那就和开发人员好好沟通沟通，看能否发现具体问题！

作者: zm_027 时间: 2009-3-17 14:42
1. 严格按用例执行
2. 如果是作随机测试时，把测试步骤的点进行速记
3. 偶发BUG一般都是严重的，保留现场，让开发人员一起分析留下的现场
4. 最好的做法：要求开发打开调试信息
5. 即使一时没有重现，一定也要做好记录，以便日后“偶遇”

作者: 投缘 时间: 2009-3-17 14:50
1.先把问题记录下来，排查出可能出问题的功能点或者范围；
2.找到大致功能范围，查看代码部分，看是否有逻辑问题；
3.查看此功能相关的数据库存取情况是否有异常；

作者: 投缘 时间: 2009-3-17 14:51
1.先把问题记录下来，排查出可能出问题的功能点或者范围；
2.找到大致功能范围，查看代码部分，看是否有逻辑问题；
3.查看此功能相关的数据库存取情况是否有异常；

作者: 投缘 时间: 2009-3-17 14:57
1.先把问题记录下来，排查出可能出问题的功能点或者范围；
2.找到大致功能范围，查看代码部分，看是否有逻辑问题；
3.查看此功能相关的数据库存取情况是否有异常；

作者: 小草 时间: 2009-3-17 17:44
1.如果是自己偶然发现的问题，而且自己也不能重现的话，也要记录下来，那么自己尽量要回想一下出现这个问题时，自己的操作步骤，测试版本，以及测试环境情况是什么，这些都要描述清楚。
2.这类问题要通知开发人员进行了解，圈定范围，在适当的时候进行跟踪修改。
3.如果开发人员也无法定位出原因，那么就暂时搁置，但是不要删除，在后续测试版本中，对于这类问题也要重点跟踪测试，一旦出现，要马上保留现场，及时联系开发人员进行检查。

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

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

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

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

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

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

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

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

作者: mr.bee 时间: 2009-3-18 17:00
1.尽可能的描述清楚该缺陷的重现方式，尽可可能的提供系统信息，包括相关可能的设置；
2.在缺陷管理针对不可重现的缺陷增加一个字段，方便他人查看，若再出现了不可重现的缺陷，可以通过该字段过滤查看，确认是否之前已经在被其他测试人员发现过，如果是已经发现过的，可以在原描述基础上继续补充；
3.对这些不可重现的缺陷进行过期作废的处理方式，这个可以根据测试周期进行安排，对于过期的缺陷不予以理会。

作者: vaguely 时间: 2009-3-18 17:02
我也同意对于"不可重现"的bug不必太在意！
因为危害性严重的Bug必然是可以重现的！

对于"不可重现”的Bug,我顶多会
1）自己重复多次
2）请其他测试人员重复
3）检查系统的Log，看有没有Exception出现。因为有的时候即使无法再现出错的场景，
系统也可能会产生一些Exception, 好的系统还会记录下来。

作者: black_tulip 时间: 2009-3-18 17:07
3.对这些不可重现的缺陷进行过期作废的处理方式，这个可以根据测试周期进行安排，对于过期的缺陷不予以理会。

完全赞同bee先生的这句。

作者: bht2000 时间: 2009-3-18 21:21
相信很多测试人员都遇到过不能重现的问题.既然不能重现,那接下来就是个原则态度问题:对不能重现的问题,既不能说没问题,因为问题的确发生过;又不能在这个问题上死钻牛角尖,浪费大量时间精力.
对于不可重现问题,做法通常有以下三步:
1,提交BUG相关现象描述
2,说明该BUG为不能重现
3,对该BUG不做关闭处理

作者: drwei123 时间: 2009-3-18 21:53
不可重现的原因多了去了...
有可能是当时的网络原因造成的
有可能是程序BUG
有可能是数据库问题
有可能是人为原因
有可能是IO

只有先记录下来操作流程,等手上别的工作都做完了,再来详细的发觉这个"不可重现"的问题
反复的实验,尽量的找其规律........
(等这一轮的测试结束了还未找到的话,就只有等下个版本在来回顾这个问题了)

作者: applejuzi 时间: 2009-3-18 22:38
偶在测试中经常遇到这种情况，公司是这样处理的：
看这个Bug的严重性和测试阶段，如果是在系统测试的初级，且严重性在一般以上（含一般）是要提的，把当时的环境和操作步骤详细写清楚。然后跟踪3个版本，回归时对于复现率的阶段测试的次数有所不同，一般是20次。3个版本上都没复现的话就closed

其实偶觉得这样处理也太好，因为有时候还会遇到在3个版本以后出现，这时将它reopen,开发也不太重视的。偶的想法就是一直open，直到产品上市一段时间以后closed比较合适的。

作者: wonderzzl 时间: 2009-3-19 09:38
不可重现的bug其实并不多，如果出现了，也不一定都是很严重的问题。万一出现了这样的Bug，最好还是把它先记录下来，如果在一定的时间内（比如几个月）没有再次出现，那么就认为这个bug可以关闭了。

作者: wepheloo 时间: 2009-3-19 12:53
其实不可重现的BUG比较常见,特别是在性能测试中,你用几天,一周甚至一个月来收集数据,相信大家不会为了再次证明数据是确实错误而再去运行一次的.所以此时分析就显得十分重要了.

作者: wangjingying 时间: 2009-3-19 15:18
缺陷不可重现的情况有很多种，按照我个人的工作经验和理解可以分为一下几类。
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在测试机上重现缺陷跟踪及定位。

个人看法，轻拍

作者: maguschen 时间: 2009-3-19 15:21
不可重现的BUG；大致可以分为：
1. 实在是不可重现
a. 测试人员误操作导致 -- 结束，并且在以后的工作中要注意不要犯类似的错误
b. 开发人员自己发现错误并且偷偷改正 -- 应该跟开发人员沟通好，这样偷偷改正会对测试带来一些噪声，应该避免。

2. 偶然出现，但是没有规律
a. 由于使用的被测软件版本不一导致 -- 通过改进测试流程来避免
b. 真都有BUG，但是不能100%重现 -- 尽可能地找出真正的原因，因为计算机软件的行为其实都是确定的，只是在不用的环境下（测试数据，操作系统，版本等……）下导致行为错误行为不能百分百重现。作为一个优秀的测试人员，应该努力把导致BUG出现的步骤找出来，不能说是“我现在找到个BUG，有时候出现有时候出现不了，你们自己找吧，肯定有问题的”。

总之，对于测试人员来说，发现一个偶然出现的问题，就一定要把它当作一个肯定存在的问题，然后运用自己的知识，经验，找出其中的原因，“不以恶小而为之”，放过任何一个可能存在的问题。

作者: black_tulip 时间: 2009-3-19 16:33
25楼第一名。结束。没什么好讨论的。各说各的，重复的内容也很多。几乎没有针对已有的回帖观点有评述。

作者: chengxq 时间: 2009-3-19 16:41
本公司遇到这种情况，首先是争取能够截到图，最重要的是把执行的步骤给记录下来
然后再备注重说明，大概的说明，这种情况发生的概率等等
然后让开发人员对应，开发人员当然是项目经理等对该问题进行判断

作者: orange_10 时间: 2009-3-19 17:06
首先判断该BUG的严重程度，作用不累述了

其次，积极地借鉴白盒测试的方法论，我们从代码角度去看问题。

个人见解：
其实任何BUG，只要你看到了，就不可能不能重现，只是你的输入、环境、也就是广义上的input 参数有不同而已，所以我一直不认同“不可重现的缺陷”这样的说法，最多只能说是“难以重现”

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

最后还有一种可能，就是人为的误操作，脏数据等造成的，但是运用以上的方式也是一样可以重现。

作者: maclehappy13 时间: 2009-3-19 17:48
我的建议是：
1、问题第一次出现时就问题的相关信息都记录下来并记入缺陷库（暂不提交），包括出页面截图等。
2、重现问题，如果尝试多次都重现不了则在备注里面说明，提交缺陷；
3、对不可重现的问题要持续跟踪，设定一定的级别，达到一定时间没重现，就把缺陷降一个级别再跟踪，直到问题没的级别来降。

这样做的优缺点：
1、不会错过缺陷
缺点：
1、非问题率有可能会上升

作者: lansnor 时间: 2009-3-19 17:57
根据操作步骤，多次重复执行，以确定bug是否不可重现；（执行次数固定为5或10，这样可以给出一个重现几率）
然后将bug描述记录下来，最好是附上截图或操作录像之类的文件，更加直观；
至于bug是否该修复，可先与开发人员沟通，然后再和PM沟通。

作者: strive.c 时间: 2009-3-19 18:05
1.要考虑这个BUG对系统造成影响，比如是导致系统崩溃的BUG，必定要探索测试，来定位这个BUG，要是对系统的影响不大，比如不能影响系统的整体功能，像楼上的说的就不要死钻牛角尖在这上面花费精力了。

作者: a365441258 时间: 2009-3-19 22:57
支持bht2000，因为不可重现的BUG严重性是不好判断的，2000的三不做法很有道理

作者: puchonghui 时间: 2009-3-19 23:57
根据我的体会，对于不可重现的缺陷处理不当，很多都源于绩效考核手段不当，但凡绩效考核里牵涉到bug数的，不可重现缺陷肯定是没人跟踪的。。。

其实说白了就两点：记录+跟踪
至于具体流程怎么做，各个项目组情况不同不能一概而论。

作者: szflone521 时间: 2009-3-20 00:00
我是还没入行的新人，学习学习。顶你们的肺

作者: davids 时间: 2009-3-20 10:08
是不是应该叫不易于重现的缺陷比较准确一些啊~~
一般对于这样的缺陷，我是这样处理的：
1.对出现缺陷的情况进行截图，保留错误的信息；
2.仔细回忆刚刚造成这样缺陷的所做的操作并把开发人员叫到一起，尝试着重现这样的缺陷；
3.如果仍不能重现的话，仍需要将缺陷提到缺陷管理系统中，毕竟这个缺陷出现过，记录缺陷的详细信息，可适当将此缺陷的优先级降低；

作者: navy2008 时间: 2009-3-20 10:44
我比较赞同楼上几位说的，当出现异常时，首先想到的是截图，把这个图给截下来，其次，把刚才具体的操作步骤回忆记下来，然后，再次按着这个步骤来操作一遍，如果不能重现，那在提交BUG时，要注明，可能再次操作时不能重现。
另外，也要试一下和这个异常相关的其他的操作，看会出现什么样的现象，也把这些问题一并提交上去。
这样可能有助于开发人员确定问题

作者: search_happy 时间: 2009-3-20 16:29
我觉得对于一个不可重现的bug:
a.首先应该看看这个bug的severity,若是这个bug造成影响很严重,系统crash,或是软件crash了,在这种情况下,我的处理方法跟大家都差不多;
1.先回忆操作steps,做个20次边上,没碰到的话,记下了,在之后的build上做测试时.用心留意下,做相同的steps后,会不会在出现.若是一直都没出现过,就不管了.
2.就是问问跟你一块测试的同事,看看他们有没有遇到,把你操作的steps告诉他们,看他们可能遇到.
3.找类似的测试环境,包括你用的配置,用的软件,操作环境等等,在做相同的steps,大概20次边上,若没遇到的话,就不管了,

b.若是这个bug severity很低,在用户可接受的范围内,建议你别管了,不比浪费太多的时间在这方面,利用这段时间去找其他你没cover到的测试吧,提高整体效率.

作者: black_tulip 时间: 2009-3-20 22:19

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

唉。

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

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

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

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

作者: black_tulip 时间: 2009-3-20 22:26

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

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

作者: black_tulip 时间: 2009-3-20 22:32

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

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

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

作者: dannachen 时间: 2009-3-20 23:06
除了以上大家说的：截屏，重复之前操作，记录之外，个人觉得还有一个很好的办法就是查看后台的操作日志，很可能当时后台日志也已经抛错了，那么可以让开发人员帮忙分析日志找出出错原因。

作者: achong252159676 时间: 2009-3-21 15:15
楼上的说的好，可以查看后台记录，或者其他的操作以及系统运行记录，查看是不是机器出错。

作者: coolkisses 时间: 2009-3-22 14:42
看了许多人的回复，说了不少，也分析的很到位，但觉得大部分都偏题了
个人理解，这个题目的本意是针对那些不可重现的BUG，其前提已经指定
很多人都分析了不可重现的原因，也有很多人都在分析说明测试中如何避免这种情况的发生，但真正说到点上，即，发生不可重现BUG时如何处理的人，真的很少
对此，感到非常遗憾，本来是抱着想找到对这么一个人人都会遇到问题的妥善解决道

最后说下个人理解，
不可重现BUG原则之一，不可关闭，起码在最近几个版本之内都不应关闭，最好是一直挂起状态；
原则之二，建立BUG跟踪流程，跟踪的BUG应当包括测试中不可重现的BUG，也可在测试过程不断补入新的需要跟踪的BUG，即使是已经关闭的BUG。类似于版本review吧；
原则之三，任何不可重现的BUG，都需要进行仔细分析，即使当前版本没有时间做这事，回过头来，还是需要进行仔细研究。不可重现的BUG最令人担心的不是BUG本身，而是隐藏在背后的风险，我们很可能只是偶然发现了冰山一角。

作者: 周卫 时间: 2009-3-22 22:49
1、毫无疑问，第一反应就是抓图，仔细回忆操作步骤以及操作数据，并重复操作，如果系统是基于B/S架构的软件，那么在删除COOKIES、历史记录、脱机文件等信息前后的操作有和区别
2、既然是不可重现的BUG，那么接下来在操作的过程中从价值上考虑，是否容易重现？严重与否？估量一下有什么潜在的风险？是否值得我们花大量时间让使得它重现？
3、如果有风现存在，就同身边的同事交流探讨可能的原因，再进一步检查软硬件的配置（很有可能与兼容性有关系），并且在多个不同的环境下多次操作
4、可能等到产品发布了还是不能重现的话，入档记录，并跟踪市场及时反馈

[ 本帖最后由周卫于 2009-3-22 22:53 编辑 ]

作者: mumurain 时间: 2009-3-23 10:05
看了一下各位前辈的回答，感觉和题目有点跑题，现在的问题是对于不可重现的缺陷如何处理，重点是处理上，而不是要将不可重现变成重现上
我个人观点：
1、根据记忆力，首先判断不可重现的bug是什么级别的bug，对于级别很低的bug只要记录在案，在一定时期内如果没有发现类似的问题可以忽略过去，如果级别相对较高的bug，可以记录在bug管理系统上，注明问题内容，标注偶发性，并与其他测试小组成员进行沟通
2、与研发进行交流，反馈不可重现的bug描述，在与研发的交流中，看是否能大概确定问题的范围
我大概能想到的就这么多，也请前辈们多多提出其它好的解决方法

作者: nakin 时间: 2009-3-23 13:54
对于不可重现的问题：

1.首先，一定要记录下该问题
2.尽量去重现该问题，若不能重现，可以反映给项目组，让项目组来决定该问题的处理方法

作者: jerrygu625 时间: 2009-3-23 15:19
对于半年都无法复现的可以Close掉了，没有必要再关注
有些不可会显得缺陷往往是修改了其他bug,顺带修改掉了这个bug

作者: keevinl 时间: 2009-3-23 16:48
这样的问题,可以添加缺陷库,当确认处理,以后再次出现此问题时,保留现场,待开发人员进行分析

作者: hero1796 时间: 2009-3-23 17:04
不可重现的bug通常是有操作的随机性及系统的不稳定性造成的，本身来讲属于bug，但很容易被忽视，而在软件投入使用后，形成多种多样的错误，影响非常严重，所以必须重视这类bug的产生。
比较好的做法是：

对bug进行分类统计，记录bug，分析一段时间bug的分布状态，参照历史数据，确定系统的稳定性。

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

作者: ladyjanice 时间: 2009-3-26 17:16
尽量重现，否则也要留档备用

作者: UU1983 时间: 2009-3-28 16:37
标题: 25楼的说的都是百盒
我还以为是从黑盒呢早知道不来掺和了让大家见笑

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)