51Testing软件测试论坛

标题: 在测试的过程中发现不了BUG是好事还是坏事 [打印本页]

作者: kason163 时间: 2007-5-17 15:03
标题: 在测试的过程中发现不了BUG是好事还是坏事
在测试的过程中发现不了BUG是好事还是坏事

作者: rovegirl 时间: 2007-5-17 15:41
发现不了BUG即不是好事，也不是坏事。
得看实际情况，有时候确实是几天也发现不了一个BUG，但前提是某系统已经运行一段时间了，或者曾经发现过很多BUG了。这种情况再去测试确定很难找。但是对于一个刚刚才做好的系统来说应该是有很多BUG等待去发现的。这时候再发现不了就是水平问题。至少现在的程序员还没有高到不留BUG的程序。
也有公司用评价测试人员发现BUG的数量来进行绩效考核，这不是很合理，所以测试人员要学会保护自己，用质量评估的手段，要对系统熟悉的程度，用和客户的关系和客户的思想及市场定位方面去保护自己。你要说出道理来，否则只能等着被BS吧。

作者: kason163 时间: 2007-5-17 15:50
一个系统已经测试很长时间，最近一段时间一直没有发现什么BUG。我在想BUG肯定是有的，但是人已经产生了惰性，那些已经被测试了无数次的问题现在已经不想再测了

作者: newtypex 时间: 2007-5-17 20:00
假如是已经测试过的，那没有BUG还是比较正常的，不过也不能因此而不去测试。毕竟有时候程序改着改着就出现新的BUG的可能性也是有的。

作者: kason163 时间: 2007-5-18 17:02

原帖由 newtypex 于 2007-5-17 20:00 发表
假如是已经测试过的，那没有BUG还是比较正常的，不过也不能因此而不去测试。毕竟有时候程序改着改着就出现新的BUG的可能性也是有的。

那么此时的测试应该如何进行呢？

作者: huash 时间: 2007-5-18 17:41
感觉二楼说的很好，支持一下

作者: newtypex 时间: 2007-5-18 20:31

原帖由 kason163 于 2007-5-18 17:02 发表

那么此时的测试应该如何进行呢？

再测一遍，没办法，回归测试本来就是测你的耐心的。。。。。。

作者: jidiangf 时间: 2007-5-20 12:34
对!就是回归测试了!

作者: babiwawa 时间: 2007-5-23 17:59
谢谢！对我起到很大的作用

作者: nsforever 时间: 2007-5-25 16:28
我是测试人员，测不出BUG里，心里说有点慌，怕是因为自己漏了哪里了。所有还是有点BUG好，不过最后一轮测完后还是不要有的好。

作者: walker1020 时间: 2007-5-26 16:42
这个是好事还是坏事，要因人而异，因测试的阶段而异。具体来说，如果一个新手测试了一个系统后告诉我，他没有发行任何Bug，那么我就会怀疑，系统是否真的没有问题了。如果是一个对系统非常熟悉的高级测试工程师经过一段时间的测试后，发送给我一份测试报告，告诉我他执行了哪些Test Case，测试了哪些Function Points，测试的结论是没有发现任何Bug，那么我会相信的。

如果在系统的代码刚刚完成，交给测试人员去测试的时候，却没有发现任何Bug，那么这本身就是有问题的。最合理的解释是Test Case不完善或者是测试人员没有认真、完整、全面地对系统进行测试。如果在经过N次回顾测试后，发现没有什么问题了，那么这是正常地。如果明天就要交付给客户了，可是今天的测试还发现有许多Bug，或者是有几个严重的Bug，那么这只能说明以前的测试流程有问题，Test Case有问题。
对于这样的问题，千万不要一概而论。

作者: walker1020 时间: 2007-5-26 16:58

原帖由 kason163 于 2007-5-17 15:50 发表
一个系统已经测试很长时间，最近一段时间一直没有发现什么BUG。我在想BUG肯定是有的，但是人已经产生了惰性，那些已经被测试了无数次的问题现在已经不想再测了

对于这种情况，你可以让测试人员进行“交叉测试”。例如，原来测试人员A一直负责测试第一个模块，B一直负责测试第二个模块，那么经过一段时间后，我就让A负责测试第二个模块，让B负责测试第一个模块。这样，既解决了这种长期测试形成的麻木和惰性以及定性思维，还可以促使他们对别的模块熟悉起来。（为了尽快熟悉别的模块，我就让他们之间进行沟通和交流。这样也利于团队的良性发展。）有的时候，测试别的模块的时候，人会不自觉地把它和以前测试的模块联系起来，这样结合起来进行测试时，通常会发现许多问题。问题常常发生在模块的接口间。

通过这种方法，我发现测试人员在测试别的模块时，几乎每次都能发现Bug。某些以前从来没有被发现的Bug都被发现了。

作者: walker1020 时间: 2007-5-26 16:59

原帖由 newtypex 于 2007-5-17 20:00 发表
假如是已经测试过的，那没有BUG还是比较正常的，不过也不能因此而不去测试。毕竟有时候程序改着改着就出现新的BUG的可能性也是有的。

微软对测试非常重视，他们发现平均每修改3或4个Bug，都会产生一个新的Bug。所以他们要求及时增加新的Test Case。

作者: lkj8168805 时间: 2007-6-12 09:14
我是一个测试新手,听了各位的见解很受益

作者: add1231 时间: 2007-6-12 13:11
继续学习中...

作者: yiyi820106 时间: 2007-6-12 13:59
关注中。。。

作者: shinerain 时间: 2007-6-14 16:45

原帖由 walker1020 于 2007-5-26 16:58 发表

对于这种情况，你可以让测试人员进行“交叉测试”。例如，原来测试人员A一直负责测试第一个模块，B一直负责测试第二个模块，那么经过一段时间后，我就让A负责测试第二个模块，让B负责测试第一个模块。这样， ...

说的很好～～学习了哈～

作者: zqp 时间: 2007-6-18 10:12
發現不了BUG,還真不說是好事還是壞事呢, 像我們這里,如果測試一段時間沒有發現BUG就會結束測試, 這常常讓我很擔心這個測試員是真的進行了比較全面的測試后沒有發現BUG呢還是隨便走了一遍呢,這確實不好說,因為不可能把每要測試的點都寫出來,一般我們只寫必測要點,和某些特殊的用例,還有就是自己現場發揮測試. 像有的測試人員就很少去做發揮性的測試...所以發現不了Bug還真不好說...

作者: yiyi820106 时间: 2007-6-19 15:26
费了好大劲才看懂楼上的字

作者: seven0918 时间: 2007-6-20 09:32
多做回归测试吧

作者: liaoyangliu 时间: 2007-6-20 12:40
受益匪淺

作者: imnleester 时间: 2007-6-20 14:34
一般情况下，我觉得BUG的状态曲线应该比较符合速的状态曲线，都没有什么太大的问题

作者: support 时间: 2007-6-23 11:18
标题: 今天你回归测试了吗?
从头在来,
1)整理业务流程,例如画出流程图,设计测试循序;主要为了避免重复测试;
2)清除数据库表,除正式上线必须保留数据以外的所有数据;
有些时候程序员往往忽略没有数据时的异常处理
3)开始测试吧~

另外再验证以往的缺陷,也许会发现些遗留问题!

[ 本帖最后由 support 于 2007-6-23 11:20 编辑 ]

作者: glf20255 时间: 2007-6-25 10:18
有道理啊，继续学习中。。。。

作者: hasis 时间: 2007-6-26 21:48
看了walker老大的评论，真的觉得学到很多东西，特别是比较系统的介绍了在公司里的测试流程。

可是在实际的公司中，好些都是以发现BUG的数量和质量作为测试人员的考核标准，如果几天都不能发现BUG，心里真的是很心虚的。而且对于一个产品而言，不可能BUG被消除，特别是新需求增加的时候，新BUG就由之产生。只有用心，能够全身心的考虑测试用例的覆盖和方法，肯定会发现BUG的。

我猜想楼主是在公司里发现BUG太少，而感觉很尴尬吧

作者: svr678 时间: 2007-6-26 23:18
无语，
培养测试人员第一关就是缺陷敏锐度的养成，通过培养基本达到发现bug速度远大于bug溯源速度，看来。。。

作者: svr678 时间: 2007-6-26 23:19
技术功底＋质疑的精神

作者: walker1020 时间: 2007-7-2 09:48

原帖由 hasis 于 2007-6-26 21:48 发表
看了walker老大的评论，真的觉得学到很多东西，特别是比较系统的介绍了在公司里的测试流程。

可是在实际的公司中，好些都是以发现BUG的数量和质量作为测试人员的考核标准，如果几天都不能发现BUG，心里真的是 ...

BUG的数量和质量可以作为考核测试人员的一个标准，但这不能是唯一的一个标准！还有沟通能力、学习能力、工作态度、合作精神等。

作者: walker1020 时间: 2007-7-2 09:54
测试人员的工作的最终目的是通过提交高质量的Bug 来提高软件的质量。如果把BUG的数量和质量可以作为考核测试人员的唯一标准，那么测试人员可能对前期出现的问题不重视，甚至会有意不去提交，然后等后期出现问题了才去提交。这样显得测试人员的工作很多。但前期的一个Bug 可能省去了后期的许多Bug，并且后期修复Bug的代价远远要比前期高，难度也会大许多！

作者: walker1020 时间: 2007-7-2 09:57
防范问题的能力远远要比提交Bug的能力重要，因为前者的效果和意义远远优于后者。个人的观点是防范问题是我测试的终极目标。防范问题里面有测试人员的功劳，也有SQA人员的功劳。

作者: deter 时间: 2007-7-2 10:59
测试不能仅仅关注发现bug啊！
受教了

作者: letfoxrush 时间: 2007-7-4 17:47
真是非常不错的讨论，难得一见的好帖子。
非常赞同walker1020大侠的说法。
对于“测试人员可能对前期出现的问题不重视，甚至会有意不去提交”，
或者可以通过对测试人员长期提交的BUG情况进行度量，把不同阶段的度量指标作为一个评价标准

作者: 风华绝代 时间: 2007-7-10 15:14
有时候一个新的系统给我，我就真的发现不了涅。
一下就蒙了。呵呵

还有一种情况是，做的软件功能很单一，比较简单。基本就没什么功能上的错误。
这种是不是正常情况啊？

作者: crystalpear 时间: 2007-7-10 17:25
我觉得除了上述大家提到,还有跟程序员也有关系,厉害的程序员写出来的程序很稳定,一般BUG会很少,粗心的程序员,即使写逻辑很简单的程序,都会发现很多BUG.

作者: 想做飞鱼 时间: 2007-7-11 10:24
标题: 恩
也有公司用评价测试人员发现BUG的数量来进行绩效考核，这不是很合理，所以测试人员要学会保护自己，用质量评估的手段，要对系统熟悉的程度，用和客户的关系和客户的思想及市场定位方面去保护自己。你要说出道理来，否则只能等着被BS吧。

这点我一定要记牢因为我有个同事他们公司就那样

作者: 想做飞鱼 时间: 2007-7-11 10:32
标题: 学习
我们公司现在的程序就是每发一个新版本就有N多BUG，必须从头测试

作者: sunbysun3721 时间: 2007-7-12 10:52
我觉的发现不了bug要根据测试人员的工作来决定。

作者: mans 时间: 2007-7-24 13:50
学习了很多...高手云集啊..

作者: charliemr 时间: 2007-7-24 21:01
这也不是什么坏事啊，这会激发你更会去努力啊。也有可能是回归测试中没有发现BUG啊，是在找不到，让同事或朋友帮你啊。

作者: alisonxmq 时间: 2007-7-25 09:01
非常同意版主的看法一般来说在测试前期肯定会发现很多问题如果没有没有找到问题除了测试用例有问题之外更重要的是可能是测试人员的工作方法或工作态度有问题如果遇到这样的问题就需要对测试人员进行指导在测试后期一般软件质量应该相对稳定一些所以发现的问题也会比较少
在这个阶段更应该认真测试多注重扩展性测试和回归测试 .如果到测试的后期仍会发现很多问题
说明测试的前期存在很多问题应该好好总结一下并进行有针对性的调整同时也要吸取教训切记！sdlkfj1

作者: leetony 时间: 2007-7-25 14:58
保持质疑的精神,坚持自己的工作,做下去,,坚持自己的立场

作者: micro_sandal 时间: 2007-7-29 10:04

原帖由 rovegirl 于 2007-5-17 15:41 发表
发现不了BUG即不是好事，也不是坏事。
得看实际情况，有时候确实是几天也发现不了一个BUG，但前提是某系统已经运行一段时间了，或者曾经发现过很多BUG了。这种情况再去测试确定很难找。但是对于一个刚刚才做好 ...

说得好，得综合起来考虑这个问题吧

作者: linqinmei 时间: 2007-7-31 18:04
如果你作为管理人员，怎么处理员工的惰性和不回归测试。

作者: antsbee 时间: 2007-8-1 00:25
有没bug的软件么?
所以没bug 在于测试这并未发现~
谈不上好和坏~~
正如 2楼所说 tester应该仔细和会自我保护~

作者: waiverson 时间: 2007-8-6 16:38
学习到了

作者: pbtlight 时间: 2007-8-6 21:09
这个还真是难说，但是如果你没有发现，被客户发现，那就不妙了

作者: luohong 时间: 2007-8-20 11:04

原帖由 kason163 于 2007-5-17 15:50 发表
一个系统已经测试很长时间，最近一段时间一直没有发现什么BUG。我在想BUG肯定是有的，但是人已经产生了惰性，那些已经被测试了无数次的问题现在已经不想再测了

同意你的说法
最好不能让我们的客户发现bug

作者: wangrong 时间: 2007-8-20 14:16
应该是好事。

作者: 海上的泡沫 时间: 2007-8-21 22:01
感觉找不到bug不是什么好事，任何软件，bug是找不完的，另外，我记得以前有人有过这样的统计，末发现的bug不会少于己发现的bug.

作者: ly_rainy 时间: 2007-8-22 17:21
反正我们现在是努力多看懂用户的需求，再跟软件模块结合起来，多运行几次用例，就好拉

作者: tingtingc 时间: 2007-8-28 20:58
事务的两面性告诉我们，无法确定判断它的好坏。必须明确一点，软件质量不是测出来的。
如果测试人员天天测到一大堆低级的bug，无疑说明软件质量太差，对开发，对测试都是坏事。首先，测试人员把大量精力放在这些重复的bug上，无法进行深层次的研究；其次，开发人员也把大量时间花在这些bug的反复修改上，也不能进行更深层次的开发。
当然，终日测不到bug,要不就是开发人员无敌，要不就是测试人员无能，其中也不排除人为因素。
很同意walk1020的观点。有经验的人，比书本知识生动多了！

作者: surace 时间: 2007-8-29 19:23
sdlkfj3 sdlkfj3
这个事情我也经常在考虑~~~作为测试新手，没有很多经验，在这边来学习了哈

作者: kellyxie 时间: 2007-8-31 08:48
标题: 技术功底＋质疑的精神+外带对需求的深度把握
技术功底＋质疑的精神+外带对需求的深度把握,不然会产生很多不必要的考虑外加争论.

作者: zhicl 时间: 2007-8-31 16:11
很多时候发现不了BUG是由于人的惯性思维跟惰性心理,
特别是小公司中程序员与测试员搭档久了,通过以往的BUG程序员很了解你的思维方式,
一个优秀的程序员在编写过程中会注意这些问题,提交前会先检查这些错误,
这时候,如果测试员再用原有的思维方式,就会发现BUG数量很少,或者发现不了;
还有一种情况是一个系统测了很久了,新版本出来,你点来点去,发现跟原来差不多,惰性上来了,
执行用例时可能就睁一只眼闭一只眼,这时就很难有突破,所以,质疑的精神非常重要

作者: owenyuan 时间: 2007-9-5 12:10
是好事

作者: owenyuan 时间: 2007-9-5 14:15
路过

作者: 51testingmm 时间: 2007-9-9 14:33
最好不要放过弱智bug啊

作者: red-hat 时间: 2007-9-11 10:28
测试中发现不了bug,肯定不是好事,否则测试就失去了它存在的意义了

作者: zhicl 时间: 2007-9-11 11:34
没有发现BUG几乎是不可能的,每一轮做回归时都会多少加一些新的BUG,有的是改动引起的,也有是前面遗漏的,隐藏较深的问题,有时发现不了问题,需求转换一下思考方式吧

作者: jiepeach 时间: 2007-9-11 15:19
标题: 回复 #5 kason163 的帖子
此时如果产品的上线测试那么你只能重新验证这个版本修复的所有bug，看有没有bug还没有修复，同时也可以发现在修复这些问题的过程中是否引起新的bug；如果不是最好是再走一遍用例。

作者: judyni 时间: 2007-9-13 10:31
对我来说~也最怕发现不了bug了~。。HOHO

作者: jimmyzhangcm33 时间: 2007-9-14 12:06
一个人和一个团队，在短期内的开发质量不会发生太大的变化
比如说千行Bug率，过往项目是一般是10个，那就不可能突然变成2 3 个，或者20个
对于工作量比较大的测试来说，这些数字统计就能反映测试工作是否到位

作者: hellen_ma 时间: 2007-9-19 11:56
发现不了BUG,心里总感觉不对.不塌实

作者: paopaolvlv 时间: 2007-9-20 09:27
发现不了BUG可能是约束于固定模式的测试用例，刚到公司还没有接触项目做模拟测试的时候，就没有按照测试用例上面来执行测试，结果发现一些以前没有发现的BUG
学到了交叉测试。。嘿嘿。。不错

作者: meijiao 时间: 2007-9-20 16:25
也有公司用评价测试人员发现BUG的数量来进行绩效考核，这不是很合理，所以测试人员要学会保护自己，用质量评估的手段，要对系统熟悉的程度，用和客户的关系和客户的思想及市场定位方面去保护自己。

很有道理，要学会保护自己

作者: firefly616 时间: 2007-9-22 11:49
发现不了bug一种情况是开发人员的确是高手，另一种情况就是测试人员写的用例质量不行。
受益匪浅！

作者: ssafa 时间: 2007-9-28 19:54
对于成熟的系统，发现不了bug是很正常的，发现bug也是很正常的。如果是一个新完成的系统，发现不了bug那就是个很严重的问题，不过如果发现太多的bug也是个问题，有可能需要修正自己的定义的bug标准。

作者: hqchen_23 时间: 2007-9-29 14:51

原帖由 风华绝代 于 2007-7-10 15:14 发表
有时候一个新的系统给我，我就真的发现不了涅。
一下就蒙了。呵呵

还有一种情况是，做的软件功能很单一，比较简单。基本就没什么功能上的错误。
这种是不是正常情况啊？

再简单的系统都不可能没有bug的,所以只要你能很好的分析,清楚的认识系统,按照需求仔细分析一定还是能找出bug的!

作者: lonewolf 时间: 2007-9-30 10:32
标题: 原因很多，看你怎么看待这事了！
原因很多，就看你想怎么样了！所以对策也很多。
如果你有了惰性，不想再测试下去了，就可以上报领导，说测试可以停止了。如果你就是不服，一定要再找出BUG，那就从测试用例，测试的人，测试时间，测试技术等方面做改进。
前者你可能要负上一些责任，你最好祈求客户那边测试不出你没测试到的BUG。后者的话，对你自己来说又是一种提高。

作者: billssong 时间: 2007-10-8 16:44
用不同的思路和方法再测试，或者再换个熟悉这个系统的人做一次测试效果会比较好

作者: dj 时间: 2007-10-10 15:59
如果只是简单的功能点测试,而且该功能是比较成熟的开发技术摸块,在测试的时候,测试不出BUG,很正常;
对于一些厉害的开发人员,在开发的时候,对系统的调试,功能点的走查,单元的测试,都做的很细,可能找出的BUG数就相对少很多;对应一个新的系统,如果开发人员写的代码,如果不是成熟的模块,在代码走查的时候,或调试的时候,很马虎,那将会产生很多漏洞和BUG
测试人员的考核,不应该以BUG数做为考核的标准

作者: sleepygirl 时间: 2007-10-15 16:06
敏锐度和耐心对于测试人员来说是相当的重要啊！呵呵！

作者: 风亦清清 时间: 2007-10-17 14:17
是否能发现bug和测试人员的经验也有关系，新手可能发现的问题都是一些显而易见的，但是有经验的测试人员，他的想法就很多，所以发现的bug也很多。

作者: julyjin_1 时间: 2007-10-18 11:48
标题: xuexi
学习一下！呵呵！

作者: clqq4 时间: 2007-10-23 16:40
恩这个不是单一的判断题好就是好坏就是坏呵呵

作者: sho166 时间: 2007-10-24 12:07
反过来讲,发现了BUG也不完全是件好事.
这根本就不应该做判断题来问啊.
要搞清楚测试人员的真正职责.发现BUG不是测试人员唯一要做的事情.

作者: yang644112 时间: 2007-10-25 15:41
回归测试重要啊，不过自动化测试此时应该发挥一下它的作用了，枯燥的测试阿

作者: hidenqin 时间: 2007-10-27 10:54
具体情况具体分析

作者: Tester_wu 时间: 2007-10-27 19:01
以发现bug数做为测试人员的绩效考核，这是现阶段绝大多数测试人员无法回避的问题。
要学会责任规避来保护自己，要对业务非常了解，当然测试技术一定要过硬，这样怀疑的目光就会少一些。怎样规避责任，最好用数据来说话。

作者: bzfyhfyh 时间: 2007-10-29 20:35
o(∩_∩)o...，受益匪浅。看来回归测试是很重要的。一定的做好了。

作者: oracletest 时间: 2007-11-2 11:13
我到是觉得是好事。发现不了BUG，我会的激情高涨。
我还没碰到过，1天一个BUG都没发现的状况。

作者: rting 时间: 2007-11-19 11:20
这个时候就是考察你的耐心的时候了
发现不聊bug。不代表没有bug
只是不那么容易发现
这个时候是最能表现一个人的能力和耐性的时候

作者: wangxuan0529 时间: 2007-11-25 21:14
在测试的过程中发现不了BUG不能马上就下结论说是好事或者坏事，因该先检查所依据的工作产品（例如：用例，分析用例设计的是否合适），如果这方面没有问题则可能是Bug达到了稳定，即在缺陷走势图中缺陷已经达到稳定，我们不可能找出所有缺陷，剩下的缺陷属于残余缺陷，这时可以向测试经理反映情况，要求停止测试。

作者: dujun 时间: 2007-11-27 11:22
这个问题还是要根据实际情况而定的。一般情况下，允许20%的bug被用户发现，但这20%的bug应该是有关界面或者是在极端条件下才会发生的，绝不能包含很严重的功能和性能上的bug，如果包含了，那么测试人员可能就得负很大的责任了。

作者: yjr2008 时间: 2007-12-2 20:16
说得很好，学到了好多

作者: yangtesting 时间: 2007-12-3 19:13
不错各位观点都好测试就是需要激情

作者: kekia 时间: 2007-12-13 17:59
学习一下，qa真是不好做啊

作者: xueva 时间: 2007-12-14 13:50
如果测试的流程管理严谨，bug虽然不可避免，但是会越来越少的，而且有严格的流程保证，测试的结果是可以进行评估的，从测试的覆盖分析可以看到的测试的充分性和完备的。case不是随便设计的，所以，如果本来很多bug却无法测试出来，不仅仅是测试工程师的水平，是process存在问题。高质量的测试不仅仅是人实现的，是依靠严格的流程出现的

作者: liucui513 时间: 2007-12-15 12:18
标题: 测试
支持二楼的说法。

没有BUG或许是系统已经正常运行，或许是测试人员的测试方法不对而没有找到BUG，因人而异，每个公司的运转也不同。

作者: sandregao 时间: 2007-12-22 23:57
感觉LS的几位分析的很透彻，确实发现不了BUG的话，也是因测试环节和测试人员各种情况而定，没有办法一定要说是好事还是坏事，需要具体情况具体分析了

作者: 测客 时间: 2007-12-25 10:18
标题: 软件是不能没有bug的
测试不能发现bug只能说明测试不是很成功，虽然测试到了后期或者甚至测试已经结束，但是测试始终都应该能发现软件的问题。。。

作者: zhan_gqian 时间: 2007-12-26 23:10
呵，大家都说得差不多啦，我也来说几句
不能光凭Bug数据来评定测试人员的绩效！
我们公司老大经常要求我们一个测试版本提100以上的Bug，如果是第1或2个版本，或许还可以，测到后来的几个版本就只有廖廖几个Bug了或者没发现Bug。。。另外，上线前的测试，要尽量测出潜在的Bug，如果这时测试还有严重的Bug的话，可就有点问题了。。。

作者: rsl887 时间: 2008-1-4 14:03
go through````gold``````````````

作者: thloong 时间: 2008-1-7 18:39
公司用评价测试人员发现BUG的数量来进行绩效考核,不可取,到最后有的测试人员会拿一些小BUG,低质量的BUG来冲数,测试员之间相互攀比,结果造成BUG质量低下,严重BUG被忽视

作者: liuxz 时间: 2008-1-9 21:26
楼主你是猛人，我从来没想过竟然还有软件没BUG ，BUG无穷无尽啊。我快要受不了了

作者: sirly2001 时间: 2008-1-11 13:43
标题: 同意二楼说的
同意二楼说的

作者: ganbadei!!! 时间: 2008-1-16 18:52
恩～～受益匪浅！！！

作者: jacky8312 时间: 2008-1-21 16:08
标题: 测试过程中发现不了BUG究竟是喜是忧?
1、开发人员水平一般，又是刚提交的新功能，如果没能测出BUG来，那我想该“忧”了
2、开发人员水平很牛，也是刚提交的新功能，如果没能测出BUG来，那就有两个极端，要么确实没有问题，要么问题是致命的，但是本着“只要是人为的肯定有漏洞”的精神，明知有，但是还找不出来，而且很可能是致命的话，那我想也该“忧”了
3、至于已经运行相当一段时间后仍没发生任何问题的话，不能说明软件已经没有BUG了，只能说它已经符合使用需要了，个人认为再投入时间、精力去回归那些可能存在的极端错误不值得，这样或可算“喜”

作者: 紫色梦幻 时间: 2008-1-28 13:22
讨论的很激烈呀,受益良多!

作者: njglman 时间: 2008-2-4 17:09
标题: 发现不了BUG不是坏事也不是好事！
需要根据具体情况，具体项目、软件成熟度来进行有效判断，我们常常感受到测试人员为找不到BUG而气馁，我认为，只要满足客户要求的测试覆盖就可以了，话虽如此，因为有很多单位BUG数量和考核绩效奖金挂钩，这样造成找不到BUG的话，会影响自己的考核！两者自相矛盾，所以我们能做的必须先学会保护好自己，凡事留证据，邮件抄送领导，与开发人员保持良好的沟通，尽可能的避免因为找不到BUG而对自己造成的伤害和损失。

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