关于漏测率的统计

goopy

部门内测试人员KPI中，现在要加入漏测率的考核，不知道各位有没有统计过漏测率，都是怎么统计的，大家能说下吗

zhuwenfeng

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

没翅膀的飞鱼

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

goopy

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

sunzhenguo1010

我觉得答的挺好的，感觉你还没懂。这个是由多个因素决定的，你要综合分析自己总结啊

没翅膀的飞鱼

回复 3# goopy

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

kavensyw

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

lymmxz

回复 6# kavensyw
学习了，但不知道这样的考核以什么为依据？

zhuwenfeng

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

ff411

aric60

8楼的说的全面务实

pcxty

与DDP相反即可，DDP是讲探测率，DDP=测试发现的Bug数 / Bug总数（测试+客户） *100%

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

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

zhuwenfeng

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

kavensyw

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

kavensyw

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

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

zhujiejun1314

15楼的  顶了  ~~说的很具体~

zhujiejun1314

6# 8# 15#的 学习了，感谢~

ahaxi

学习了！想找个漏测回溯表单

guoguo2005

上线后发现缺陷个数/上线前后发现的缺陷总数

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

karenzhou2

这个帖子好老了，顶上来。大家都怎么评定漏测率的呀。