1、缺陷概述

　　测试是提高软件质量的重要途径，它的目的是发现软件中的错误（缺陷）。软件开发本身多方面的复杂性决定了软件中缺陷的存在无法避免。对于大型系统而言，缺陷的数量非常巨大。

　　本人曾参与一个工作量为250人年，周期为18个月的GSM移动网络开发项目。本人直接所在的子系统开发工作量为90人年（包括20人年外包）。该子系统原有代码行约40万，项目中新开发和修改的代码行约为9万。测试阶段包括：模块测试，子系统功能测试，子系统负载测试，子系统回归测试，系统接口测试，系统集成测试，系统负载测试，系统确认测试。在此期间发现的本人所在的子系统的缺陷约为200个。

　　由于系统各部分的开发，测试，及系统的集成测试分别由分散在不同国家的各个研发部门分工完成，因此对于缺陷的跟踪管理就需要有规范的流程。

　　2、缺陷跟踪流程实践

　　基本的缺陷跟踪流程及相关的基本内容在工业中的各个实际的流程中是大致相同的，但针对不同的领域和范围会有所不同。本章中，作者主要从实际项目中亲自实践使用的缺陷跟踪流程的角度加以描述。

　　2.1 缺陷的描述

　　缺陷描述是任何缺陷跟踪和报告系统的核心，包含缺陷的必要信息。缺陷描述所形成的技术文档就是缺陷报告，它描述与单个缺陷相关的各种征兆或模式。

　　在项目实践中，缺陷的描述包含五个部分：

　　● Header（头）：包含缺陷的编号，相应产品，缺陷报告创建者，创建日期，当前状态等基本信息。

　　● Body（体）：包含缺陷所在的子系统和相应版本，对应的功能模块，简要描述和详细描述，缺陷严重等级，缺陷紧急程度，缺陷覆盖范围等具体信息。

　　● Follow-up（跟踪）：包含缺陷的分析，决策，实现和测试，更正缺陷的新版本等详细信息。

　　● History（历史）：缺陷在生命周期中经历的状态变化和相应的日期。

　　● Comments（注释）：与缺陷相关的自由信息。

　　缺陷的等级被分为五级：
　　G0：系统无法运行；
　　G1：系统的关键功能受到严重影响；
　　G2：系统的关键功能受到部分或完全的无法工作，但有临时解决方案；
　　G3：系统的正常操作受到轻微影响；
　　G4：不回影响系统的操作，但如果改正的可以改善客户的对系统印象。

　　缺陷的优先级也分为五级：
　　U0：最高－必须尽可能马上解决；
　　U1：高－必须在下一个软件维护版本中解决；
　　U2：中－需在下一个软件发布版本中解决；
　　U3：低－在需要达到一定的质量等级是解决
　　U4：非常低－可根据产品所需负责的范围判断是否解决。

　　缺陷的覆盖范围也分为五级：
　　D0：微小的影响或编辑问题；
　　D1：对一个子系统的单独功能有影响；
　　D2：对一个子系统的至少一个功能有严重影响；
　　D3：对至少一个子系统有严重影响；
　　D4：对整个系统结构或多个子系统有影响。

　　2.2 状态与流程

　　2.2.1 缺陷跟踪的过程中存在以下状态：

　　CRE（CREated）：缺陷报告（FR）被发起人（Originator）创建；

　　OPEN（OPENed）：缺陷报告（FR）发送给缺陷报告负责人（FRR）做评估；

　　RFA（Request For Analysis）：FR发送给设计人员分析；

　　RFI（Request For Information）：FR的分析者向Originator 寻求相关信息（如Trace，发生缺陷的具体情况等）；