比如说千行Bug率,过往项目是一般是10个,那就不可能突然变成2 3 个,或者20个
对于工作量比较大的测试来说,这些数字统计就能反映测试工作是否到位 发现不了BUG,心里总感觉不对.不塌实 发现不了BUG可能是约束于固定模式的测试用例,刚到公司还没有接触项目做模拟测试的时候,就没有按照测试用例上面来执行测试,结果发现一些以前没有发现的BUG
学到了交叉测试。。嘿嘿。。不错 也有公司用评价测试人员发现BUG的数量来进行绩效考核,这不是很合理,所以测试人员要学会保护自己,用质量评估的手段,要对系统熟悉的程度,用和客户的关系和客户的思想及市场定位方面去保护自己。
很有道理,要学会保护自己 发现不了bug一种情况是开发人员的确是高手,另一种情况就是测试人员写的用例质量不行。
受益匪浅! 对于成熟的系统,发现不了bug是很正常的,发现bug也是很正常的。如果是一个新完成的系统,发现不了bug那就是个很严重的问题,不过如果发现太多的bug也是个问题,有可能需要修正自己的定义的bug标准。 原帖由 风华绝代 于 2007-7-10 15:14 发表 http://bbs.51testing.com/images/common/back.gif
有时候一个新的系统给我,我就真的发现不了涅。
一下就蒙了。呵呵
还有一种情况是,做的软件功能很单一,比较简单。基本就没什么功能上的错误。
这种是不是正常情况啊?
再简单的系统都不可能没有bug的,所以只要你能很好的分析,清楚的认识系统,按照需求仔细分析一定还是能找出bug的!
原因很多,看你怎么看待这事了!
原因很多,就看你想怎么样了!所以对策也很多。如果你有了惰性,不想再测试下去了,就可以上报领导,说测试可以停止了。如果你就是不服,一定要再找出BUG,那就从测试用例,测试的人,测试时间,测试技术等方面做改进。
前者你可能要负上一些责任,你最好祈求客户那边测试不出你没测试到的BUG。后者的话,对你自己来说又是一种提高。 用不同的思路和方法再测试,或者再换个熟悉这个系统的人做一次测试效果会比较好 如果只是简单的功能点测试,而且该功能是比较成熟的开发技术摸块,在测试的时候,测试不出BUG,很正常;
对于一些厉害的开发人员,在开发的时候,对系统的调试,功能点的走查,单元的测试,都做的很细,可能找出的BUG数就相对少很多;对应一个新的系统,如果开发人员写的代码,如果不是成熟的模块,在代码走查的时候,或调试的时候,很马虎,那将会产生很多漏洞和BUG
测试人员的考核,不应该以BUG数做为考核的标准 敏锐度和耐心对于测试人员来说是相当的重要啊!呵呵!:lol 是否能发现bug和测试人员的经验也有关系,新手可能发现的问题都是一些显而易见的,但是有经验的测试人员,他的想法就很多,所以发现的bug也很多。
xuexi
学习一下!呵呵! 恩 这个不是单一的判断题 好就是好 坏就是坏 呵呵:victory: 反过来讲,发现了BUG也不完全是件好事.这根本就不应该做判断题来问啊.
要搞清楚测试人员的真正职责.发现BUG不是测试人员唯一要做的事情. 回归测试重要啊,不过 自动化测试此时应该发挥一下它的作用了,枯燥的测试阿 具体情况具体分析 以发现bug数做为测试人员的绩效考核,这是现阶段绝大多数测试人员无法回避的问题。
要学会责任规避来保护自己,要对业务非常了解,当然测试技术一定要过硬,这样怀疑的目光就会少一些。怎样规避责任,最好用数据来说话。 o(∩_∩)o...,受益匪浅。看来回归测试是很重要的。一定的做好了。