缺陷管理规程.docx

This model paper was revised by the Standardization Office on December 10, 2020
缺陷管理规程
缺陷管理规程
文档版本号：
文响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）
4
轻微缺陷
使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
5
建议（非缺陷）
从用户角度考虑在软件设计和功能实现等不完全合理之处提出建议。
缺陷优先级
序号
缺陷优先级
描述
1
立即解决
立即解决是指缺陷导致系统几乎不能使用或者测试不能继续，需立即修复
2
高优先级
高优先级是指缺陷严重影响测试，需要优先考虑
3
正常排队
正常排队是指缺陷需要正常排队等待修复；。
4
低优先级
而低优先级是指缺陷可以在开发人员有时间的时候再被纠正
一般地，严重程度高的软件缺陷具有较高的优先级，但是严重程度和优先级并不总是一一对应。有时候严重程度高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重程度低的缺陷却需要及时处理，反而具有较高的优先级。例如，公司名字和软件产品徽标是重要的，一旦它们误用了，这种缺陷是用户界面的产品缺陷，并不影响用户使用。但是它影响公司形象和产品形象，因此这也是优先级高的软件缺陷。
缺陷状态
缺陷状态
描述
New
已提交的缺陷
Open
确认“提交的缺陷”，等待处理
Rejected
不予解决，不需要修复或不是缺陷
Fixed
缺陷被修复
Reopen
缺陷未通过验证
Closed
确认被修复的缺陷，将其关闭
tostory
转为需求
缺陷发现的阶段
缺陷起源
描述
需求阶段
在需求阶段发现的缺陷
设计阶段
在设计阶段发现的缺陷
编码阶段
在编码阶段发现的缺陷
集成测试阶段
在集成测试阶段发现的缺陷
系统测试阶段
在系统测试阶段发现的缺陷
验收测试阶段
在验收测试阶段发现的缺陷
维护阶段
在维护阶段发现的缺陷
缺陷引入的阶段
缺陷引入阶段
描述
需求阶段
需求阶段引起的缺陷
设计阶段
设计阶段引起的缺陷
编码阶段
编码阶段引起的缺陷
缺陷管理流程
对于缺陷管理（注1），从发现缺陷到最终解决的流程图如下：
图1 缺陷管理流程图
【注1】可以采用自动化的BUG管理工具进行管理，例如公司的BUG追踪系统，生成缺陷跟踪表。
（1）缺陷的提交
发现的缺陷均提交给项目内指定人员，缺陷的状态为：New由指定人员进行评审、分配。
提交缺陷必须填写：缺陷的描述、优先级、严重性、缺陷的状态、解决人、发现缺陷的阶段，缺陷引入的阶段等信息。这些信息由提交缺陷的人负责填写。
测试人员登录BUG追踪系统，将缺陷的信息录入，然后提交给项目经理审核。
（2）缺陷的分配
项目组内对缺陷评审，决定缺陷计划解决的版本、时间和负责人员。
分配缺陷后的状态可能为：Open & Rejected
缺陷分配必须修改：缺陷的状态、解决人、计划关闭的版本和评审信息。这些信息由缺陷的解决人（一般是项目经理、开发经理或者是模块负责人）负责填写。
项目经理登录BUG追踪系统，接到测试人员提交的缺陷信息，对缺陷进行评审，如果评审缺陷通过，则该缺陷的状态变为Open，项目经理将该缺陷分配给开发人员解决；如果评审缺陷不通过，则该缺陷的状态变为Rejected，该缺陷不能作为缺陷进入缺陷管理流程。
（3）缺陷的解决
缺陷由指定的开发人员解决后，经过单元测试或代码走查，填写缺陷修改完成时间和缺陷处理结果描述。
解决后的缺陷的状态为：Fixed
解决缺陷必须修改：缺陷的状态、解决人、涉及到的代码等信息。这些信息由解决缺陷的人负责填写。
开发人员登录BUG追踪系统，修复该缺陷后，填写该缺陷的基本信息，缺陷状态变为Fixed，提交给CM工程师。
（4）缺陷的关闭
经过验证后的缺陷由测试专员关闭，状态为Closed，否则为：Reopen
缺陷的验证必须修改：缺陷的状态、解决人、解决的版本等信息。这些信息由测试工程师负责填写。
缺陷验证后的关闭必须修改：缺陷的状态、实际关闭缺陷的版本、解决的版本等信息。这些信息由测试专员负责填写。
测试工程师登录BUG追踪系统，对状态为Fixed的缺陷进行验证，通过验证，缺陷状态变为Closed，否则状态变为Reopen，提交给开发人员重新修复。
缺陷报告
阶段性的测试完成后，测试工程师将该阶段发现的缺陷进行统计分析，可以作为测试报告的一部分，包括：缺陷的数量、缺陷类型分类、缺陷分类百分比等。
遗留缺陷跟踪
跟踪遗留