上这些度量项，对于测试管理者来说应该都不陌生，全部整理到一起，真的还是蛮齐全的了。测试品质保证的乐趣，其实很多就在这些关键度量元素间。其一，这样的分析显然是颇具科学意义的，统计学嘛；其二，真正能通过管理这些度量项达到提高质量的效果，那是一件很美妙的事情。我个人而言，比较有实用感触的是1，2，3，5，15这几项。
1---客户反馈缺陷，即漏测。其实这是一个很直观的质量保证结果，本人非常崇尚用这个指标衡量测试人员的结果绩效。虽然漏测的原因不单单在于测试的疏忽，但终究能在很大程度上体现测试的质量。且通过对这个指标的线性观察，发现一些潜在的可能在未来会反馈回来的问题，我们还能亡羊补牢，出补丁提前堵漏。
2---模块缺陷密度。往往找到缺陷最多的地方也是潜在缺陷最多的地方。这个规律几乎是千真万确。就跟越是担心会出问题的时候一般都是会出问题的，类似。这个在测试过程中或者发布之后拿来分析都很有意义。
3---遗留缺陷。仅仅看一个绝对的数字并无太大意义，它的意义在于与之前拟定的交付标准做比对，假若在标准之内就放行，不在标准之内那就卡住。另外，被允许的遗留缺陷一般也是下一阶段启动任务之时开发任务的首要任务之一。
5---趋势分析。这是一个质量活动如期完成的强力证明工具，当然要真正看到收敛才对。
15--测试用例有效率。这个指标更大意义的是规范测试活动，其次才是提高测试用例的质量。想要统计出有效率，有个前提就是测试集驱动测试，即你开展每一轮测试之前，根据测试需求建立好测试集，并且集里面的测试用例也都已经确定好，之后照着逐一测试。很多测试人员说测试用例只不过是我用来熟悉需求的产物，等我拿到被测对象，我根本就不看测试用例就刷刷的往下测。殊不知，人的记忆往往是有漏洞的，当你脱离测试用例来测试，你就是在走向随机测试，大家想想随机的活动有没有可把握性？
简单评论之后，我再加一个度量项，尤其是在这提倡测试先行的年代。---需求review阶段发现的需求issue数/整个测试过程中发现的需求Issue的总数，这个指标体现测试人员在需求熟悉阶段对需求透析程度，透析度越深往往对促进需求精致化的贡献度越大，对测试用例的有效性的贡献也越大。我们毕竟不希望到了测试执行阶段才来不停的质疑需求这里有问题那里有问题。
