1、 缺陷跟踪管理的目标
缺陷能够引起软件运行时产生的一种不希望或不可接受的外部行为结果，软件测试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理一般而言需要达到以下的目标：
确保每个被发现的缺陷都能够被解决;这里解决的意思不一定是被修正，也可能是其他处理方式(例如，在下一个版本中修正或是不修正)，总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致;
收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段;决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。
收集缺陷数据并在其上进行数据分析，作为组织的过程财富。
上述的第一条是最受到重视的一点，在谈到缺陷跟踪管理时，一般人都会马上想到这一条，然而对第二和第三条目标却很容易忽视。其实，在一个运行良好的组织中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。
2、 缺陷的描述
对缺陷的描述应该包含以下的内容：
|
可追踪信息 |
缺陷ID |
唯一的缺陷ID，可以根据该ID追踪缺陷 |
|
缺陷基本信息 |
缺陷状态 |
缺陷的状态，分为“待分配”、“待修正”、“待验证”、“待评审”、“关闭” |
|
缺陷标题 |
描述缺陷的标题 | |
|
缺陷的严重程度 |
描述缺陷的严重程度，一般分为“致命”、“严重”、“一般”、“建议”四种 | |
|
缺陷的紧急程度 |
描述缺陷的紧急程度，从1－4，1是优先级最高的等级，4是优先级最低的等级 | |
|
缺陷提交人 |
缺陷提交人的名字（邮件地址） | |
|
缺陷提交时间 |
缺陷提交的时间 | |
|
缺陷所属项目/模块 |
缺陷所属的项目和模块，最好能较精确的定位至模块 | |
|
缺陷指定解决人 |
缺陷指定的解决人，在缺陷“提交”状态为空，在缺陷“分发”状态下由项目经理指定相关开发人员修改 | |
|
缺陷指定解决时间 |
项目经理指定的开发人员修改此缺陷的deadline | |
|
缺陷处理人 |
最终处理缺陷的处理人 | |
|
缺陷处理结果描述 |
对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改 | |
|
缺陷处理时间 |
缺陷处理的时间 | |
|
缺陷验证人 |
对被处理缺陷验证的验证人 | |
|
缺陷验证结果描述 |
对验证结果的描述（通过、不通过） | |
|
缺陷验证时间 |
对缺陷验证的时间 | |
|
缺陷的详细描述 |
对缺陷的详细描述；之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细 | |
|
测试环境说明 |
对测试环境的描述 | |
|
必要的附件 |
对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的 |
3、 缺陷管理的一般流程
文章来源于领测软件测试网 https://www.ltesting.net/
