51Testing软件测试论坛

标题: 关于漏测率的统计 [打印本页]

作者: goopy 时间: 2013-1-18 21:44
标题: 关于漏测率的统计
部门内测试人员KPI中，现在要加入漏测率的考核，不知道各位有没有统计过漏测率，都是怎么统计的，大家能说下吗

作者: 没翅膀的飞鱼 时间: 2013-1-19 10:51
漏测率感觉可以从以下几个方面考虑：
1. 同一个测试人员一个版本多个Build测试时，是不是有些bug在后期发现（要考虑测试策略和时间问题）
2. 同一个模块交叉测试，看看是不是能发现之前测试人员没有发现的bug（要考虑是否是测试用例的问题）
3. 是不是有些测试人员没有按照测试用例走，测试覆盖率不够等
当然要进行漏测率的统计也要考虑如测试时间，测试策略以及其它问题，做一个动态把握

作者: goopy 时间: 2013-1-19 14:50
楼上的有点答非所问呢，现在是要计算漏测率，漏测率的计算，肯定会有个公式，这就关系到分子和分母的取值问题，所以就想问下大家有没有这方面的经验，想借签下

作者: sunzhenguo1010 时间: 2013-1-21 20:03
我觉得答的挺好的，感觉你还没懂。这个是由多个因素决定的，你要综合分析自己总结啊

作者: 没翅膀的飞鱼 时间: 2013-1-22 17:15
回复 3# goopy

漏测率是会要涉及到分子分母问题，但是如果不知道分子分母的参数如何获取，知道公式又有什么意义呢？我这里主要说明的是分子的获取，分母的获取看你具体的项目了，可以是测试用例总数也可以是缺陷总数

作者: kavensyw 时间: 2013-3-18 17:53
本帖最后由 kavensyw 于 2013-3-18 17:56 编辑

是考核的这个公式吧：客户反馈的Bug数 / Bug总数（测试+客户） *100%。
该公式，我习惯上会按不同严重等级进行一个换算。

作者: lymmxz 时间: 2013-3-19 09:06
回复 6# kavensyw
学习了，但不知道这样的考核以什么为依据？

作者: zhuwenfeng 时间: 2013-3-19 10:32
可以使用多个指标进行衡量，至少包括以下几点：
1、用例包括而未发现的bug数/用例总数（衡量用例执行质量，执行人员的测试效果）
2、版本交付后又发现的bug数/项目bug总数（衡量总体测试效果，也是重要的产品质量，项目质量指标）
3、用例不包括而发现的bug数/bug总数（衡量用例质量）
4、严重bug在测试周期的分布（后期严重bug比例较重，则显然整个项目组都比较被动，虽然bug最终被发现了，但仍是一种“漏测”行为）
####
值得说明：
1、上述指标异常并非只是测试人员的责任，开发人员也可能会在后期引入严重缺陷。
2、测试用例不包括而发现的bug，一般不认为是测试失误，而是测试用例设计和评审的失误。
3、测试用例包括而未被发现的bug，测试人员应付全责。

作者: zhuwenfeng 时间: 2013-3-19 10:37
6# “客户反馈的Bug数 / Bug总数（测试+客户） *100%”
有相当的合理性。
建议讨论一下，开发人员、测试人员的责任边界这个话题

作者: ff411 时间: 2013-3-19 11:14

作者: aric60 时间: 2013-3-19 11:34
8楼的说的全面务实

作者: pcxty 时间: 2013-3-19 11:36
与DDP相反即可，DDP是讲探测率，DDP=测试发现的Bug数 / Bug总数（测试+客户） *100%

漏测率=客户反馈的Bug数 / Bug总数（测试+客户） *100%

不说责任, 想办法提高DDP的值，减少漏测率的值，才是最重要的。

作者: zhuwenfeng 时间: 2013-3-19 13:18
@ 12#
责任当然是另外一个话题，就写在这里：
1、开发、测试是有责任边界的，这不是说如何在工作中推卸责任，保护自己，而是更加明确的，分工到人，责任到人，有计划有目标的测试。
2、测试人员应该勇于担当。
这一点非常重要。
明明知道项目组其他成员们，期望一份条分缕析的测试报告，却总是含混其词，是可耻的。

作者: kavensyw 时间: 2013-3-19 20:52
关键要明白度量的目标是什么。度量贵精不贵多，分析时要综合考虑，不要以单一指标来衡量。同时我个人倾向于通过度量来分析问题，不提倡将度量和测试绩效直接挂钩。

作者: kavensyw 时间: 2013-3-19 21:01
度量贵精不贵多，同时应注重针对分析问题，避免针对个人。可考虑从以下几个方面入手（有些指标，可考虑添加折算系数）：
1、问题类型：需求问题、设计问题、代码问题、数据问题、配置问题、测试问题；
2、发现阶段：需求阶段、设计阶段、单元测试、集成测试、系统测试、UAT阶段、维护阶段；
3、按模块划分；
4、按严重等级划分；
5、千行代码Bug率（上下阀值，过低或过高均可能有问题）；
6、Bug流出率。
7、其他（需求覆盖率、每功能点用例数、Bug数/用例数等等。）

可使用一定的图标辅助分析，示意如下：

作者: zhujiejun1314 时间: 2013-3-20 17:49
15楼的顶了 ~~说的很具体~

作者: zhujiejun1314 时间: 2013-3-20 17:54
6# 8# 15#的学习了，感谢~

作者: ahaxi 时间: 2013-5-13 15:25
学习了！想找个漏测回溯表单

作者: guoguo2005 时间: 2013-5-13 15:56
上线后发现缺陷个数/上线前后发现的缺陷总数

小于5%，非常优秀
小于10%，优
大于10%，良好

作者: karenzhou2 时间: 2016-8-29 11:40
这个帖子好老了，顶上来。大家都怎么评定漏测率的呀。

作者: lyf83111 时间: 2017-2-7 10:18
现在我们也要考核这个，顶起来

作者: maliya1314 时间: 2017-2-21 15:03

可以使用多个指标进行衡量，至少包括以下几点：
1、用例包括而未发现的bug数/用例总数（衡量用例执行质量，执行人员的测试效果）
2、版本交付后又发现的bug数/项目bug总数（衡量总体测试效果，也是重要的产品质量，项目质量指标）
3、用例不包括而发现的bug数/bug总数（衡量用例质量）
4、严重bug在测试周期的分布（后期严重bug比例较重，则显然整个项目组都比较被动，虽然bug最终被发现了，但仍是一种“漏测”行为）
####
值得说明：
1、上述指标异常并非只是测试人员的责任，开发人员也可能会在后期引入严重缺陷。
2、测试用例不包括而发现的bug，一般不认为是测试失误，而是测试用例设计和评审的失误。
3、测试用例包括而未被发现的bug，测试人员应付全责。觉得这个说的特别好

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