c）过程

　　算术，初始化，控制或顺序，静态逻辑等。

　　其他：控制流或处理错误。

　　d）数据：类型，结构，初始值，其他。

　　e）代码：输入、拼写、风格错误，编码错误。

　　f）文档：文档与程序不对应，或者不全。

　　g）标准：未符合工业或供应商标准、代码标准、命名规范等。

　　h）其他：不在前述分类中

　　i）重复：错误描述重复。

　　j）不是问题：因误解产生，文档不够细，将正确行为理解为错误的输出。

　　k）坏单元：由随机的硬件故障引起

　　l）需要根本原因：开发人员不提供根本原因解释，但错误已关闭。

　　m）未知的：再现性差的问题

　　3）错误何时结束？关闭日期和注入、检测发现和删除阶段

　　可能出现错误的项目阶段：包括需求、设计、实现、组件测试、集成测试、系统测试、验收测试、发布后。

　　可以用缺陷去除模式分析错误被注入、检测发现和删除的阶段。

　　4）完成错误跟踪数据库

　　错误的注入阶段、发现阶段、去除阶段、严重度、优先权、根本原因等体现错误的基本特征，测试人员、子系统、所有者、配置、质量风险等体现错误跟踪过程中的变化内容，这里有测试任务、修复任务分配问题，回归测试可能多次反复。

　　7、从错误跟踪数据库中抽取度量

　　1）缺陷去除统计：发现/修复图表

　　在系统测试阶段，记录每日的公开与关闭错误数量，就可以形成一个趋势图表，可以包含累计发现/修复、延时的数量，及每日的公开与关闭和延时错误数量，根据这些数量与时间的对应关系就可以做一组折线图反映发现/修复、延时的发展趋势。

　　开发结束，错误数虽然未知但已固定。累计发现曲线与修复曲线开始都是上升势头。中间修复、测试的过程中，修复一个问题，可能引发多个问题。

　　如果累计发现的曲线不平滑，说明很多问题等待发现：开发人员能力不一致或者重视程度不一致，或者测试系统设计或用例数据有问题，或者测试人员能力和状态不一致。

　　当累计发现的曲线低头趣平时，说明发现错误的能力在衰退或者测试接近尾声。当累计发现曲线与修复曲线交叉或接近时。可以对外发布产品了。可能还有未发现的问题。

　　开发过程中，当开发人员从开发程序转入修复错误时，公开累积曲线即累计发现曲线出现一个尖峰，表示部分错误已被消除。

　　如果出现成批延迟的情况，关闭累积曲线可能是跳跃似的，即体现成批的错误在较长时间之后才被消灭。

　　如果没有错误跟踪管理过程，哪些问题已经修复就无法确认。如果从开发到报告错误的时间太长，开发者可能忘了原来的编程思路；或者从发现到报告错误的时间太长，相关人员可能不清楚错误报告的含义。这样不利于错误修复，控制适度紧凑的公开/关闭节奏（例如不超过一周），有利于提高工作效率。

　　2）统计发生错误的根本原因

　　根据根本原因分析的结果和错误分类进行统计，使用前面的错误分类信息以及处理过程信息，为以后的开发和测试工作提供借鉴。

　　应根据分类发生错误的比率，分配注意力，正如前面质量风险优先级数所提示的那样，影响严重的需要优先修改的易发错误当首先进行整改修复，其实这里可能包含两个方面，一是开发人员认识层面的重视，二是错误的消除，接下来测试人员还要进行验证。

　　3）统计开发小组响应？D？D平均关闭周期

　　可以使用每日平均关闭周期和滚动（累计）平均关闭周期，检查错误报告？D？D修复？D？D测试环节有没有问题。