PAGE\*Arabic1/NUMPAGES\*Arabic2
软件缺陷管理规定
目的
为加强公司开发、测试环境的管理，确保开发、测试环境项目文档、代码及数据安全，明确开发测试环境软硬件平台的职责维护职责，保证开发、测试环境的稳定运行，提高开发效率，特制定本文件。
范围
适用于软件研发项目实施过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规范。
职责
研发负责人：负责本文件的实施和监督管理。
软件测试人员：负责对软件测试，提交测试报告和测试过程中发现的bug。
软件开发人员：负责软件缺陷的修复。
软件配制管理人员：负责软件缺陷生命周期过程中与软件配置有关过程的管理，例如配置库的checkin等。
概念
软件缺陷管理（DefectManagement）是在软件生命周期中识别、管理、沟通任何缺陷的过程（从缺陷的识别到缺陷的解决关闭），确保缺陷被跟踪管理而不丢失。需要使用缺陷跟踪管理工具来帮助进行缺陷全流程管理。本公司使用的缺陷管理工具为XXXX
//常用的缺陷管理工具有：Bugzilla、Mantis、JIRA、Bugfree、TestDirector、ClearQuest、MercuryQualityCenter、JBOSS、Bugzero、BugTracker、KisTracker等等
分类
缺陷（defect）：存在于软件之中的偏差，可被激活，以静态的形式存在于软件内部，相当于bug;
故障（Fault）：软件运行中出现的状态，可引起意外情况，若不加处理，可产生失效，是一个动态行为；
失效（Failure）：软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户无法完成所需要的应用。使用要求
严重程度
第一个等级：致命的软件缺陷(Fatal)造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等。
第二个等级：严重错误的软件缺陷（critical）系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件。
第三个等级：一般错误的软件缺陷（major）次要功能没有完全实现但不影响使用。如：提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等。
第四个等级：较小错误的软件缺陷（Minor）使操作者不方便或遇到麻烦，但它不影响功能性的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚。
第五个等级：建议问题的软件缺陷（Enhancemental）由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。
优先级
代号
级别
描述
P3
建议
建议增加或修改优化操作。
P2
一般
功能没有完全实现但是不影响使用。
P1
高
主要功能丧失，基本模块缺失等问题。
P0
紧急
可稳定复现的造成系统崩溃、无响应、卡死的问题。
状态
序号
状态
描述
1
Submitted
已提交的缺陷
2
Open
确认“提交的缺陷”，等待处理
3
Rejected
拒绝“提交的缺陷”，不需要修复或不是缺陷
4
Resolved
缺陷被修复
5
Configed
缺陷涉及到的代码被受控
6
Reopen
缺陷未通过验证
7
Verify
缺陷验证通过
8
Closed
确认被修复的缺陷，将其关闭
缺陷产生的类型
类型代码
缺陷类型
描述
10
功能
影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷。
20
逻辑
需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。
30
接口
与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
40
标准
编码/文档的标准问题，例如缩进、对齐方式、布局、组件应用、编码和拼写错误等
50
性能
处理速度慢、因文件的大小而导致系统崩溃等
60
语法
不符合所用程序设计语言的语法规则
70
设计
设计错误。
处理流程
测试提交的Bug处理
发现的缺陷均提交给项目内指定人员（可以是项目经理或者开发经理），缺陷的状态为：NEW,由指定人员进行评审、分配。
提交缺陷必须填写：缺陷的描述、优先级、严重性、缺陷的状态、解决人、发现缺陷的阶段，缺陷引入的阶段等信息。这些信息由提交缺陷的人负责填写。
缺陷分配