偶然性不可重现BUG怎么处理？zz

songfun

一、一定要提交！！

1．  记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2．  尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3．  程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
4．  无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5．  对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。


二、程序不是测试人员写的，出问题也不是测试人员的原因。

至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。

测试人员的任务只是尽力重现问题，而不是必须重现！！


三、下次再遇到的时候，拉他们来看就可以了。

因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。

而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。 : )


四、你可以告诉程序员，测试过程是没有错误的。

测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。

需要让程序员理解，测试人员是帮助他们的，不是害他们的。

客户那里发现问题比测试员发现问题结果要严重的多。


五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。

在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。

问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。

实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现（比较严重的问题才如此处理，小问题经理之间商量商量可能就算了）。

至于测试人员必须重现bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多我能找到大概的原因，有些根本无法重现（仅仅出现一次）。

这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位（哼，程序有bug，是否可以说程序员工作不到位的呀）。


六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。

我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过，这样就避免了很多的问题。

其实只要自己尽到心就可以了，管别人怎么说呢。


七、我们使用的状态有：

程序员处理的状态（由测试员提交的Action）：等待处理的，再次出现的。

测试员处理的状态（由程序员提交的Action）：已经修改的，暂不修改的，系统限制的，使用错误的，无法再现的。测试员可以修改记录。

经理处理的状态（由测试员提交Action）：管理员处理的。经理还可以删除记录。

按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，统一使用了“等待处理的”。

最后结项的时候，缺陷的状态对我们来说有两种，“已经关闭的”（由测试员或经理确认）和“暂不修改的”（比如下一个版本处理等）。

呵呵，状态多，有些烦琐，特别是程序员很多的时候都不清楚应该回复什么状态，但我个人觉得对测试人员来说，这些状态比较清晰明了，容易处理。



八、一个叫doer_ljy(可战)的网友回复了一些内容，我个人认为不很妥当，就回复了一些内容，绿颜色的是doer_ljy(可战)的内容：


关于“无法重现”我看是有这么个问题存在。

首先如果你在测试之前有严格的测试计划，就很难出现“无法重现”这种现象。“无法重现”的意思是不知道怎么操作才能再次看见这个BUG。那么这个BUG多半是“计划外”的。

不清楚你是否是测试人员。“计划外”这个词，对测试员来说应该不存在。测试用例的粒度一直是个在讨论中的问题，测试人员很难有时间和精力写出包含内容、数据、步骤等等全部操作一切的测试用例（说白了，只要一个长手识字的人，按照测试单做，就能发现所有的问题，呵呵，有软件蓝领的感觉了）。即使真的有，意义也不大，测试很多的时候，是发散性的思维，带点创造性，想事先考虑完全，很难。所以更多时候，是在测试过程中逐步对用例等进行完善，所以说“计划外”最好不要提。

说说我现在测试的一个项目，有一个业务，首先查询出人员，有个“全选”按钮，“全选”后，再用鼠标一个一个取消选择，这个时候进行业务办理的时候，就会提示“没有选择人员”，至今为止一切都正常，但是这个时候再次点选人员进行业务处理，仍然会提示“没有选择人员”，这就是一个缺陷了。这个问题我想一般人都不会在测试用例中考虑到吧，因为发生的条件很苛刻：不用“全选”按钮的时候不会发生；全选后点击“取消全选”按钮再办理业务不会发生；全选全消后，先点击人员再办理业务也不会发生。

其次，成熟的测试人员及时无法再现BUG，也能准确的描述出BUG发生之前几个步骤的操作方法，测试用例情况。这些对开发人员分析BUG原因很重要。所谓的BUG发现环境。

呵呵，看来我不是成熟的测试人员。手工测试，比较熟练的时候，和打字可以说差不多，应该进行到哪里，心中是有数的，但让我完全从头到尾的重复，不容易呀。写测试缺陷报告单的时候，也只是说明操作步骤和发生的现象。其实无法重现的问题，既然说“无法重现”，也就是测试人员已经对这个现象进行了多次的验证，一般从程序外部来说，测试人员的操作比程序员要熟练的。

最后，我不同意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作，目标是一致的。测试人员总是处在BUG发生的第一现场，应该帮助分析出现问题的原因。确认是不是自己的此时Miss.


测试人员提交任何一个问题，都会经过反复的验证，如果容易重现，早就提出来了。绝对不是在推脱责任，还是那句话，对程序的结构，做的人当然比不做的人要清楚。另外，除非程序员询问，否则我不会给程序员提出修改分析和建议！！测试人员的任务是发现问题，解决问题是程序员的事情。这么做可能会影响程序员思考问题的思路；而且测试人员做的多了，程序员不但不感激，可能反而会反感（好像程序员对测试人员有好印象的不多）。

再说两个我这两天遇到的问题。第一个就是我们的程序有一个锁定数据的功能。锁定后，在其它的业务，此数据将不能再使用。我当时发现这个功能无效，而且经过了几次的验证都不行，我当然就提出了。但是程序员那里说此功能好使，我再验证的时候，就没有问题了，这个问题当时可以重现（但是我不可能遇到问题就拉程序员来看吧），后来却没有了，只能放在那里，最后关闭掉。第二个就是在一个界面中，录入有顺序要求，必须先选择一个ListBox（必填）再进行Edit的录入，但一次操作我没有选择 ListBox就录入的Edit，也正常保存了。后来无论我怎么操作此问题都没有出现（不够成熟呀），我就放弃了，也没有提交记录（为了避免麻烦）。

测试人员的时间是有限的，进度给的都很少，一般连用例都没有时间写，还要去花很多时间验证“无法重现”的问题？反正10分钟如果试验不出来，我就会放弃。严重的就提交，不影响的就当不知道。

下面是其它一些人的观点：

doublefalse(散诸怀抱)：如果不能重现的bug确实比较麻烦，但最好在测试过程中注意干净环境、正确的操作、相同的数据源，只要真的有问题，一定能否复现的。呵呵，多试试！！！我们以前一直有客户反映入库的数据经常有无关数据，但在家里测试没有问题，后来才发现是汉字编码错位，这样同样的字，错位后就变成另外的东西了。

liuxiaoyuzhou(蟀哥)：遇到过同样的问题!主要是记住BUG出现的环境!测试的时候这是关键!在我们这里不能从现的BUG,是测试人员的工作不到位!我们这里程序员比测试人员说话有力度!郁闷呀!

ericzhangali(另一个空间)：首先一定要提交bug；其次不要企图RD一定去解这个bug；某些时候还得关闭这个bug。如果RD认为是测试错误，（不明白什么叫测试错误，是不是说他从测时要告诉你千万不要怎么怎么做，否则后果自负啊，）那也没什么办法，如果沟通解决不了，爱咋认为就咋认为吧。

darkcat_c(错了重来)：没有bug是不可以重现的，bug本事是建立在标准的规程上所出现的异常，如果你按test case步骤做的话不太可能出现此类bug。作为测试人员一定要具备良好的记忆能力，一旦出现一些不知如何产生的bug，至少你要知道刚才你大致进行了那些操作。良好的分析能力，尽管你只是测试，但你应该全面的了解程序的架构，和一些重要的内部细节，不然你这个测试就是不合格的。定位bug是开发的事情，而重现一个bug是测试的本职工作，不要把所有的事情推给开发，不然你的确比开发要低一等。（编者按：这种话，不愿意去辩驳，标准开发人员的看法，也许应该让他们也来做做测试）

liyan_1014(雁子)：我觉得应该是这么处理：

1、一定提交bug，必须由负责bug的tester详细描述测试操作步骤，bug发生的症状，并将bug发生的具体环境也描述清楚；这样对于再次重现也有一定的参考性。

2、测试和开发之间是需要良好沟通的，如果得到的回复是操作错误，那么请开发人员解释，为什么会允许存在操作错误，一般来说，对于错误控制，开发那边应该能很好的把握。

3、沟通方面是需要方式的，开发人员对于自己完成的程序有一种满足感，一般来说是不允许别人来破坏他的这种感觉，如果沟通的时候尽可能是一种建议的形式，让开发人员自己指出自己的程序缺陷，这样对于开发人员来说是可以接受。

以上仅是个人工作中的经验，呵呵~~~~

luming

原帖在这里：http://blog.csdn.net/pyp/archive/2005/03/24/328941.aspx

掐去了头，而且没有颜色，看着可能会比较乱。

songfun

to luming：

谢谢你提供的资料，我有注明zz的字样了呵呵。
不过你自己的blog为何也要加那么多防拷贝的字符串呢？

好知识不如多共享，独乐乐不如众乐乐，你说呢？

luming

什么防copy的字符串呀，没有呀。我是在word整理后，发布在自己的blog上。

你是否说的---分----割------线------，那个是好玩的。如果你常看玄幻小说，总能看到的。

zys3497

我的做法是自己先记在本子上，备忘。记在心里。

songfun

楼上的，你这样做有问题。

没有让过程控制你。

变成了依赖于tester自身的主动性——根据tester自身素质来定，他今天要是忘记了也没辙。

不能这样！

Adrian_wangjun

liyan_1014(雁子)：我觉得应该是这么处理：

1、一定提交bug，必须由负责bug的tester详细描述测试操作步骤，bug发生的症状，并将bug发生的具体环境也描述清楚；这样对于再次重现也有一定的参考性。

2、测试和开发之间是需要良好沟通的，如果得到的回复是操作错误，那么请开发人员解释，为什么会允许存在操作错误，一般来说，对于错误控制，开发那边应该能很好的把握。

3、沟通方面是需要方式的，开发人员对于自己完成的程序有一种满足感，一般来说是不允许别人来破坏他的这种感觉，如果沟通的时候尽可能是一种建议的形式，让开发人员自己指出自己的程序缺陷，这样对于开发人员来说是可以接受。

以上仅是个人工作中的经验，呵呵~~~~


支持雁子的觀點﹐測試與開發是一種非常之微妙的關系^_^

walker_lai

有意思！

graxy

写的很好 俺们好好看

morpar82

关于这个问题我在看的过程中倒产生了另外一种想法。
很多时候不可重现的问题会出现在一种无意的状态下，比方测试点是A，但在通往A的过程中测试员可能就随意的输入数据，那么当出现和A无关的bug后，就会不知道问题出在哪里，甚至想重现都比较难。
基于这个原因，我在测试的过程中都尽量在使用固定的数据（除和测试点相关的特定数据外的），以保证万一出现不可估计的bug时能准确的回想步骤，可事实上，当很多东西被固定后，似乎也丧失了发现更多bug的机会。
通常我们会说手工测试会发现比自动化测试更多的bug时，说的不正是这种不可预计性吗？如果在手工测试的时候也固化每个步骤，是否反而不妙呢？

demonangel06

测试人员测出无法复现的问题，才到了最高的境界，哈

小猫咪咪

如果按照你认为的正确的操作步骤来走,估计发现问题的时候就是产品失败的时候了.一般都会先按照正常流程操作一次,至少一次,在使用非正常流程操作.至于一些交互的问题,当然不能说不是问题,不但是问题,而且是影响很大的问题.项目在研发的时候,一般都是按照功能模块划分.等合到一起的时候可能就会出现一些意想不到的问题,不能说这个不算问题,只能说测试不够充分.当然也不是一下子就可以考虑到的.是经验:什么是经验,错过一次,下次再看到类似的情况我都会想下会不会有这种可能性!

wuhuawu09

太长了...大概看了..谢谢

摩登口戴

很好

baizhudan

在我以前的公司，这种不能重现的bug责任都推到测试人员的头上。。。

applue

我刚加入测试这个行业，对测试不是很了解，看了后觉得测试人员还真不容易！

rlyxx2915

1.多测试几遍，也许能够发现规律，就能发现其原因，可以重现
2.也要提交，不过要注明，这是偶然出现的，不可重现，也许开发人员知道原因，不过要标明测试的环境和版本，尽量给出详细的说明
3.再遇到的时候直接给开发人员看，

bigoffer

我觉得这个作者有点挑拨测试员和开发员关系的感觉了:P

不过个人以有限的经验感觉，不可重现问题还是有些是自己操作造成的。一般我提交bug都是再三确定操作没有问题才提交的----当然对于偶尔出现的不可重现bug我还是会给开发员说，以诚恳的态度讲出来也不会遭到开发员的白眼啊~往往他们会想半天，然后给出可能的原因并留心线索。

qiqi

碰到这种问题要立刻找开发去查LOG，虽然有可能是测试人员的误操作，但也有可能是个难以发现的严重BUG！sdlkfj6

fyj123121

很是受益，解决了一些一直比较迷惑的问题，谢谢楼主，辛苦了 拜谢一下