软件缺陷管理制度[共8页].doc

软件缺陷管理规定
1 目的
缺陷是产品与规定要求不相符的部分。 软件缺陷是开发、 评审、 测试和使用
的过程中， 发现的软件产品与用户需求， 设计要求不符的部分， 这些部分造成使
用不方便或在某种程度上不能满足用户的要求。
软件缺陷的同义词有： bug ，issue ，defect ，问题等，这里通称为缺陷。
缺陷会存在于软件产品的整个生命周期中： 可以是软件代码的问题、 系统文
档（开发文档和测试文档等） 存在的问题， 或者是用户的帮助文档和使用指南方
面的问题等。
本文规定了软件缺陷登记跟踪处理的完整过程规范。
2 范围
适用于软件的整个生命周期。
不限于测试过程发现的缺陷。 评审，用户使用等过程中发现的缺陷都是应当
按照本流程进行登记跟踪管理。
3 职责
测试工程师： 在这里主要是指发现和报告缺陷的测试人员。 在一般流程
中，他需要对这个缺陷后续相关的状态负责： 包括相关人员对这个缺陷相关信息
的询问回答，以及验证测试。
开发工程师：这里主要指对这个缺陷进行研究和修改的开发人员。 同时，
他需要对修改后的缺陷在提交测试人员正式测试验证之前需要进行验证测试。
其他参与人：主要有项目负责人、测试经理、用户等组成。他们对缺陷
进行优先级划分，负责人进行确认并调解争议。
配置管理员：负责缺陷库的创建和权限管理， 并监督指导缺陷库的定制。
4 缺陷管理流程
缺陷管理流程图，下图描述缺陷管理的工作程序，缺陷的生命周期状态。
登记
缺陷发现后， 由测试人员登记到缺陷库。 具体项目也可以允许用户向缺陷库
提交缺陷。
缺陷登记后，提交前可以反复编辑，补充缺陷记录的信息。
测试人员必须保证登记的缺陷信息可以被处置负责人员理解， 具体要求参见

登记后的缺陷状态是“新” 。
提交
测试人员确认缺陷已经表述清楚，可以提交缺陷。
提交后的缺陷状态是“已提交”
缺陷提交前必须分配一个具体的开发人员负责，如果测试人员不确定谁负
责，可以把缺陷分配给测试经理或项目负责人，再由他们重新分配负责人。
处置
开发人员确认缺陷是自己负责后， 开始着手处理， 并修改缺陷的状态为 “打
开”，表示缺陷正在处理中。
已经打开的缺陷也可以修改负责人。
解决
问题解决后， 填写解决处置记录， 写明造成缺陷的原因和解决方案， 改变缺
陷状态为“已解决” 。
处置记录必须符合 规定的要求。
如果开发人员发现如下情况，可以把缺陷状态置成“否决”
条件 处置意见 处置记录
缺陷不可再现 不可再现 无
与先前登记的缺陷重复 重复问题 先前登记缺陷的编号
不是缺陷，是测试人员理解错误 不是问题 说明需求和设计中对应的内容，以证明
软件行文符合预期要求。
缺陷轻微， 且修改困难， 或修改易 不处理 说明缺陷和需求不相抵触，且轻微
导致更大的潜在问题 说明处理的困难和风险
如果按照开发计划， 缺陷发生的功 推迟处理 引用开发计划，写明何时处理。
能不属于当前开发阶段必须的完 需要项目负责人确认
成的
验证
测试人员对 “已解决” 状态的缺陷进行重新测试， 测试步骤应当按照登记的
可重现步骤进行。