偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？

[kasad]

各位大侠：
　　偶然性不可重现BUG一般怎么处理？
　　怎样才能这种ｂｕｇ重现？

　　我们公司遇到偶然性不可重现BUG竟然视为操作错误！（无赖的苦笑）

[kasad]

解决方案一般定义那几种？

[shuibo]

以上的人，说得太好了，学习

[doer_ljy]

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

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

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

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

[pyp]

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

首先如果你在测试之前有严格的测试计划，就很难出现“无法重现”这种现象。“无法重现”的意思是不知道怎么操作才能再次看见这个BUG。那么这个BUG多半是“计划外”的。
-----------无---敌---分---割---线------------
不清楚你是否是测试人员。“计划外”的，这个对测试员来说应该不存在。测试用例的粒度一直是个在讨论中的问题，测试人员很难有时间和精力写出包含内容、数据、步骤等等全部操作一切的测试用例（说白了，只要一个识字的，按照测试单做，就能发现所有的问题，呵呵，有软件蓝领的感觉了）。即使真的有，意义也不大，测试很多的时候，是发散性的思维，带点创造性，想事先考虑完全，很难。所以更多时候，是在测试过程中逐步对用例等进行完善，所以说“计划外”最好不要提。
说说我现在测试的一个项目，有一个业务，首先查询出人员，有关“全选”按钮，“全选”后，再用鼠标一个一个取消选择，这个时候进行业务办理的时候，就会提示“没有选择人员”至今为止一切都正常。但是这个时候选择再次选择人员，再进行业务处理，仍然会提示“没有选择人员”。这个问题我想一般人都不会在测试用例中写吧，因为发生的条件很苛刻：不用全选的时候不会发生；全选后点击“取消全选”按钮也不会发生；全选后，先点击人员再办理业务也不会发生。


其次，成熟的测试人员及时无法再现BUG，也能准确的描述出BUG发生之前几个步骤的操作方法，测试用例情况。这些对开发人员分析BUG原因很重要。所谓的BUG发现环境。
－－－－－－－我－－又－－出－－来－－了－－－－－－－
呵呵，看来我不是成熟的测试人员。手工测试，比较熟练的时候，和打字可以说差不多，应该进行到哪里，心中是有数的，但让我完全从头到尾的重复，不容易呀。写测试缺陷报告单的时候，也只是说明操作步骤和发生的现象。其实无法重现的问题，既然说“无法重现”，也就是测试人员已经对这个现象进行了多次的验证，一般从程序外部来说，测试人员的操作比程序员要熟练的。



最后，我不同意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作，目标是一致的。测试人员总是处在BUG发生的第一现场，应该帮助分析出现问题的原因。确认是不是自己的此时Miss.
－－－－－－－－－还－－－－－是－－－－－我－－－－－－－－
测试人员提交任何一个问题，都会经过反复的验证，如果容易重现，早就提出来了。绝对不是在推脱责任，还是那句话，对程序的结构，做的人比不做的人当然要清楚。另外，除非程序员询问，否则我不会给程序员提出修改分析和建议！！测试人员的任务是发现问题，解决问题是程序员的事情，这么做可能会影响程序员思考问题的思路；而且测试人员做的多了，程序员不但不感激，可能反而会反感（好像程序员对测试人员有好印象的不多）。
在说两个我这两天遇到的问题。第一个就是我们的程序有一个锁定数据的功能。锁定后，在其它的业务，此数据将不能再使用。我当时发现这个功能无效，而且经过了几次的验证都不行，我当然就提出了，但是程序员那里说此功能好使，我再验证的时候，就没有问题了，这个问题当时可以重现（但是我不可能遇到问题就拉程序员来看吧），后来却没有了，只能放在那里，最后关闭掉。第二个就是在一个界面中，录入有顺序要求，必须先选择一个ListBox（必填）再进行Edit的录入，但一次操作我没有选择ListBox就录入的Edit，也正常保存了。后来无论我怎么操作此问题都没有出现（不够成熟呀），我就放弃了，也没有提交记录（为了避免麻烦）。
测试人员的时间是有限的，进度给的都很少，一般连用例都没有时间写，还要去花很多时间发现“无法重现”的问题？反正10分钟如果试验不出来，我就会放弃。严重的就提交，不影响的就放弃。

[kasad]

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


这个和我们公司的差不多
根本就没有正规的测试文档可依
完全靠测试人员测试时候发挥。

[Iris]

我觉得应该是这么处理：
1、一定提交bug，必须由负责bug的tester详细描述测试操作步骤，bug发生的症状，并将bug发生的具体环境也描述清楚；这样对于再次重现也有一定的参考性。
2、测试和开发之间是需要良好沟通的，如果得到的回复是操作错误，那么请开发人员解释，为什么会允许存在操作错误，一般来说，对于错误控制，开发那边应该能很好的把握。
3、沟通方面是需要方式的，开发人员对于自己完成的程序有一种满足感，一般来说是不允许别人来破坏他的这种感觉，如果沟通的时候尽可能是一种建议的形式，让开发人员自己指出自己的程序缺陷，这样对于开发人员来说是可以接受。
以上仅是个人工作中的经验，呵呵~~~~

[kasad]

你们都说的很有道理，但在我们部门还是不行，测试工作还很不完善，对测试也不怎么重视。

我们的测试文档都是很简单，都没有具体的ｔｅｓｔ　ｃａｓｅ

我们测试环境有时被用来做编译环境，有时同样的步骤，不能使ｂｕｇ重现。

[loveisbug]

测试环境并不干净

[wzb99447227]

用上测试管理工具，他们不认为是BUG的，可以作废掉，至少这是你的劳动成果。

[kasad]

谢谢各位！！！

[kasad]

呵呵
本来想给各位加多些分
发现最高只能是100
ｓｏｒｒｙ
下次给大家多一些！！

[doer_ljy]

呵呵，本来已经是结过贴的了。
不过我看PYP好像意见挺大，交流一下。
测试没做多长时间一年多的测试负责人吧，后面就是项目控制的时候做过结合测试。肯定不如你经验丰富。
我们这里所有的测试都要有文档，测试数据。
我不是贬低你的工作，可是你那样实在没有效率。也没有办法很好的保证程序的质量。
也许我太理论化了，不过几十个人合作没有文档简直是灾难。这一点却深有体会。
同时，我不喜欢你的工作态度。这样好像没有办法让别人信任你的工作结果。
不过你说的测试时间不足等等，确实存在。有时会很严重。
但这个问题可能是你们PM需要解决的吧。
在时间紧的时候有些做法可以谅解，但是不能拿出来作为理论讨论是吧？

[pyp]

理论是理论，实际是实际，理论方面我看的应该也不少了。
我做测试3年多了，原先每个月都基本会去买测试的书籍，多了不敢说，市面上一半以上关于测试的书都看过了还是敢说的。
还有各个测试论坛也常去，都是中文的，我的E文不是很好。
但大家说的都很好听，如果想，我也可以去说很多这样的理论，但实际至少在我们这里用不上。
所以我这里说的只是经验而不是理论。
虽然你做过测试，但看来对测试你并不很满意，否则就不应该用那种口气说话。
你可以把你的话发到51testing去，看看是否有测试人员会满意。
不清楚你说的测试文档和测试数据说的是什么，即使再好的文档和数据，也只能起一个指导的作用，真正发现问题的还是干活的人。
对测试人员的尊重是最基本的，但在你的话中我实在无法看到，也许做领导的和干活的是不同的想法和侧重点吧。
我并不认为我的观点和想法有什么问题，文档我也写，测试计划是我们经理写，但用例和总结基本都是我写以后我们经理进行确认。
也许是因为我们的规模小，所以并不很正规，但实际就是实际，我不会用好听的理论去告诉别人，我只会说我的经验而已。
就是这样。

[pyp]

对于测试人员辅助开发的想法，一直都存在，最新的《测试员》上面也说到了这个问题（不知道你是否还做测试工作，如果还在做，可以看看这电子杂志）。

我个人不是很赞同这种观点，本来也想写东西进行反驳，但后来看到有人说的已经很好了，下面是一位叫“叶子”的朋友的回复，观点我完全赞同。

“非常赞同前面“不要给开发建议怎么改错来限制他的思路”
这个很重要，而且，实际中也碰到一些，毕竟测试人员对程序构架及内部结构没有开发人员那么熟悉，比较有深度或关联比较复杂的bug，测试人员其实是很难定位到的，而测试人员能够定位到的，也不过是些相对独立或简单的问题，而这些问题开发人员是很容易定位到的。（这并不强调测试人员水平不如开发人员，只是强调，测试人员对内部结构和关联并不清楚），所以并没有起到太多作用。这样做除了限制开发人员的思路，还有比较大的一个负面效果是：容易引起开发人员的反感-------他会觉得你有点指手划脚的意思，当然如果某次定位正确了，他没什么话说，但如果一旦定位错了，他就有我刚才提到的想法了，几次不正确的定位描述下来，很容易降低开发人员对测试人员的重视和信任。
也有同学说，开发，测试是一个整体，应该协调合作，不分彼此。。。。。这话我觉得对一半，错一半，作为一个项目团队来说，的确是一个整体的，需要协调合作，但并不意味着就不分彼此，否则也就不用分职责分类了，所谓的协调合作应该是各尽其责任，而不是不分彼此。虽然目的一样，但责任还是不一样的，工作重点也是不同的。---------为了累计经验，比较有意思的bug，测试人员自己可以定位，自己记录，等开发人员回复之后，看看跟自己当初的想法是否一样，长期积累，也许以后碰到类似的问题就可以提点有建设性的意见了，也能让别人信服。所以我的建议是不太确定的就不要轻易给定位了，如果能明确当然定位最好了。

无需定位问题，并不等于测试人员发现问题就一锅端上去，描述也不是越多越好，有时候可能操作很多步骤或输入很多内容后出现某个bug，但真正引起bug的却只是其中一步和一项内容不对，测试人员要做的应该是，尽量精炼步骤和输入内容，找出那一条，精准描述问题是对开发人员最好的帮助。”

[doer_ljy]

首先祝贺你升星星，然后生命一下我对测试的态度。我自认从未对测试工作有过任何偏见。不止我的发言中哪一点让你觉得“看来对测试你并不很满意”。我觉得这里面有一个问题，就是看问题的角度。从工程的角度（我在这里说的也是经验，既然你并不喜欢谈理论，我也不再谈理论。虽然我一直认为理论不一定都是无聊的人编出来骗人的），任何一个项目管理者都虚妄自己的项目是：有序的、易于调整的、可评估的。这首先需要项目进行的计划足够细化，这个细化的程度，我个人认为是一个最小的可评估单位。一个项目经过几次划分，最终成为若干个这样的单位。对于每个单位，我们有它的设计者、实现者、质量保障者。他们各司其职，但协同工作。那我我们如何保证“质量保障者”的工作质量呢？从项目管理者的角度，两点：一、他必须有完备的测试计划（这里包括测试者自己编制的、以及从设计者那里引用的若干文档）。二、他要有准确的测试实施报告。这两份东西都是可以评估的，同时具有责任的约束力。你提到的前面提到过测试人员自己的发挥，我的感觉很有效但是不保险。也就是说我不能靠测试人员的即兴发挥来保证我的系统的质量和稳定性。因为里面有太多的不确定性。比如测试者经验会参差不齐，比如他们的技术能力和对BUG的预见能力不一样，甚至他们的心情等等。我相信他们能做好，但是这不能作为我保证自己系统质量的手段。

[doer_ljy]

写到这里我忽然有点明白PYP老师为何觉得我“不尊重”测试者了。的确，我的口气可能有点重了，但是不是对测试者而是对软件工程（这里不是指软件工程理论，而是指它本身）不重视的人。任何事情，想要完成好必然要有他一套成型的方法和思路。不只是软件测试，简单一点的一块饼干我们测试质量是否合格首先要做什么？无论是厂家还是食品监督局，他们检验者块并盖有有自己的标准和检验流程。你说他们是通过流程和方法来保证的质量还是通过人来把握的质量？对于一个工程，我们要努力作的是弱化个人在其中的作用，而强调团队和科学管理。我们中国软件业铺天盖地，却难成大气跟这个很有关系。谁都喜欢英雄力挽狂澜，但是在“没有英雄的年代”我们不是还得好好的活下去嘛。

[doer_ljy]

然后关于“辅助开发的想法”的问题，我觉得可能是个误会。你说得挺好，我觉得也是应该做到那一步就足够了。我觉得让测试人员帮开发人员发现“BUG是在那句代码里出现的”这事儿是万万不能的。毕竟大家各司其职。如你所说的，提供线索也就足够了！

最后，有个有点失礼的问题：你所在的公司对测试人员是怎么看的呢？

我先说我们公司，项目组中测试人员有统一的专注测试的leader，他们只对测试Leader和自己负责的程序负责，不受开发组的任何“领导”指挥。在选人上，基本用两种人：1、“工作仔细”，这是女生的特性。2、思维严谨，有时候是技术也要比较好的。所以，没有人“瞧不起”测试工作和作测试的人。

[pyp]

首先说明，我绝对不是什么老师，没有做过领导，一直都是工作在第一线的小兵兵。

我做测试也三年多了，从工作就开始做测试，做到现在。理论我一向都很关注，所以市面上有什么测试书籍，我都会买来看，网上的测试资料和测试论坛也每天都要看的，测试有什么新东西我想第一时间我就会去注意。

现在我发现自己到了一个瓶颈，工作成为了一种习惯，很久没有太大的提高。所以才努力的总结自己已有的经验，希望能找到一条出路。

你说项目管理者希望项目是有序的、易于调整的、可评估的。但这些对需求、设计、编码阶段都比较容易，到测试这一块，却容易发生一些问题。

说说测试的一些事情。按照习惯上的测试理论，测试应该早期介入软件开发过程，并进行详细的测试计划和写测试用例。这里其实隐含这很多的东西，主要是人力、时间还有开发流程的问题。

好像国外的大公司，对测试比较的重视，测试和开发的比例都很高，当然了，他们的测试要深入代码级，所以需要的人也多一些。现在国内测试和开发的比例能有1：10我想就很不容易了，而且测试需要有小组的形式，单人做的效果和效率都不一定太好，所以一般正规点的测试都独立于开发。我想这是一个基本的共识。这样实际涉及项目组间配合的问题，现在国内的测试部门，由于水平能力等关系，实际大部分都在黑盒阶段。这样如果要写测试用例，就必须需要想当长的时间和详细的文档。我想没有文档，光想像软件会是什么样子，应该没有人能写出测试用例来的吧。特别是详细的带数据的测试用例。

这样就涉及到一个前期文档的问题。现在中国的软件工程程度，我想做过开发的都知道，文档在哪里？？在程序员的脑子里。很遗憾的是，测试人员无法把程序员的脑子橇开看里面到底有什么，也许程序员在没有开发出来之前，对程序本身也可能只有一个模糊的印象而已。在这种情况下，要求测试人员写用例，好像困难些了吧。

这样一般来说，用例的编写就需要在程序开发到差不多的时候进行。现在开发的产品，实际时间都不多，3个月、半年，能成年的软件很少吧。除去需求、设计，给程序员写代码的时间都不多，留给测试人员的时间能有多少呢？

真正详细的测试用例，写几万条是很正常不过的事情，因为要覆盖很多的情况（写过一次，3个月，4个人，总共2万多条）。但这样的一个问题就是需要很多的人去写，周期也比较长，还需要花很多的时间维护（需求变动、程序修改，用例可能也要修改，而且可能几百上千的修改用例，很容易进去几个工作日），这些人和时间去哪里找？

当然了，我不否认有做的好的公司，大家的文档都做的很好，测试人员很早就可以进入，很早就可以规划和写用例，但我想这样的公司应该是凤毛麟角吧。

现在软件工程的一个趋势其实是弱化文档，比如XP，追求快速开发，对编码有利，到测试这里是很麻烦的。

我同意一种观点，做到最后，应该是不需要测试，也就是说，程序本身没有问题，问题的关键在业务流程上，换句话，测试最后需要的是业务专家，而不是测试人员。但现在至少我测试过的程序还无法达到这种程序，软件本身的问题还是成堆，所以还是需要我们测试员的。

在现阶段，可度量的测试过程还很不容易，因为无法用bug数去考核测试人员，测试用例也不可取，因为要评审，所以会很麻烦。

你的观点我明白，像CMM一样，弱化人，强化流程和管理，一切要求可控。但实际执行太不容易了。

我们公司是CMM2，测试部门是完全独立的，很独立很独立的那种。我们公司的集团下面分为两个公司，测试部有两个部分，软件测试和硬件测试，分属两个公司，但是都是一个经理在领导。我们软件测试这边，算上我们经理4个人，一般大的程序给的测试时间是2周左右，小的就2、3天，嗯，测试都不够（因为要算上提交缺陷、修改、再验证等时间），所以用例有时间就去补，没有时间就算了。写了也是很简单的，可以说只是测试思路和流程而算不上具体的用例。可以看看这个帖子，就知道我的工作大概是什么样子的了。http://community.csdn.net/Expert/TopicView3.asp?id=3671025

我们的人么，呵呵，1个原先做配置管理、1个原先做QA的，所以小活一般都我自己做了，也有人多的时候，但公司给的money太少（500～700），全部跑掉了。

对于测试，我认为男女不重要，最关键的是想做测试。现在测试待遇不很好，所以很少想做测试的人。只要有心做测试，所有的都可以学习，不会有什么问题。

[pyp]

实际上，我想国内大部分的公司都处于我们公司的阶段甚至更低，至少我们公司过了CMM2，至少有独立的测试部门。
规范的公司，还是比较少的，一般对外的公司比较的规范，所以才可以施行CMM等比较大的软件工程。
另外说一句，我们有的时候会发测试不通过的报告给他们，至于他们如何处理，我们测试部就无法掌控了。
还有一点，硬件和软件的规则不同，他们的经理认为程序不应该有任何的错误（也许硬件的理念就是这样），所以测试硬件部分附带软件的时候，比测试纯软件轻松的多，一是程序都比较简单，二是他们不敢不修改程序，呵呵，哪怕一个轻微的错误，他们经理也要开会让他们解释，所以一般小问题不好解决的我们都帮他们隐瞒。
据说在我们公司过CMM的时候，有质量保证部门，但我来的比较晚，等我到公司的时候，因为种种原因，质保部门解散了，所以现在公司都是项目组独立，没人负责流程，只要到时候把程序做出来就ok了，测试部只是一个最后把关的作用而已。
中国的测试，任重而道远，我在北方一个中型城市，和北京、上海、深圳等无法相比。
我只能在可能的范围内做好自己的工作。

[doer_ljy]

个人原因，久未能上线。
看了你提到的帖子，发现我的认识确实以偏概全。不过我想你我可能都是从自己所在的为基准看待这个问题的。最多加上我们身边的一些公司。所以，不能代表全部的情况。
说说我所在公司的情况吧，客户往往是外国人他们不但会要求提交完整的代码。也会要求提供完整的文档。当然包括测试用例和测试结果报告，有时甚至是每一张BUG票。所以我们在座项目安排的时候都给测试留有相对充分的时间，所以我认为测试是可以XXXX样的。但是看了你的工作状况，我发现这个想法确实有点偏颇。实际上，我所做过的项目很少站对国内，不过我想在理论与实践的结合上。我们还应该有探讨的余地。
很多时候我都提到了领导对测试工作的认识。为什么要提这个，因为这个决定了测试工作的可利用资源的厚薄。这个不是一个测试者自己利用自身的技术理论能力所能解决的。我们打个比方吧，一座大楼的质量控制：当你发现地基不牢的时候，像盖楼的资方（我们的boss）提出，这个楼的地基不牢，以后会出问题。结果她不以为然。然后根据你说“你不是搞质量检验的吗？楼盖好了再来吧”。OK，楼盖好了，你来了，被告知随便看看，给你一天的时间。我要验收合格的报告（呵呵，说实话归根到你你干提交一份测试不合格的报告吗？）。你能怎样，纵你三头六臂你又能怎样？没有办法，还是那句话测试是一个系统工程，应该和软件开发的过程有机的融合起来。这需要上至PM下到testor都对测试工作有一个全面的认识才可以。所以，你说的"实际当中很难实现"我能明白。
最后谈点感想，随着中国软件开发能力的提高和规模的扩大。很多公司的已经开始对QA的重要性有所认识，并逐渐重视。我还是觉得这条路走下去，最终会走到测试理论中描述的那样。当然会比理论灵活和复杂的多。