软件缺陷跟踪管理

(戴金龙、谢敏)

郑重申明：本文版权归计算机世界，任何转载和大幅刊用，务必征得作者同意。

1为什么要做软件缺陷的跟踪管理

考察一个典型的软件开发流程：需求分析—概要设计—详细设计—程序编码—系统集成—交付与维护，你会发现此流程中各阶段之间的依赖与继承关系是相当密切的。前一阶段形成的方案或产品中正确的部分固然会被后一阶段继承和细化，然而，如果前一阶段的方案中出现了错误，而测试人员没有及时介入此阶段的质量控制，那么该错误就会被后一阶段继承和放大，并顺序传递下去。如果等到交付与维护阶段，错误才被发现，那么相关的纠错工作将成为一件成本高昂而又收效甚微的事情，在某些的情况下，甚至会导致整个开发工作的失败。这并不是故意危言耸听。据美国国家标准技术研究院的一份报告显示，占据世界软件销售额85%的大型专用软件，其开发的失败率高达70%。

因此，在软件开发流程的每个阶段都必须引入软件测试技术，及早测试，杜绝错误的蔓延。然而，测试工作的天性决定了测试人员可能是开发人员总想回避的角色。在测试实践的早期，当测试人员查出某个缺陷，报告给开发人员时，多数情况下开发人员会象征性表示一下感谢，然后把测试报告撂在一边，继续忙手头的工作。事后到底有没有修改，谁也不知道。如果测试人员频繁给同一开发人员报错或不停地追问缺陷的修改情况，开发人员或许会逐渐丧失好脾气，出于维护技术权威或其他目的，他会狡辩：这不是错误，这是软件的一个特殊功能。或者说：这不是什么大问题，现在开发进度紧，而且纠正起来也挺麻烦的，等有时间再说吧。于是，不了了之，问题依旧存在。

为了规避这种情况的发生，软件企业必须引入软件缺陷跟踪管理机制。测试人员不再需要直接与开发人员接触，甚至不需要知道开发者是谁，查出错误以后，直接报到缺陷跟踪管理系统就可以了（有些测试团队是有写入权限控制的），开发人员做不做修改以及什么时间之前必须完成修改是项目管理部门的事情（当然测试团队也可以提相关建议）。引入缺陷跟踪管理机制一方面划清了各个角色的职责，避免了不必要争执，另一方面也有助于项目管理部门及时了解软件产品在生产过程中所处的质量状况，从而更好地控制产品的质量。

2软件缺陷的描述

在上一节的讨论中，没有对缺陷、错误做严格的区分，在开始本节的论述之前，先简单说明一下这两个概念。缺陷，指软件文档（如软件需求规格说明、设计规格说明等等）或程序代码中存在的数据错误、逻辑错误、内容遗漏以及内容上的不一致性等等。它包括错误，与bug是同义词（注：针对缺陷、错误、bug有更细致的讨论，鉴于这是一篇实用性文章，笔者不打算做更严格的区分）。在上面一节，我们谈到在软件开发流程的每个阶段开发人员都有可能引入缺陷，那么如何来描述一个缺陷呢？下面笔者谈谈自己的看法。

1、对缺陷的描述应该包含可追踪信息

如给每个缺陷分配一个缺陷号。每个编号必须是唯一的，可以根据该编号搜索、根据、查看该缺陷的处理情况。

2、对缺陷的描述应该包含缺陷的基本信息

通常缺陷的基本信息包括缺陷状态、缺陷标题、缺陷严重程度、缺陷紧急程度、缺陷提交人、缺陷提交日期、缺陷所属、缺陷解决人、缺陷解决时间、缺陷解决结果、缺陷处理人、缺陷处理最终时间、缺陷处理结果、缺陷确认人、缺陷确认时间、缺陷确认结果等等。下面笔者简单解释一下：

缺陷状态：标注缺陷待修正、待评审、待验证、关闭等状态信息；缺陷标题：简明地说明缺陷的类型及内容；缺陷严重程度：测试人员给出的缺陷严重程度估计，可以是致命的、严重的、一般的、建议的；缺陷紧急程度：测试人员给出的测试处理优先级；缺陷提交人：发现此缺陷的测试人员，最好附有联系方式，以方便缺陷处理人员进行确认；缺陷提交日期：提交人提交缺陷的日期；缺陷所属：指缺陷所在的模块或者是缺陷所属的开发文档的名称；缺陷解决人：由谁来进行缺陷的解决，明确是需求分析人员、设计人员还是程序编码人员；缺陷解决时间：项目组负责人返回的缺陷预计处理的时间；缺陷解决结果：预计缺陷修改后能达到的结果；缺陷处理人：应该由谁来处理这个缺陷；缺陷处理最终时间：指缺陷得到处理的实际时间；缺陷处理结果：缺陷最后的实际处理结果；缺陷确认人：由谁来确认缺陷已经得到了修正；缺陷确认时间：缺陷修复的确认工作完成的时间；缺陷确认结果：确认软件缺陷的修正工作是否有效。

以上列出的条目不是必须的，读者可以根据项目的实际情况进行剪裁，同时还应该根据测试工作的实际需要适当添加一些笔者没有考虑到的条目。另外，要引起注意的是上述部分条目不是由测试人员来填写的，如：缺陷解决时间、缺陷解决结果、缺陷处理人等等，应该由项目管理人员统筹成本、进度等因素后决定。

3、对缺陷的描述应该包含缺陷的详细描述；

即是对缺陷的特征应做详细的描述，例如程序代码中的错误，应详细描述错误发生的软硬件环境，相关输入输出数据，出错时程序的状态等等，以方便编码人员进行错误复现和错误定位。又如设计规格说明中的错误，应指明它与高层软件开发文档（如需求规格说明）中哪些条款相违背，为什么判为违背，都需要描述清楚，以方便设计人员进一步核实。

4、对某些缺陷的描述应该包含必要的附件；

有时，某些缺陷可能无法用语言文字表达清楚，如用户界面出现的一些缺陷，光用语言文字是难以表述清楚。这时，就需要借助于屏幕拷贝等方式来进一步描述缺陷。

3 软件缺陷管理的一般性流程

我们来看一个软件缺陷跟踪管理系统的简单流程：

该流程涉及如下角色：

测试人员：  执行测试的人，是缺陷的报告者。

项目负责人：包括上文所提到的项目管理人员。他对整个项目负责，对产品质量负责。

开发人员：  设计和编码人员

评审员：    对缺陷进行最终确认，在项目成员对缺陷处理达成一致意见时，行使仲裁权力。

各个角色的职责分配如下：

“提交”、“未通过”、“通过”由测试人员来定义；

      “分配”由项目负责人来定义；

“修正”与“不修正”由开发人员来定义；

“评审通过”与“评审不通过”由评审员来定义。

图中提到软件缺陷的几个状态有：

初始状态、待分配状态、待修正状态、待验证状态、待评审状态以及最后的关闭状态。

读者可以根据企业的实际情况，适当调整该流程以取得更高的效率。

4 缺陷跟踪管理系统概述

    缺陷跟踪管理系统（ Defect Tracking System）是用于集中管理软件测试过程中发现的缺陷的数据库程序。可以通过添加、修改、排序、查寻、存储操作来管理软件缺陷。

目前市场已经出现了一些通用缺陷跟踪管理软件。这些软件在功能上各有特点，可以根据实际情况直接购买使用。也可以根据测试项目的实际需要，开发专用的缺陷跟踪系统，例如基于Lotus Notes 开发。

4.1缺陷跟踪管理系统的作用

（1）便于缺陷的查找和跟踪。对于大中型软件的测试过程而言，报告的缺陷总数可能会达成千上万个，如果没有缺陷跟踪管理系统的支持，要求查找某个错误，其难度和效率可想而知。

（2）便于协同工作。缺陷跟踪管理系统可以作为测试人员、开发人员、项目负责人、缺陷评审人员协同工作的平台。

（3）保证测试工作的有效性。避免测试人员重复报错，同时也便于及时掌握各缺陷的当前状态，进而完成对应状态的测试工作。

（4）便于跟踪和监控错误的处理过程和方法。可以方便地检查处理方法是否正确，跟踪处理者的姓名和处理时间，作为工作量的统计和业绩考核的参考。

4.2 缺陷跟踪管理系统的实现原理

缺陷跟踪管理系统在实现技术层面上看是一个数据库应用程序。它包括前台用户界面，后台缺陷数据库，以及中间数据处理层。目前，不少缺陷跟踪管理系统是采用B/S结构来实现的，相应地，采用的编程语言是ASP或JSP。读者可以根据需要选择购买商品化的缺陷跟踪管理工具，或者选择自行研发软件缺陷跟踪管理工具。这类系统的用户界面所显示的信息一般应根据用户的角色不同（测试人员、开发人员、项目负责人、缺陷评审员等等）而略有差异，因为各个角色使用该系统完成的任务各不相同，如测试人员用于报告缺陷或确认缺陷是否可以关闭，开发人员用于了解哪些缺陷需要他去处理以及缺陷经过处理后是否被关闭，而项目负责人需要及时了解当前有哪些新的缺陷，哪些必须及时修正等等。另外，不同角色所拥有的数据操作权限也不尽相同。例如开发人员无权通过其用户界面往数据库中填写新的缺陷信息也无权关闭某个已知缺陷；而测试人员无权决定分配谁去修正某已知缺陷也无权决定是否要修正某个缺陷。除了用户界面的设计要考虑角色差异外，此类系统数据处理层所采用的业务逻辑也需要颇费推敲。本文第三节讨论的缺陷跟踪管理流程是一个可供参考的模型，读者可以对它进行进一步的细化，从而形成所要开发的缺陷跟踪管理系统的业务逻辑。也有一些其它结构的业务逻辑，读者可以通过查阅文献获得或请教专业的咨询公司。缺陷跟踪管理系统后台数据库的设计建议尽量考虑到不同角色的应用需要，如测试人员可能需要对相关数据表做频繁的记录的插入、查询等操作，软件开发人员可能对与他相关的记录非常重视，而对其他记录不感兴趣，而项目负责人员可能对新发现的缺陷数据需要做到及时掌握，这些需求对于数据库的建表、建立索引都有很大的指导性意义。数据库的具体实现可以根据应用规模选择Microsoft Access或者SQL Server，也有一些其它的数据库技术(如Oracle)可供采用。

5 实施缺陷跟踪管理的意义

上面我们讨论了在一个软件企业内部如何描述软件缺陷信息，以及如何实施缺陷跟踪管理，接着我们讨论了缺陷跟踪管理工具的实现原理及设计要领。这部分内容对于希望了解软件缺陷跟踪管理技术的读者有重要的参考意义。

实施软件跟踪管理技术对于企业而言，它的意义在于确保每个被发现的缺陷都能被解决。这里，解决可能是指缺陷被修正，也可能是指项目组成员达成一致的处理意见（如不做处理）。软件缺陷跟踪管理过程中所收集到的缺陷数据对评估软件系统的质量、测试人员的业绩、开发人员的业绩等提供了量化的参考指标，也为软件企业进行软件过程改进提供了必要的案例积累。另外，有些软件企业还根据缺陷跟踪管理过程中所获得的缺陷数目分布趋势来决定软件产品的最佳发布时机。