3.2.9　缺陷度量和缺陷跟踪

缺陷预防和缺陷清除的缺陷度量方案的有效性是相对较高的，然而令人沮丧的是，如此有力的武器却很少有人使用。

缺陷跟踪，或保留缺陷从第一次发生直到被修复以及被分配整个过程的记录，是比较常见的。然而，缺陷跟踪与技术（如修复的速度）相关，而与基础的主题如（如缺陷起源和根本原因）无关。

直到最近，准确和自动化的缺陷跟踪还是一个只有很少公司具有的能力，因为有必要构建定制的缺陷跟踪系统。因此，只有大公司拥有完全自动化的缺陷跟踪系统，如AT&T、波音、惠普、IBM、微软、摩托罗拉、诺斯洛普格鲁曼、雷神、西门子利多富等。

从20世纪90年代开始，持续到今天，很多新的商业缺陷跟踪工具进入了美国商业市场，用在各种平台上，如Windows、Linux、Leopard，最近还用在Android上。准确和自动化的软件缺陷跟踪现在对于任何选择做缺陷跟踪的公司而言，都是力所能及的。

当代商业缺陷跟踪工具的整体功能包括了按照严重等级和按照来源来跟踪缺陷，将缺陷按指定路线发送到适当的修复设备。一些商业缺陷工具有更高级的功能，例如保存重复的缺陷、误提交的无效缺陷等内容的记录。

有一个有趣的观察是，这些新的商业缺陷跟踪工具是由公司之前的员工创建的，这些员工构建了内部缺陷跟踪系统。使用过这样的系统，看到了它们的能力，很显然存在着一个快速增长的商业市场。2010年夏天，用Google搜索短语"software defect tracking tools"（软件缺陷跟踪工具），返回了超过25家公司和50种工具的信息。这其中大部分缺陷跟踪工具是商业的，但是也有一些是开源的。

缺陷跟踪工具和缺陷度量工具所感兴趣的能力，应该包含下面这些。

●来自所有主要来源的缺陷都应该能被记录，即需求、设计、源代码、用户文档、不良修复中的缺陷或者二次缺陷。能够增加其他缺陷来源也是很有用的，如测试用例中的错误或数据错误。

●缺陷起因应该被包括进来，即遗漏的错误、指令的错误（errors of commission）、含糊的错误、计算效率或者性能的错误。

●对同一缺陷的重复报告应该被记录和标注出来，尽管对于质量分析而言，大多数统计是以独一无二的有效缺陷为基础的。然而，对于严重度高的缺陷的很多重复的缺陷报告是一个需要注意的重要主题。

●除了真正的bug或者缺陷，无效的缺陷报告经常被收到。（本书的一位作者曾经收到过一个bug报告，该bug是一个直接竞争对手的软件的，被通过邮件误发给作者了。）无效缺陷报告的例子包括被误诊断为软件问题的硬件问题、用户错误，以及诸如操作系统的问题被误诊为操作系统上所运行的应用程序的错误。因为无效缺陷报告很多且很昂贵，所以它们应该作为缺陷跟踪系统的标准特性被记录下来。

●记录缺陷报告被收到的方法尽管对于缺陷修复不是很重要，但却是有帮助的。向厂商报告缺陷的主要渠道包括网站、文本消息、电话、传真（衰退中）、E-mail（当厂商支持该方法时，这个方法是很常见的），以及有现场服务时（如部署ERP包期间）一些面对面的讨论。这一类数据对于规划热线和客户支持台等的人力资源是有用的。

●缺陷严重度级别应该被记录，范围从危急的（critical）到较小的（minor）。然而，给缺陷分配严重度是非常主观的，因此需要一些条款来允许在必要的时候改变严重度的级别。

●有一部分缺陷最终被建议为在将来加强。因此，工具应该有这个能力，即将缺陷报告转化为可能的新特性。

●缺陷首次被报告的日期应该被记录下来，如其他关键事件发生时的日期被记录一样，例如将缺陷转到修复团队、缺陷解决的最终日期，还有修复后的软件重新发布给客户的日期。

●缺陷跟踪工具应该有一个内建的警告系统，以便于那些年龄超过用户指定的边界点的缺陷被着重显示出来。例如，一个超过一周没有被修复的关键度为1的缺陷需要某种警告信号。

●一些缺陷跟踪系统还需要记录修复缺陷所需要的工作量。如果缺陷跟踪系统包括了这个特性，那么它就应该有足够的粒度来捕获所有相关的活动，例如缺陷分析、设计变更、代码变更、新测试用例的建立、测试等。

●有不少缺陷不能被厂商的修复团队重现。这个情况通常是因为客户使用的一些特别的或者独特的硬件和软件组合。IBM使用术语“暂时搁置的缺陷”（abeyant defect）来表示这些困难的问题。这个术语是指修复不得不延期，直到关于导致问题发生的特殊条件的额外信息得以被引出。暂时搁置的缺陷通常修复时间是最长的，也是最昂贵的，因此在它们发生时缺陷跟踪系统需要能够将其着重显示出来。

●缺陷跟踪工具和缺陷度量工具需要一些统计上的概括能力（内建的或者是外部的），这些能力可以为高级主管们生成关于总缺陷的报告，这些缺陷的报告可以按照时间段、缺陷所在的应用程序、报告缺陷的不同客户、缺陷严重等级、缺陷起源等方式生成。另外，还需要报告平均缺陷修复时间、最大和最小缺陷修复时间，以及其他生产率主题。最终的统计能力是指将数据标准化，以来按照功能点、KLOC和其他规模度量元展示所报告的缺陷。最理想的情况是，统计的引擎应该可以报告潜在缺陷（来自所有来源的总缺陷）和累积缺陷清除效率（发布前缺陷清除的百分比）。一些公司还能够计算各种审查、静态统计、很多种测试的具体的缺陷清除效率水平。

拥有复杂的缺陷度量和跟踪工具的公司，如IBM和摩托罗拉，随着时间的发展潜在缺陷会减少，而且缺陷清除效率水平会提高。

对于构建大型软件系统来说，找到bug和修复bug的总体累积成本通常非常高。因此，有效的缺陷跟踪工具对于质量和生产力提高都是非常有用的。