关于测试遗漏的分析

大概已经有两年多的时间了，出货后的客户反馈缺陷一直作为我们的KPI。

说实话，当时只是确认降低这个数字对我们来说非常有意义，但并不知道降低到多少是合理的，当然最理想是零，不过显然不可能。最差的时候，我们一个产品发布给3-4家客户，一天能报回来7-8个D类以上的缺陷，有几次报到总经理那里，非常的惶恐。但不管怎样，既然是KPI，肯定是要可以被衡量，所以就先主观（虽说是主观，但也是结合了以往的历史数据的）定一个目标上限。第一步我们针对之前的测试遗漏一个个作仔细的分析，分析漏测的原因，然后将原因归类，看百分比，最后依照原因百分比从大到小一个个安排对策去克服。两年来，就是这么过来的，当然随着测试质量的提升，那个主观的数字也在不断的变化，效果还蛮明显，现在一个版本出去之后半年，10多家客户，总计也就不到10个。似乎蛮好的。

但是今天做了一个分析，把我吓了一跳。

最近刚发布了一个新版本，我让我的team member手工统计了一下这次测试发现的缺陷中有几个是上个版本的测试遗漏，最后得到的平均值是35%，着实把我吓了一跳。也就是说这次35%的精力是补以前的漏洞了，再换算一下，把这次测到的遗漏+客户反馈的作为上个版本的测试遗漏，除以上个版本发布当时的缺陷总数，结果是30%左右，又吓了一跳，如果这个30%是我们当前的能力经验值，那么我已经能预测到这个版本发布存在的测试遗漏，只是看我们跟客户哪个发现的更快些！虽说，只要客户不发现，就造不成什么经济损失，但心理还是很怕怕的。

当然我还要再分析一下这次发现的上版本漏测缺陷的具体原因。这次测试我加入了交叉测试，但这也不能作为百分百的理由。

总之我要再深入的反省一次了。汗一个！