使用缺陷数据来测量绩效是诱人的。测试人员是找缺陷的，因此您期望好的测试人员找到很
多缺陷。许多管理人员通过收集和跟踪缺陷数据来进行绩效管理。然而， 缺陷数量报告仅能
对个人业绩提供非常有限的参考。尤其是同事人之间的比较时， 缺陷数据具有太多的可变量，
比如下面的几方面：
•所测试功能的复杂性
•开发人员编程能力
•规格完整性
•缺陷预防与缺陷发现
•报告的及时性
此外，如果有人打算利用缺陷数量数作为一个业绩考核标准，该人必须理解该标准的参数和
考虑到诸如如下的问题：
•报告的缺陷具有什么严重性和优先度, 分布如何？
•功能缺陷与简单的用户界面缺陷一样算数量吗？ •花费时间（一天或几天）追踪一
个关键问题（如数据丢失，内存泄漏）并使之得到解决，这能说明没有达到预期或
业绩表现差吗？如果是，什么是团队合作的政策，即协助开发人员排解疑难问题？
•缺陷质量是一个因素吗？如果是的话，在团队里，这些具体因素是如何决定缺陷
的？团队平均值是什么？平均数是目标吗？哪些具体的因素是超过预期的目标？
•每一次评比，最低的缺陷数量是什么？什么样的缺陷数量是测试人员超过期望的数
量？
发现了大量的缺陷可能表明测试人员做的很好，或者它可能意味着开发人员编写的代码很
差。反之，如果一个测试人员找到很少的缺陷，这可能是一个迹象:表明他做得不理想，也
可能意味着他正在测试高质量的代码，具有较低的缺陷密度。所以关键是怎样解读数据，这
也意味着可能需要额外的个案调查。例如，如果一个测试人员没有报告很多缺陷，看一下功
能区以确定是什么原因造成缺陷数量低。如果其他用户（客户、开发，Beta测试用户）在该
功能区找到缺陷，该测试人员的低缺陷数可能会有问题。如果是测试运行次数 （用测试用例
或代码覆盖信息为度量） ，低缺陷数量也是值得调查的。当然，如果进一步的调查后，您确
定功能区的测试不错，没有多少缺陷，这当然就不该怪测试人员了。
一个缺陷度量的故事
当我刚开始在微软工作时， 对找缺陷数量有特定的要求。我的经理告诉我， 团队里的每一个
测试人员每星期应找到 10 个缺陷。这似乎像一个合理的要求，所以我努力去工作，并开始
寻找缺陷。 像大多数微软的员工，我一直想做得更多一点， 所以我每星期找出 12 或 13 个缺
陷。
幸运的是，我所测试的领域总是在变化，对我来说，完成配额从来没有问题。事实上，有几
个星期，我发现 20 个或更多的缺陷！当发生这种情况，我却很担心，我已发现太多的缺陷，
下周我将无法完成我的配额。所以，我每周只报 13 个缺陷左右，这样来“节省‖缺陷，以防
下一周我的缺陷枯竭。
这是另一类典型的例子，它表明你衡量的是什么。我的经理每星期要 10 个缺陷，我给了他
所想要的，却不管我是否能发现更多的缺陷。我一再看到有人企图利用缺陷度量来衡量个人
业绩，但这些度量很少有效。
——摘自《微软测试之道》第9章