一般的，测试人员识别缺陷，其初始状态是“新建”；项目经理或技术领导分析缺陷，分配给合适的开发人员来解决，状态流转为“待解决”；指定的工程师解决缺陷，将其状态跟踪到“已解决”，测试人员复核该缺陷，如果复核通过，则关闭缺陷，状态是“已修复”，如果复核不通过，则打回到“待解决”。

缺陷标题

描述缺陷的标题

缺陷的详细描述

对缺陷的详细描述，缺陷如何复现的步骤等等，之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细

缺陷的严重程度

描述缺陷的严重程度，一般分为“致命”、“严重”、“一般”、“细微”四种

缺陷的紧急程度

描述缺陷的紧急程度，从1－4，1是优先级最高的等级，4是优先级最低的等级

缺陷的紧急程度与严重程度虽然是不一样的，但两者密切相关，往往的越是严重，就越是紧急，所以有些组织只用“严重程度”

缺陷提交人

缺陷提交人的名字

缺陷提交时间

缺陷提交的时间

缺陷所属项目/模块

缺陷所属的项目和模块，最好能较精确的定位至模块

缺陷指定解决人

缺陷指定的解决人，在缺陷“新建”状态为空，在缺陷“待解决”状态下由项目经理指定相关开发人员修改

缺陷指定解决时间

项目经理指定的开发人员修改此缺陷的deadline

缺陷解决人

最终解决缺陷的人

缺陷处理结果描述

对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改

缺陷处理时间

缺陷复核人

对被处理缺陷复核的验证人

缺陷复核结果描述

对复核结果的描述（通过、不通过）

缺陷复核时间

对缺陷复核的时间

测试环境说明

对测试环境的描述

必要的附件

对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的

除上述描述项外，配合不同的统计的角度，还可以添加上“缺陷引入阶段”、“缺陷修正工作量”等属性。

通常大家发现软件缺陷时会对软件缺陷进行分类，可分类的方式只有一种，就是严重级别,难道没有其它的分法吗。比如我们碰到下面这种情况，测试人员发现有一种功能是必需加入进去的，这时他与程序员说，程序员说没有时间或是不必要，这时这种情况则会形成两者的扯皮，最终的结果也就不了了知了，这样会挫伤测试人员的积极性，下次他们再也不会尽心的考虑产品的问题，只要可以运行就可以了。其实这种情况是可以解决的,下面我会提到一个新的软件缺陷分类概念，从而有效的解决这个问题。

在软件缺陷中不仅仅只是严重极别，更多的则是功能没有做到。说到这里也许大家都理解了，就是需求没有考虑到，可需求不会一次就很完美的，需要大家的共同努力，来不断的完善。那么怎样才能让测试人员提出的好的建议得到有效的执行？这就是我下面想说的。在软件缺陷中还有一种分法，跟据缺陷内容来分，主要分为需求Bug与程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都知道是由相关开发人员进行处理。下面主要讨论一下需求Bug，需求Bug从名称上来看就知道是要交由需求人员进行处理。可怎么处理，怎样在处理的过程中有效？这时，我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理。不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必须让程序员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求Bug。

这样处理有以下好处，首先需求Bug再不象以前，没有人进行确认，需求的处理人员本来就是需求人员，由他们确认与跟踪是最好不过的，因为他们对需求有绝对的权威。同时测试人员其实就是最早的用户，他们的需求就是用户的需求，这种方法加强了需求人员与测试人员的沟通，使需求得到有效的补充，从而让产品更加完善。还有测试人员从本质上来说与程序员还是对立的，这里如果为了这样一个不是软件本身问题的问题形成与开发人员的对立，则会出现赢得战役而丢失整个战争的情况，测试人员协调好与开发人员的关系，让他们更有效的对软件本身的缺陷形成有效的关注是最好的。还有最为关键的一点，测试人员的激情是最重要的，如果他们的想法没有得到体现，这时会渐渐的失去对测试的兴趣，从而软件的质量则会无法得到保证，通过这种方法可以让他们看到自己的建议可以通过对需求人员的反映得到实现，让他们时时觉得自己的想法是可以通过这种方法来有效的推行，这样工作的积极性才会有保障。

不过从实施的角度来说，还是有一定的困难的，首先要让大家改变以前那种凡是Bug就是由开发人员负责的观念，其次需求人员的工作量要加大，不过广泛的了解需求是他们的本份工作，想来不会很困难，还有必需要有有效的Bug管理工具，比如BugManage等等，不要出现那种对需求人员说了，可过两天就忘的情况出现，这时需求Bug的生命周期会出现跨越两个软件开发周期，因为有些需求会在下一版实现，这时测试人员需要延长对这些需求Bug的管理，不过我想这些需求是他们提出的，会有兴趣对这些Bug进行管理的。

缺陷能够引起软件运行时产生的一种不希望或不可接受的外部行为结果，软件测试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理一般而言需要达到以下的目标：

a,确保每个被发现的缺陷都能够被解决；

b,这里解决的意思不一定是被修正，也可能是其他处理方式（例如，在下一个版本中修正或是不修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致；

c,收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段；决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式；

d,收集缺陷数据并在其上进行数据分析，作为组织的过程财富。

上述的第一条是最受到重视的一点，在谈到缺陷跟踪管理时，一般人都会马上想到这一条，然而对第二和第三条目标却很容易忽视。其实，在一个运行良好的组织中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。

处于CMM第一级（或称为初始级）的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修改相应的软件。通常，没有人会去记录自己发现的缺陷。也没有人知道在新的软件版本里，究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。而且，只有在下一轮测试中才有可能知道那些所谓已被纠正了的缺陷是否真的被纠正了，更重要的是纠正过程是否引入了新的缺陷。

所以这样的软件组织的项目交货期（Release Date）表现出强烈的不可预测性。并且， 为了获得一个高质量的软件产品（如果能够的话），通常要在测试上花费大量的人力。

在CMM第二级（或称为可重复级）的软件组织中，软件项目会从自身的需要出发，制定本项目的缺陷管理过程。一个完备软件缺陷管理过程通常会包括如下几个方面：（1）提交缺陷

（2）分析和定位缺陷

（3）提请修改相应的软件

（4）修改相应的软件

（5）验证修改

项目组会完整地记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。

CMM第三级（或称为已定义级）的软件组织会汇集组织内部以前项目的经验教训，制定组织级的缺陷管理过程。并且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程。

从而，整个软件组织中的项目都遵循类似的过程来管理缺陷。好的缺陷管理实践成为所有项目的实践，而教训也为所有项目所了解。更重要的是，随着组织的不断发展完善，组织的过程会得到持续性的改进，所有项目的过程也都会相应的改进。

CMM第四级（或称为已管理级）的软件组织会根据已收集的缺陷数据，采用SPC的方法建立软件过程能力基线（Process CapabilityBaseline

这样的过程能力基线可以用来：(1)帮助未来的项目设立量化的项目质量目标；(2)理解和控制未来项目的实际结果。

在项目开始时，项目可以根据过程能力基线并结合本项目的实际情况来设立缺陷密度目标；而在项目的生命周期里，可以使用这样的过程行为图（Process Behaviour Chart）来理解和控制项目的实际的缺陷密度。当项目的实际缺陷密度在UCL和LCL之间波动时，可以理解为项目的开发过程处于受控状态。换言之，当项目的实际缺陷密度超越了UCL或LCL时，可认为某异常的原因（Special Cause）导致了这一现象，必须进行分析并实施某种行动来防止该异常的原因再次发生，从而确保开发过程始终处于受控状态。

与CMM第四级相比，CMM第五级（或称为持续优化级）更强调对组织的过程进行持续性改进，从而使过程能力得到不断的提升。

就缺陷管理而言，软件组织应当在量化理解其过程能力的基础上，持续地改进组织级的开发过程、缺陷发现过程，引入新方法、新工具，加强经验交流，从而实现缺陷预防（Defect Prevention）。

缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过找寻、分析和处理缺陷的共性原因，实现缺陷预防。

当实施了缺陷预防，缺陷密度的过程行为图将可表现为图1的形式。