本文讨论了在一个软件企业内部如何描述软件缺陷信息，如何实施缺陷跟踪管理，以及缺陷跟踪管理工具的实现原理及设计要领。

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

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

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

　　软件缺陷的描述

　　这里首先对“缺陷”和“错误”两个概念做一下区分：缺陷指软件文档或程序代码中存在的数据错误、逻辑错误、内容遗漏以及内容上的不一致等。缺陷包括错误，与bug是同义词（注：鉴于这是一篇实用性文章，笔者不打算对缺陷、错误、bug进行更细致的理论讨论）。既然在软件开发流程的每个阶段开发人员都有可能引入缺陷，那么如何来描述一个缺陷呢？下面笔者谈谈自己的看法。

　　首先，对缺陷的描述应该包含可追踪信息，如给每个缺陷分配一个缺陷号，每个编号必须是惟一的，可以根据该编号搜索、查看该缺陷的处理情况。

　　其次，对缺陷的描述应该包含缺陷的基本信息。通常缺陷的基本信息包括缺陷状态、缺陷标题、缺陷严重程度、缺陷紧急程度、缺陷提交人、缺陷提交日期、缺陷所属、缺陷解决人、缺陷解决时间、缺陷解决结果、缺陷处理人、缺陷处理最终时间、缺陷处理结果、缺陷确认人、缺陷确认时间、缺陷确认结果等等。