缺陷管理规程.docx
《缺陷管理规程.docx》由会员分享，可在线阅读，更多相关《缺陷管理规程.docx（11页珍藏版）》请在冰点文库上搜索。
缺陷管理规程
缺陷管理规程
文档版本号：
文档编号：
江通服_TST_05
文档密级：
内部公开
归属部门/项目：
研发部
编写人：
朱佳佳
生效日期：
2018-05-10
版权信息
本文件涉及之信息，属江西省通信产业服务有限公司所有。
未经江西省通信产业服务有限公司允许，文件中的任何部分都不能以任何形式向第三方散发。
文档修订记录
版本号
修订日期
修订人
修订说明
修订状态
审核日期
审核人
批准人
2018-05-02
朱佳佳
新增缺陷管理规程
A
2018-05-02
熊婧汝
李伟
2018-05-10
朱佳佳
评审并发布正式版本
M
2018-05-10
熊婧汝
李伟
修订状态：
A--增加，M--修改，D--删除
日期格式：
YYYY-MM-DD
目 录
1.目的
缺陷管理的最终目标是最大限度地减少缺陷的出现率，从而提高软件产品的质量。
细分为：
1）从缺陷发生到结束的全生命周期进行跟踪管理，尽可能发现所有的缺陷，确保每个被发现的缺陷都能够被解决；
2）收集缺陷数据并根据缺陷趋势图识别测试过程的阶段；可以通过缺陷趋势图来确定测试过程是否结束；
3）在已收集到的缺陷数据的基础上进行统计分析。
总结缺陷出现的原因、类型和规律，采取相应措施避免该类型缺陷再次出现，并在开发过程的早期阶段予以确定，起到缺陷预防的作用，并作为组织的过程财富。
本规程规定了缺陷管理流程以及缺陷统计分析要求，项目组必须严格遵循本规程要求保证在较短的时间内高效率地解决所有缺陷，缩短软件开发测试进程，提高软件质量，减少开发和维护成本。
2.角色与职责
角色
职责
项目经理
评审缺陷
测试工程师
提交，验证缺陷
软件工程师
修改缺陷
CM工程师
在缺陷管理中受控已解决的缺陷代码
3.入口准则
●缺陷发生时
4.输入
无
5.主要步骤
5.1.定义缺陷
是对软件产品预期属性的偏离现象，它包括检测缺陷和残留缺陷。
每一个软件组织都知道必须妥善处理软件中的缺陷。
这是关系到软件组织生存、发展的质量根本。
缺陷属性
属性名称
描述
缺陷标识
缺陷标识是标记某个缺陷的一组符号。
每个缺陷必须有一个唯一的标识。
缺陷类型
缺陷类型是根据缺陷的自然属性划分的缺陷种类。
缺陷严重程度
缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
缺陷优先级
缺陷的优先级指缺陷必须被修复的紧急程度。
缺陷状态
缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
缺陷发现的阶段
指缺陷引起的故障或事件第一次被检测到的阶段。
缺陷引入的阶段
指引入缺陷的阶段。
缺陷类型
缺陷类型编号
缺陷类型
描述
10
功能
影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。
并且设计文档需要正式的变更。
如逻辑，指针，循环，递归，功能等缺陷。
20
逻辑
需要修改少量代码，如初始化或控制块。
如声明、重复命名，范围、限定等缺陷。
30
接口
与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
40
标准
编码/文档的标准问题，例如缩进、对齐方式、布局、组件应用、编码和拼写错误等。
50
性能
处理速度慢、因文件的大小而导致系统崩溃等。
60
语法
不符合所用程序设计语言的语法规则。
70
设计缺陷
设计错误、设计不符合用户习惯等。
缺陷严重程度
序号
缺陷严重等级
描述
1
致命缺陷
数据丢失，数据计算错误、数据传递错误、对数据库造成破坏，造成操作系统或其他支撑系统崩溃、非正常关闭和非正常死机，不能执行正常工作功能或重要功能。
或者危及人身安全。
2
严重缺陷
应用系统崩溃、非正常关闭和无响应，但没有造成数据丢失。
系统的主要功能不能正确实现或不完整，严重地影响系统要求或基本功能的实现，且没有办法更正。
（重新安装或重新启动该软件不属于更正办法）
3
一般缺陷
规定的非主要功能没有实现或不完整、影响系统的运行，设计不合理造成性能低下，比较严重地影响系统要求或基本功能的实现，但存在合理的更正办法。
（重新安装或重新启动该软件不属于更正办法）
4
轻微缺陷
使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
5
建议（非缺陷）
从用户角度考虑在软件设计和功能实现等不完全合理之处提出建议。
缺陷优先级
序号
缺陷优先级
描述
1
立即解决
立即解决是指缺陷导致系统几乎不能使用或者测试不能继续，需立即修复
2
高优先级
高优先级是指缺陷严重影响测试，需要优先考虑
3
正常排队
正常排队是指缺陷需要正常排队等待修复；。
4
低优先级
而低优先级是指缺陷可以在开发人员有时间的时候再被纠正
一般地，严重程度高的软件缺陷具有较高的优先级，但是严重程度和优先级并不总是一一对应。
有时候严重程度高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重程度低的缺陷却需要及时处理，反而具有较高的优先级。
例如，公司名字和软件产品徽标是重要的，一旦它们误用了，这种缺陷是用户界面的产品缺陷，并不影响用户使用。
但是它影响公司形象和产品形象，因此这也是优先级高的软件缺陷。
缺陷状态
缺陷状态
描述
New
已提交的缺陷
Open
确认“提交的缺陷”，等待处理
Rejected
不予解决，不需要修复或不是缺陷
Fixed
缺陷被修复
Reopen
缺陷未通过验证
Closed
确认被修复的缺陷，将其关闭
tostory
转为需求
缺陷发现的阶段
缺陷起源
描述
需求阶段
在需求阶段发现的缺陷
设计阶段
在设计阶段发现的缺陷
编码阶段
在编码阶段发现的缺陷
集成测试阶段
在集成测试阶段发现的缺陷
系统测试阶段
在系统测试阶段发现的缺陷
验收测试阶段
在验收测试阶段发现的缺陷
维护阶段
在维护阶段发现的缺陷
缺陷引入的阶段
缺陷引入阶段
描述
需求阶段
需求阶段引起的缺陷
设计阶段
设计阶段引起的缺陷
编码阶段
编码阶段引起的缺陷
5.2.缺陷管理流程
对于缺陷管理（注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，提交给开发人员重新修复。
5.3.缺陷报告
阶段性的测试完成后，测试工程师将该阶段发现的缺陷进行统计分析，可以作为测试报告的一部分，包括：
缺陷的数量、缺陷类型分类、缺陷分类百分比等。
5.4.遗留缺陷跟踪
●跟踪遗留缺陷
对于发布的产品，需要跟踪产品发布后的运行情况。
对遗留的缺陷跟踪记录并分析其影响范围，直到遗留缺陷形成解决结果。
●产品发布后发现的缺陷
产品发布后的缺陷来源有：
客户服务部门客户服务人员、咨询实施部项目实施工程师、客户、开发和测试人员。
该类缺陷发现后需要提交给项目组，纳入缺陷管理，该类缺陷的发现阶段标识为“发布后”，便于分析原因。
5.5.缺陷分析
通过缺陷的数据分析，总结缺陷出现的原因、类型和规律，采取相应措施避免该类型缺陷再次出现，提高产品质量。
●产品缺陷趋势图
统计项目组阶段缺陷的趋势图，用于分析产品的质量。
●O/C（open/close）图分析
测试人员在每个项目的每轮测试结束后，将缺陷分析结果写在《测试报告》中，提交项目经理审批。
可按缺陷的来源、类型、严重性等对缺陷数据进行分析。
6.输出
●《缺陷跟踪表》
7.出口准则
●缺陷关闭
8.引用文档
无
9.使用模板
●《测试报告》
●《缺陷跟踪表》
升级会员 