不能使用缺陷数据作为绩效度量

使用缺陷数据来测量绩效是诱人的。测试人员是找缺陷的，因此您期望好的测试人员找到很

多缺陷。许多管理人员通过收集和跟踪缺陷数据来进行绩效管理。然而， 缺陷数量报告仅能

对个人业绩提供非常有限的参考。尤其是同事人之间的比较时， 缺陷数据具有太多的可变量，

比如下面的几方面： 

•所测试功能的复杂性 

•开发人员编程能力 

•规格完整性 

•缺陷预防与缺陷发现 

•报告的及时性

此外，如果有人打算利用缺陷数量数作为一个业绩考核标准，该人必须理解该标准的参数和

考虑到诸如如下的问题：

•报告的缺陷具有什么严重性和优先度,  分布如何？ 

•功能缺陷与简单的用户界面缺陷一样算数量吗？  •花费时间（一天或几天）追踪一

个关键问题（如数据丢失，内存泄漏）并使之得到解决，这能说明没有达到预期或

业绩表现差吗？如果是，什么是团队合作的政策，即协助开发人员排解疑难问题？ 

•缺陷质量是一个因素吗？如果是的话，在团队里，这些具体因素是如何决定缺陷

的？团队平均值是什么？平均数是目标吗？哪些具体的因素是超过预期的目标？ 

•每一次评比，最低的缺陷数量是什么？什么样的缺陷数量是测试人员超过期望的数

量？ 

发现了大量的缺陷可能表明测试人员做的很好，或者它可能意味着开发人员编写的代码很

差。反之，如果一个测试人员找到很少的缺陷，这可能是一个迹象:表明他做得不理想，也

可能意味着他正在测试高质量的代码，具有较低的缺陷密度。所以关键是怎样解读数据，这

也意味着可能需要额外的个案调查。例如，如果一个测试人员没有报告很多缺陷，看一下功

能区以确定是什么原因造成缺陷数量低。如果其他用户（客户、开发，Beta测试用户）在该

功能区找到缺陷，该测试人员的低缺陷数可能会有问题。如果是测试运行次数 （用测试用例

或代码覆盖信息为度量） ，低缺陷数量也是值得调查的。当然，如果进一步的调查后，您确

定功能区的测试不错，没有多少缺陷，这当然就不该怪测试人员了。

 

一个缺陷度量的故事

当我刚开始在微软工作时， 对找缺陷数量有特定的要求。我的经理告诉我， 团队里的每一个

测试人员每星期应找到 10 个缺陷。这似乎像一个合理的要求，所以我努力去工作，并开始

寻找缺陷。 像大多数微软的员工，我一直想做得更多一点， 所以我每星期找出 12 或 13 个缺

陷。

幸运的是，我所测试的领域总是在变化，对我来说，完成配额从来没有问题。事实上，有几

个星期，我发现 20 个或更多的缺陷！当发生这种情况，我却很担心，我已发现太多的缺陷，

下周我将无法完成我的配额。所以，我每周只报 13 个缺陷左右，这样来“节省‖缺陷，以防

下一周我的缺陷枯竭。

这是另一类典型的例子，它表明你衡量的是什么。我的经理每星期要 10 个缺陷，我给了他

所想要的，却不管我是否能发现更多的缺陷。我一再看到有人企图利用缺陷度量来衡量个人

业绩，但这些度量很少有效。

——摘自《微软测试之道》第9章