1、目的

本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性，以保证项目研发质量。

2、适用范围

适用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规范。

3、定义

3.1 术语

缺陷（Defect）：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。

Bug：缺陷一种表现形态，系统或程序存在的任何一种破坏正常运转能力的问题。

3.2 缺陷定义

（1）软件未达到需求规格说明书的功能； 

（2）软件出现了需求规格说明书指明不会出现的错误； 

（3）软件功能超出需求规格说明书的范围；

（4）软件未达到需求规格说明书未指出但应达到的目标； 

（5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。

4、缺陷生命周期

4.1 缺陷生命周期图

4.2 缺陷状态说明

5、缺陷处理过程

5.1 正常处理过程

（1）创建问题

在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清楚，并选择正确的选项，详细请参考5.4和5.5。

（2）指派问题

创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。

如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。

（3）确认问题

通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。

当创建者收到确认指派时，需要进行及时确认。如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。

如果问题确认指派次数大于6次时，需要进入“争议处理”流程，详细请参考5.2。

（4）解决问题

此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。

开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则请参考5.4中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。

如果Bug无法解决或修改影响比较大，可申请进入“延期解决”流程，请参考5.2中延期处理部分。

（5）验证问题

创建者需要及时对解决状态的Bug在对应版本上面进行验证。如果验证通过，则可关闭Bug；如果验证不通过，则激活此Bug，系统将自动指派回给解决者。

验证通过准则：相同的操作步骤，进行一定次数的验证测试都没有发生。

验证不通过准则：相同的操作步骤，全部或部分实际结果还会发生，验证不通过则激活Bug。

（6）关闭问题

通过验证的Bug，验证者需要注明验证结果并进行关闭操作，系统将指派给Closed。

如果关闭状态的Bug在之后版本又会发生，则激活此Bug，系统将自动指派回给解决者。

5.2 特别处理过程

（1）客户问题

客户反馈的问题可以由客户直接反馈或项目经理、市场部等了解到的客户问题，经确认后的Bug提交到测试管理系统，按照以上处理流程进行处理，由创建者或测试组进行跟踪验证关闭。

创建客户问题时，创建者需要在Bug标题开头标记为[客户问题]，测试组负责检查和更正。

（2）争议处理

当开发和测试工程师对某问题有争议并且多次沟通无果时（暂定为6次），可以注明双方的理由，并指派给项目经理进行处理。

项目经理可以召开评审会议，或者直接与双方沟通了解，并根据项目情况给出专业意见和最终决定。开发和测试工程师根据项目经理的最终决定执行。

（3）延期解决

当开发工程师对确认Bug进行解决时，发现或评估其解决时间紧或风险比较大等，可以说明原因或理由并指派给项目经理来确认。

项目经理可以召开评审会议，或者直接沟通了解，并根据项目情况给出最终决定。如果不同意，项目经理将此Bug指派回开发工程师，开发工程师继续分析和解决。如果同意，项目经理需要在Bug标题开头标记为[延期解决]和在处理状态选择“延期解决”，然后注明解决时间计划并指派回开发工程师，开发工程师根据解决时间计划来规划和解决此Bug。

5.3 缺陷管理工具

软件测试过程中所有缺陷要提交到公司测试管理系统进行跟踪管理。

（1）管理工具的作用

• 确保每个被发现的缺陷都能够被跟踪与处理。

• 收集缺陷数据并根据缺陷趋势曲线识别或报告测试状态。

• 收集缺陷数据并在其上进行数据分析，作为测试评估的依据。

（2）缺陷驱动原则

缺陷管理系统主要通过指派状态来驱动相关开发工程师、测试工程师和项目经理尽快地处理问题，以提高研发效率，所以会特别关注缺陷指派给谁和停留时间，并反馈在定期报告。

所以，缺陷驱动原则：尽量不要让缺陷挂在你身上。

5.4 缺陷属性定义

（1）缺陷相关属性

（2）缺陷类型说明

（3）严重程度定义

（4）优先级的定义

注：立刻、紧急、尽快的问题都要求在系统上线前解决。

（5）发生概率定义

（6）处理状态说明

（7）解决方案定义与规则

注：无法复现问题将作为风险评估点。

5.5 缺陷描述规范

（1）缺陷标题

 缺陷标题是对所提交缺陷的概述，需要简短而准确的描述出缺陷概要信息，并使用一些精炼的关键词，主要内容包括：位置+对象+动作+现象。

• 环境关键词：包括数据环境，时间环境，地点环境条件环境，描述缺陷发生时所处的背景环境，或正在执行的操作或所处的界面环境，如“在…”页面，“当…时…”，“在…过程中…”等；

• 动作关键词：引发缺陷所执行的操作，如“点…键”“选…选项”等；

• 对象的关键词：描述缺陷出现的对象，“页面”，“显示框” ，“图表”等；

• 现象的关键词：描述缺陷出现的现象，如“显示为负数”，“卡死”等。

根据上述关键词的组合来描写缺陷标题。

（2）重现步骤

在描述缺陷重现步骤的过程中，通常需要通过描述前提条件，测试步骤，实际结果，期望结果这四个方面清楚详细的描述缺陷。

• 前提条件

外部环境，这里包括网络环境，硬件环境和软件环境的状态。默认情况下，无需特殊说明，前提条件均为“系统正常运行”，其含义为网络正常，电脑硬件环境能支撑软件运行，系统软件配置情况正常。需要注意，软件环境有可能引发缺陷的功能模块所处的状态，以及重现该缺陷需要的模块相关状态或者特殊设置情况应该前在前提条件中做说明。

数据环境，对缺陷产生的所在案件或引发bug现象的数据输入和数据设计等应该在前提条件中做相应说明。

总之，这里对缺陷现象重现紧密相关的预先设置，或与缺陷模块相关联的预先设置都应该在前提条件中说明。

• 测试步骤

这里需要详细描述出重现缺陷的操作步骤，以便于重现缺陷，修复和验证缺陷。在描写测试步骤时应该注意以下几点：

精简：只描述缺陷必须的细节；

单一：每个缺陷单只报告一个缺陷；

步骤清晰：详细的、有序的描述出每一个步骤，包括输入的数据情况，执行的操作以及执行操作的界面。

操作量化：对操作次数的描述需要量化，如“连续3次点确认键”等，尽量避免出现“多次”等模糊的词。

• 实际结果

实际结果是指按照测试步骤操作后实际反映的情况，这里指的是缺陷的表现现象。这里应该详细描述出错误的现象，包括页面错误，连接错误，字符错误，业务流程错误，数据错误等。

• 期望结果

期望结果是指按照测试步骤操作，正常情况下正确执行测试步骤后应该满足设计要求的结果。对于不确定的期望结果就需要用到如建议，提示等关键字。

（3） 附件

为了方便开发工程师分析和解决，创建缺陷时需要添加必要的附件，包括缺陷现象图、测试的数据文档，测试时用到的其他特殊文件，测试脚本，操作步骤的录像等。

所以，测试人员在测试的过程中，要求每个缺陷有现象截图，以便协助开发人员快速定位问题。

原文链接：百度文库