缺陷管理，是软件研发过程中的一项过程管理。它与配置管理都是CMM2级一个KPA（关键过程域）。
一、明确几个缺陷管理的概念。
缺陷（Defect），就是静态的存在于软件工作产品（文档和代码）中的错误，也指在软件运行期间，由于这些错误所激发引起的和软件预期属性相偏离的现象。
错误（Error），代码中的错误。包括语法的错误（Syntax Error）和逻辑的错误（Logical Error）。
故障（Fault），软件在运行期间发生的意外状况。
失效（Failure），软件在运行期间发生意外状况，与用户的需求不符，导致功能不可用。
狭义的Bug就是错误，广义的Bug就是缺陷，在实际的工作中，缺陷和Bug意思是一样的。错误可能会导致故障，故障可能会导致失效，但是都不是必然的。
缺陷单（Bug Report）对于缺陷定位的书面报告，是修改、跟踪、证明、度量的依据。
二、区分是缺陷还是改进
缺陷就是被测试软件的实现与需求规格说明书描述的不一致，是由开发人员进行修改。
改进（Enhancement）是指用户的需求与需求规格说明书描述的不一致，是由需求人员进行修改。二者的现实意义：
（1）避免扯皮，明确责任
（2）涉及到费用问题（缺陷不需要缴费）
三、缺陷管理的目的：
（1）保证信息的一致性
（2）确保缺陷得到有效的跟踪和解决
（3）获得正确的Bug信息，用作缺陷分析和产品度量。
四、缺陷的管理工具
缺陷的管理工具发展经历了三个阶段，缺陷跟踪数据库、缺陷跟踪系统和缺陷管理系统。缺陷跟踪的成本越来越低，相关人员的工作量越来越少。跟踪体现在事前，而管理涉及到事前、事中、事后的整个过程，强调对缺陷的度量和分析。
第三代缺陷管理工具主要有，TD/QC（Mercury）、ClearQuest（Rational）、BMS（Microsoft）、Jira、SilkTest、Bugzilla、Butterfly、Mantis.
缺陷管理工具是通过设置角色来管理的，不同的角色具有不同的权限，从而实现对所属不同角色的账户进行管理。TD/QC中默认角色主要包括：
（1）developer 开发角色
（2）project manager 项目负责人角色
（3）QA tester 测试角色
（4）TD admin 管理员角色
（5）viewer 访客的角色
默认的角色，不可以被删除和修改他们的权限。如果是具有管理员的权限，可以自己创造相应的项目所需要的角色，上述的角色的权限是可以被继承的。
五、缺陷管理的流程
反映了缺陷的生命周期从发现提交缺陷报告单，经过若干个环节到最终权限得以修复并关闭Bug单为止。一般情况都经历了提交、审查分配、修改、验证、关闭几个阶段。不同的软件组织和软件产品，要求的缺陷管理流程是不一样的。
六、缺陷的属性
缺陷的属性包括：缺陷的状态、缺陷的严重级别、优先级别、缺陷引入和发现的阶段、缺陷所属的版本和模块、缺陷提交人和提交对象、缺陷发现、修改的时间和预期关闭的时间等。
缺陷的严重级别和优先级别没有任何的关系，是对缺陷从不同角度所进行的描述。
缺陷的严重级别就是缺陷对系统的破坏程度，分为致命（软件异常退出、系统崩溃、重要数据丢失），严重（单个功能失效引发多个功能均失效），一般（单个功能失效），提示或者建议（轻微的缺陷，比如控件没有对齐，错别字等）。
缺陷的优先级别就是缺陷修复的迫切程度，分为高（1-2个工作日解决），中（3个工作日内解决），低（方便时解决）。优先级可以有测试人员提交也可以由开发经理提交，但是建议由开发经理提交，因为可以从整个成本、工作量、风险、质量等因素综合考虑进行任务分配。
缺陷的状态，就是缺陷在生命周期某个时间点上的生命体征。缺陷管理流程的推进就是由缺陷的状态进行驱动的。包括：
（1）new,缺陷的初始状态。
（2）open,缺陷被确认，进行修改的状态。
（3）fixed（resolved），缺陷修改完成，等待验证的状态。
（4）closed,验证通过，结束状态。
（5）reopen,验证未通过，重新修改状态。
（6）rejected,拒绝修改状态。由开发决定。
（7）duplicate,重复缺陷，交回测试状态。
（8）abandon,rejected或者duplicate确认之后，抛弃缺陷的结束状态。
（9）postpone（delay），延迟修改的状态。开发和测试共同决定。
1-6为常用的缺陷状态。
七、缺陷单
缺陷单的内容：标题（发现了什么？）、操作步骤（缺陷得以发现的步骤）、输入（使缺陷重现的数据）、环境、附件（不好表述时使用，截图）、缺陷属性。
缺陷单书写的5C原则：
（1）正确Correct,不会产生歧义。
（2）清晰Clear,容易理解。
（3）简洁Concise,没有多余的东西。
（4）完整Complete,包含重现缺陷的完整数据。
（5）一致性Consistent,缺陷单格式要统一。
其他要领：
（1）再现，缺陷要至少出现三次，如果是间断的，至少要写清楚出现的频率。如果不能重现就需要进行技术加压和重新的构造，使缺陷再现。
（2）初步定位，提供影响缺陷得以重现的相关要素。
（3）推广，确定系统的其他部分是否会出现相同的问题。
（4）压缩，同简洁。
（5）祛除歧义，同准确。
（6）中立，要公正、客观的对缺陷进行描述，不应该用幽默或者讽刺的语言。
（7）评审，至少有一个同行，比如高级测试工程师或者测试经理，在提交之前先阅读一遍。