BUG的用例发现率 是怎么计算出来的？？？
表3-1 测试数据覆盖率与BUG发现率对应表模块名称 功能点数 测试数据数 测试数据覆盖率 BUG的用例发现率()
模块AA 6个 75组 12.5组/每功能点 40% (6/15)
模块BB 30个 96组 3.3组/每功能点 17% (7/42)
模块CC 15个 87组 5.1组/每功能点 18% (5/28)
模块DD 16个 46组 2.8组/每功能点 23% (5/22)
回复 3# 的帖子
貌似BUG的用例发现率还是蛮有用的吧1、测试人员考核得用它吧，谁写的用例好不是靠嘴说的，得拿数据说话。
2、用例文档变更得用它吧，比如LZ的数据，B、C两个模块的用例质量肯定有问题，不修改基本就当摆设了。
3、下一个周期的测试重点指导得用它吧，覆盖率低的地方，得重点照顾哈吧。 貌似BUG的用例发现率还是蛮有用的吧
你是版主，别貌似。我可以，你不可以。嘿嘿开个玩笑别生气呵呵
1、测试人员考核得用它吧，谁写的用例好不是靠嘴说的，得拿数据说话。
玩人吧？让你写用例的模块只有1个功能。你写吧，恰巧这一个模块没有问题。我拿这个东西考核你，你干吗？估计早就砸我家玻璃去了。
2、用例文档变更得用它吧，比如LZ的数据，B、C两个模块的用例质量肯定有问题，不修改基本就当摆设了。
楼上咋分析出来的B，C两个模块的测试用例质量有问题？能给个依据不的？考虑到功能复杂度、BUG严重等级、开发人员水平如何（还有很多，不列举了）没？
3、下一个周期的测试重点指导得用它吧，覆盖率低的地方，得重点照顾哈吧。
弱弱的问一下，这个貌似和测试用例的BUG发现率没关系吧？
[ 本帖最后由 47385024 于 2010-6-11 19:05 编辑 ] 呵呵，是俺不明白，你咋老抬俺的杠那……::tuxue:::
楼上，你应该做测试控制也有一段时间了，怎么对用例发现率的使用这么生疏呢？
以后不明白的东西要虚心请教，态度要改改。俺就再破例一次，下次你这种态度俺就不回答了……::jian:::
1、测试人员考核得用它吧，谁写的用例好不是靠嘴说的，得拿数据说话。
玩人吧？让你写用例的模块只有1个功能。你写吧，恰巧这一个模块没有问题。我拿这个东西考核你，你干吗？估计早就砸我家玻璃去了。
俺不清楚你们公司是怎么做测试员绩效考核的，你们公司在各个测试阶段用的都是同一种标准考核员工？::tuxue::: 不知道你们对工作任务完成质量是怎么理解？
在测试整个周期中，由于各个阶段的主要任务不同，自然考核的主要参数也不同。
选择Bug的用例发现率作为测试员在设计用例阶段的主要考核参数，则是根据当前周期的主要工作重心决定的。测试员在那段时间的工作成果就是用例，而用例好坏则表明了各人的工作业绩。
至于你列举的那个例子，虽然是个个例，我还是解释一下吧。团队中每个人负责的工作量基本是相等的（当然，如果你非得说你们的TL是很烂，不会提前估算工作量或估不准的话，俺实在没则了::tuxue::: ）。如果出现测试员A负责的是只有一个简单功能模块的情况，那其他人估计也差不多，所以A并没有在考核中占便宜。
2、用例文档变更得用它吧，比如LZ的数据，B、C两个模块的用例质量肯定有问题，不修改基本就当摆设了。
楼上咋分析出来的B，C两个模块的测试用例质量有问题？能给个依据不的？考虑到功能复杂度、BUG严重等级、开发人员水平如何（还有很多，不列举了）没？
首先，用例的发现率与功能复杂度、BUG严重等级、开发人员水平关系不大。你列举的这几点都不是用例发现率低的理由。
唯一关联较大的是需求。前期需求不清晰或执行阶段需求频繁变更才是可能导致用例发现率数据出现严重偏差的因素。这个又得关联到TL的能力了，主要是需求分析阶段的各种问题，又是一大篇东西了，所以就不纠结了。
当然，如果到了贝塔测试阶段，只使用了部分测试用例而导致用例发现率偏低，是完全正常的。
而你所说的标准，我可以提供给你两个数据：
MS的黑盒测试Bug用例发现率超过了60%，NOkia超过了40%，即使Nokia在贝塔测试阶段黑盒测试bug覆盖率也能达到10%以上（贝塔测试用例数不到阿尔法测试的1/60）。看看别人，就能知道自己应该达到什么水平了。当然，如果愿意止步不前，俺也是没办法啊。
再看看LZ的Bug的用例发现率，bug越多的模块数据越低。
而bug多可能因素：
1、功能复杂：越是复杂的模块，用例设计用越不容马虎，只能用更多的用例来覆盖需求，不然真的打算考执行阶段测试人员的临场发挥来决定测试力度？
2、开发人员差：测试实体质量差貌似和是否在bug出现路径上提前设置用例没有多大关系吧。
3、无大bug,小bug多：用例设计的初衷不是只为了找出所有的严重Bug.在设计用例时，目标应该是直指所有bug吧。
本来在下LZ用例存在的问题的结论时，应该假设一下他们的需求存在问题。
不过在分析了另外一个数据后，我认为没有假设这个必要了。
在LZ提供的测试用例覆盖率中，除D组外，其他3组的用例覆盖率与用例发现率均成正，也就是说，由于B.C每组功能点设计的用例少，则发现率低。
出现这样的情况，肯定就需要找问题了，而找问题从哪里入手？第一步不就是重新评审测试用例吗？既然这样，先给它扣个“差”的帽子又如何？反正得一个环节一个环节查，执行之前总得有个“由头”吧。
而针对于D组，我则认为：设计D组用例的测试员设计用例水平可能高于B.C组（或单纯的只是运气好，这需要结合他们的团队实际情况了）。
所以，我只下了B、C组有问题的结论，无非是B/C组用例出现问题的几率较大而已。
3、下一个周期的测试重点指导得用它吧，覆盖率低的地方，得重点照顾哈吧。
弱弱的问一下，这个貌似和测试用例的BUG发现率没关系吧？
用例发现率与Bug数都是支撑测试实体当前质量的一项指标。
当某个模块用例发现率偏低，很大程度上是由于采用了用例以外的测试方法，而且这种方法还真的体现了它的效果。
那么在下一个周期，我们是否应该将这种方法规范，然后完整的利用这种方法测试一次呢？
举个简单例子，A模块没有在用例中考虑使用边界值。而在执行测试的某一个周期中，使用边界值测出了不少bug，导致A模块用例发现率降低，那么在下一个周期中，我们必然会在A模块的全部功能中都使用边界值测试一次。当然，首先得重新设计A模块的边界值测试用例了。
[ 本帖最后由 Jackc 于 2010-6-18 17:59 编辑 ] 呵呵，是俺不明白，你咋老抬俺的杠那……
完了又生气了不是 都说了和你开玩笑的么 那下次我不开了好不 消消火
真不是诚心和你抬杠的 讨论问题就是讨论问题呵呵别动那么大肝火
以后不明白的东西要虚心请教，态度要改改。俺就再破例一次，下次你这种态度俺就不回答了……
晕了老大我没点名要你回答啊表冤枉偶不过你回答了我还是很高兴谢谢你指正呵呵 ::2ku:::
你看哈我说出我的想法然后呢不对的地方还请拍砖哈咱们继续讨论吧
我只是觉得用这种东西来对一个测试人员进行评估多多少少会有失公允。
我举个例子：
1个测试组有2个成员（少了一点，就先说2个吧），每个测试成员分别负责一个项目（估计这个现象应该还算是好一点的，因为很多的时候1个测试人员可能会同时负责2-3个项目）。这2个项目我们就叫做A项目和B项目吧。
A项目：
模块数量：2个
人员配备：5年以上经验开发人员1个
项目复杂程度：简单（你喜欢叫程序或者其他的复杂程度也可以呵呵）
B项目：
模块数量：5个
人员配备：5年以上经验开发人员1个，实习生2个
项目复杂程度：复杂（你喜欢叫程序或者其他的复杂程度也可以呵呵）
2个测试人员分别负责其中一个项目，那么到年底了，你觉得可以用用例发现率来对2个测试人员的工作成绩或者是个人能力进行评估吗？如果测试人员碰到了一个技术很牛的开发人员，不得郁闷的撞墙么？
我觉得BUG的产生和发现，与功能复杂、开发人员水平这些因素关系很大。你看哈，如果程序的功能复杂，再加上开发人员水平不高，出现BUG的几率就应该相当的大，是吧。相反，如果模块功能特别的简单，碰巧开发人员水平还过得去。你认为你会在这个项目中发现多少个BUG呢？即使是同一个模块，由2个开发人员来做，出现的BUG情况也会不同的。当然了，一定要排除hello world呵呵
bug多可能因素：
1、功能复杂：越是复杂的模块，用例设计用越不容马虎，只能用更多的用例来覆盖需求，不然真的打算考执行阶段测试人员的临场发挥来决定测试力度？
2、开发人员差：测试实体质量差貌似和是否在bug出现路径上提前设置用例没有多大关系吧。
3、无大bug,小bug多：用例设计的初衷不是只为了找出所有的严重Bug.在设计用例时，目标应该是直指所有bug吧。
其实你已经在帮我说明这个问题了 是吧呵呵
测试覆盖率并不能代表BUG发现率，理由同上。因为在做测试用例的时候，用例覆盖所有需求是必须的。也可以把他理解成为前提条件。如果说用测试覆盖率去衡量测试人员的能力或者说是工作态度，我觉得还是可以的。最起码别人这么评估我的时候我可以接受。
如果说，你把这种测试人员发现的BUG和客户反馈的BUG一起做分析。我觉得如果是这样的话，就非常有必要了。为什么客户可以发现，测试人员没有发现。是什么原因导致的？下次我们如何进行改进。我觉得这样应该才是有价值的。还有一种分析是有价值的，就是对整个生命周期所产生的BUG进行对比分析。举个例子吧。我们在需求阶段发现了10个BUG，在设计阶段发现了20个BUG，在编码阶段发现了20个BUG，在系统测试阶段发现了50个BUG，在验收测试阶段发现了5个BUG（或者是按单元、集成、系统、验收这样的阶段来采集数据）。我觉得，按这样的方式去统计BUG的发现率也是非常有价值的。但是我不清楚国内有多少公司可以真正的做到这点。
如果单纯的从测试这个层面来做BUG的发现率统计，我觉得意义应该是不大的。
如果单纯的仅仅靠BUG发现率来去衡量一个测试人员的工作绩效，我觉得实在有点说不过去，因为我觉得只要是能在测试这个行业是干上个1年2年的人，都应该是那种责任心非常大的人。这么衡量很容易给测试人员造成消极心理。
老大我没做过测试控制 目前就是一个小tester。
想说的就这些了呵呵哪里说的不对请指正呵呵 放心这次绝不乱丢鸡蛋了好吧::xykwd:::
[ 本帖最后由 47385024 于 2010-6-18 18:46 编辑 ] 我觉得我真的很苦啊，本来1百来字就说完的东西，要是细说，上面那堆写完后，其实问题都还没涵盖住。
哎，测试嘛，点到为止，自己体会才是根本撒~
回复 7# 的帖子
对了，请教个问题同年同职位的纯QTP的测试待遇相比一般黑盒的待遇多几个点？
QTP的TL与普通TL的比呢？ 晕老大我不了解行情啊 刚进公司的时候 1K多就把自己卖了::aida:::
你有QQ吗我加你QQ吧以后有啥不懂的我好问问你别嫌烦就好 呵呵 A项目：
模块数量：2个
人员配备：5年以上经验开发人员1个
项目复杂程度：简单（你喜欢叫程序或者其他的复杂程度也可以呵呵）
B项目：
模块数量：5个
人员配备：5年以上经验开发人员1个，实习生2个
项目复杂程度：复杂（你喜欢叫程序或者其他的复杂程度也可以呵呵）
针对于这个例子，其实你对考核的纠结处在于B项目可能出较多的bug,而且由于新人开发加入的缘故，可能导致一些不可预料的Bug，所以这样对测试B项目的测试人员就有些吃亏吧？
其实影响并没有那么大了。Bug数对bug发现率不存在直接的引导，因为bug发现率=用例发现数/bug总数。bug总数上升，只要用例发现数上升就能保证发现率了。
举个例子，同样进行“启动”操作，A项目在欢迎界面出现一个小的UIBug。而B项目则出现3个不同程度的Bug.是否就能说明B项目的发现率一定小于A？如果B项目在3个Bug的地方都设置了检测点，覆盖率是不会低的。
其实，Bug总数越多，出现率这个数据越具有代表性。相反，针对于Bug较少的A项目，则随机性较大。像上面如果A没有在针对那个小Bug设置检查点，很有可能因为不被算作用例发现而导致用例发现率为0。
所以，用例发现率不会单独使用，它会以其他相关数据一起使用，而它在其中占的系数，则是由其他数据决定的。
测试覆盖率并不能代表BUG发现率，理由同上。因为在做测试用例的时候，用例覆盖所有需求是必须的。也可以把他理解成为前提条件。如果说用测试覆盖率去衡量测试人员的能力或者说是工作态度，我觉得还是可以的。最起码别人这么评估我的时候我可以接受。
你说的很对，Bug发现率和测试覆盖是不同的。严格来说，Bug发现率是支撑测试覆盖率的一个子数据。若Bug数越多，Bug覆盖率越高，则说明当前使用的测试用例覆盖率越高，也就从另外一方面说明设计用例的测试人员的工作越出色。
还有一个问题，就是用例覆盖率的问题。用例覆盖率有两种说法。
1、针对于需求的用例覆盖率。通常指针对于前期需求文档或客户需求的覆盖率，一般项目都能达到100%。
2、针对于测试实体的用例覆盖率。通常指针对测试实体采用的测试方法和技巧的覆盖率，一般项目能达到50%就很不错了。而Bug发现率则着重支撑这个数据。
如果单纯的仅仅靠BUG发现率来去衡量一个测试人员的工作绩效，我觉得实在有点说不过去，因为我觉得只要是能在测试这个行业是干上个1年2年的人，都应该是那种责任心非常大的人。这么衡量很容易给测试人员造成消极心理。
测试人员考核都是用多种考核参数与各个系数的乘积得出的嘛，我所说的只是在不同的测试阶段，各个参数的系数应该不同而已。比如在做年终考核时，前3个月主要是设计用例，后9个月则是测试执行，那么Bug发现率在全年的考核数据为：个人负责模块的Bug发现率*(0.8*0.25+0.2*0.75)。不存在你所担心的嘛::daxiao:::
晕老大我不了解行情啊 刚进公司的时候 1K多就把自己卖了
你有QQ吗我加你QQ吧以后有啥不懂的我好问问你别嫌烦就好 呵呵
呵呵，QQ号消息发给你了，不过目前我所在的公司不能上QQ和MSN，只能晚上聊聊。
（哎，等换了就好了::qie::: ）
[ 本帖最后由 Jackc 于 2010-6-21 15:42 编辑 ] 1·考核
用例能决定一切吗？用例就是测试的唯一吗？测试的用意在于产品交付客户后不会发生问题。过程固然重要
2·用例有效性
大可说的很对，客观因素太多了！如果我让你写登录页面和一些简单的逻辑功能！之后这些东西是一个非常细心的开发人员而且该开发人员非常有经验……那非常抱歉。你很有可能全部功能测试完毕发现不了几个BUG，甚至发现不了。 告诉你个好东西 td 里头有统计的！ 讨论了那么多，到底是怎么计算的呢，bug的用例发现率是发现bug数 / 执行用例数？对吗？那位给个确切的答复？ 谁能告诉我，如何对测试出来的bug进行量化考核，跟分数和工资挂钩呢:sleepy:
页:
[1]
