缺陷管理流程说明.docx
- 文档编号:27553771
- 上传时间:2023-07-02
- 格式:DOCX
- 页数:23
- 大小:166.61KB
缺陷管理流程说明.docx
《缺陷管理流程说明.docx》由会员分享,可在线阅读,更多相关《缺陷管理流程说明.docx(23页珍藏版)》请在冰豆网上搜索。
缺陷管理流程说明
苏宁易购
缺陷管理流程
文档记录
修订记录
本次修订日期:
下次修订日期:
版本号
修订日期
变更概述
作者
修订显示
0.1
2012-8-30
初始版本
黄道勇
否
0.2
2013-07-1
修订
曹雄(IBM),丁晓东
否
批准者
此文档需要以下人员批准
姓名
职务
分发
此文档分发给以下部门或单位相关人员:
姓名
职务
1.综述
缺陷不仅仅是指软件的Bug,还包括需求、设计上的问题等;通常使用缺陷管理系统管理软件开发过程中所发现的缺陷。
苏宁所有项目均需要统一使用JIRA工具进行缺陷管理。
本文档将从缺陷定义、缺陷流程方面进行介绍,重点介绍缺陷管理的流程,涵盖的主要内容有流程目的、范围,缺陷的相关概念,缺陷管理的阶段和活动详细描述,以及主要角色和工作职责。
2.缺陷定义
2.1缺陷状态
2.1.1Jira缺陷流程图
2.1.2JIRA缺陷状态描述
序号
状态
描述
1
已提交
新建的,已提交的缺陷
2
开发安排中
缺陷被分配到具体解决人员
3
重新打开的
测试人员复测不通过,被重新打开的缺陷
4
开发解决
正在处理中的缺陷
5
已关闭
被测试人员关闭的缺陷,表明缺陷在本项目中生命周期结束
2.2解决结果
缺陷生命周期内的解决结果:
序号
解决结果
描述
1
未解决
新发现或者重新打开的缺陷,问题还未被处理
2
问题遗留暂不修复
本版本内不解决,在以后的目标版本中解决。
3
重复问题
重复的缺陷,不需要处理。
4
无法复现
问题无法重现,没有足够的证据证明该问题存在,无法处理。
5
非问题
经确认为不是问题,不需要处理。
6
需求变更
经确认为是需求,需要执行需求变更流程。
7
描述不完整
缺陷单内的信息不充分,不能支持开发分析。
8
已解决
已经被缺陷关系人处理修复的缺陷。
9
已验证通过
缺陷报告人验证开发解决修复的缺陷,并进行关闭
2.3JIRA状态与解决结果对应表
已提交
开发安排中
重新打开的
开发解决
已关闭
未解决
√
√
问题遗留暂不修复
√
√
重复问题
√
√
无法复现
√
√
非问题
√
√
需求变更
√
√
描述不完整
√
已解决
√
已验证通过
√
2.4缺陷严重程度
在测试过程中发现的缺陷按照严重程度分为五级:
阻塞,致命,严重,一般,提示。
只要满足定义描述中的一种情况,就可以判定为相应的严重程度。
对每个严重程度的缺陷,有对修复时间的要求和对复测时间的要求,需要开发团队和测试团队的响应配合,其详细定义及描述如下表:
严重程度
定义描述
响应时间要求
阻塞:
∙系统不可用且需要立即解决
例如:
1、重要功能未完成,主要业务流程不能完整进行,;
2、重要应用无法正常使用,重要业务流程错误或不完整;
3、应用程序崩溃
4、有其他计划执行的案例,由于此缺陷无法执行
∙测试人员发现阻塞级别的缺陷,需要立即汇报测试组长和测试经理
∙测试经理确认存在阻塞级别的缺陷,需要立即和项目经理、产品经理、开发经理进行沟通,协调解决
致命:
∙可能对业务功能和整个系统造成影响和损失
∙系统不可用
例如:
1、安装异常,安装的数据丢失;
2、因操作导致业务数据紊乱或丢失;
3、系统关键性能严重不达标,引起系统挂死或影响系统运行;
4、数据库设计未达到要求或需求规格;
5、关键业务逻辑错误;
6、内存溢出;
7、系统中断(含软件、硬件)或非法退出,且无法通过重启恢复;
8、系统死循环;
9、数据库死锁或数据库断连,且无法恢复;
10、数据通讯错误或接口不通;
11、对操作系统造成破坏
∙测试人员发现阻塞级别的缺陷,需要立即汇报测试组长和测试经理
∙测试经理确认存在阻塞级别的缺陷,需要立即和项目经理、产品经理、开发经理进行沟通,协调解决
严重:
∙系统中单元模块或功能有缺失或错误
∙问题不影响其他模块的正常运行
∙可以有替代办法
例如:
1、业务数据保存不完整或无法保存到数据库;
2、数据处理错误;
3、业务逻辑错误,功能接口错误;
4、功能模块反应时间超出正常合理时间范围,性能不达标;
5、重要日志记录信息不正确或应记录而未记录;
6、界面校验错误或者提示信息与异常处理不符;
7、前端未合理控制并发或连续点击动作,导致后台服务无法及时响应;
8、在产品声明支持的不同平台下,出现部分应用无法使用或错误;
9、重要单据打印格式不符合要求,查询结果错误;
10、严重的文档错误,报表数据错误;
∙测试经理或测试组长在确认严重级别的缺陷后,需要在4小时内和项目经理、产品经理、开发经理进行沟通,协调解决
一般:
∙基本不影响系统的运行和功能的实现,但是存在与标准、规范和定义的不一致
例如:
1、辅助说明描述不清楚,提示信息不明确或有错误;
2、输入输出不规范
3、长时间操作未给用户提示
4、输入限制未放在前台进行控制
5、拼写错误
6、界面不规范或者界面字段定义不准确
7、用户手册出现书写错误
8、某些查询、报表导出等实时性要求不高的辅助功能错误;
9、菜单布局,焦点控制,光标,滚动条等错误或不合理;
10、日志信息不够完整或不清晰;
11、其他的一般性数据处理错误,一般程序错误;
12、删除操作未给出提示
∙测试经理或测试组长当天与开发经理确认一般缺陷的修复计划
提示:
∙功能增强与改进,或是建议优化的项,并非系统缺陷
例如:
1、软件界面、菜单位置、工具条位置、相应提示不美观;
2、提示说明未采用行业规范语言;
3、显示格式不规范,文本未对齐;
4、界面优化、功能易用性优化建议
无要求
2.5缺陷引入阶段
编号
引入阶段
描述
1
需求阶段
在业务需求和系统需求进行评审,以挖掘需求中隐含的缺陷
2
设计阶段
概要设计和详细设计阶段,通过评审、同行评审等手段,提前发现设计过程中可能的缺陷
3
开发阶段
通过白盒测试、代码评审等方式进行动态或静态测试
4
测试阶段
由测试人员执行案例的方式,进行缺陷挖掘;由产品人员执行测试方式,进行需求确认和缺陷挖掘
5
日常运维
日常运维,线上维护阶段
注:
日常运维阶段引入的缺陷,属于运维故障,缺陷引入阶段不包含这个阶段。
2.6缺陷根源
缺陷根源可用于对测试过程中所发现的缺陷进行根因分析,识别根本原因,并按照度量结果采取有针对性的解决方法和改进措施。
在测试过程中产生的缺陷通常根源于以下几个方面
编号
根源
描述
1.
需求错误
由于错误的需求定义或已取消的需求引发的缺陷.
2.
开发错误
开发与需求不一致,需要开发修改的,开发造成的功能缺失,功能实现错误,功能不完善而引发的缺陷.
3.
设计错误
由产品设计不合理或不严谨引发的缺陷,包括系统设计,概要设计和详细设计.
4
编码错误
程序代码中的错误
5.
测试环境错误
测试环境搭建不合理或不严谨引发的缺陷
6
测试数据错误
测试数据准备不充分,不合理或不严谨引发的缺陷
7
部署错误
被测版本部署方式/方法的不合理,没按照正确的部署流程部署而引发的缺陷
2.7紧急程度
编号
紧急程度
描述
1
重大优先级
1级,要求立即解决;如系统崩溃,丢失数据或内存溢出等严重错误;紧急需求,如重大促销活动,领导决策优先考虑的需求等
2
高优先级
2级,要求当天内解决;如影响主营业务正常运行的错误
3
中优先级
3级,要求尽快解决;如主要的功能无效、新增功能建议;不影响正常业务运营的bug;紧急程度不高的一般需求
4
低优先级
4级,如非常用功能无效或对现有系统的改进
5
次要问题或需求
5级,拼写错误,文本未对齐等可改可不改的个人建议
2.8缺陷管理流程的角色和工作说明
角色
描述
工作说明
测试人员
测试执行人员
∙识别缺陷
∙记录并提交缺陷
∙执行复测,检验缺陷是否成功解决
∙重新打开或关闭缺陷
测试组长
测试组长
∙协助测试经理履行部分缺陷管理职能
∙进行测试执行识别、提交缺陷,并进行复测和关闭工作
测试经理
测试经理
∙审核缺陷的有效性
∙驳回不完整或描述有误的缺陷
∙识别重复缺陷和无效缺陷,
∙提交缺陷给项目经理审核分配
∙管理缺陷,跟踪缺陷状态
项目经理
项目经理
技术经理
开发组长
∙审核缺陷的有效性
∙驳回不完整或描述有误的缺陷
∙识别重复缺陷和无效缺陷,
∙评估需要延期修复的缺陷,
∙分发缺陷给开发人员、需求人员或者开发组长分析
修复人员
开发组长
∙识别重复缺陷或无效缺陷,退回给项目经理
∙分析缺陷,分发给开发人员修改,或转发给其他团队的适合的受理人
∙协调开发团队修复缺陷,参与评审或给出缺陷解决方案
∙对需要延期的缺陷返回给项目经理,给出意见或参与评审
开发人员
∙识别重复缺陷或无效缺陷,退回给项目经理
∙修改程序设计或代码的相关缺陷
∙修改后的代码或程序自测完成后,提交测试人员复测
需求人员
∙识别重复缺陷或无效缺陷,退回给项目经理
∙解决业务需求相关的缺陷
∙对需要延期的缺陷提供业务分析和决策
3.流程总览
3.1流程目的
缺陷管理流程的目的是规范在缺陷管理过程中各方的职责和任务,提高缺陷管理的效率。
同时,成功识别和解决测试发现的缺陷从而提高产品的质量,在测试过程中发生的所有缺陷都需要进行记录、分析、并查找根本原因,利用缺陷的相关度量指标进行统计分析,预测下一阶段的缺陷发生趋势。
缺陷记录和相应的缺陷报告为项目提供主要管理信息,也能对于缺陷的解决方案进行优先级排序。
3.2流程范围
本流程的使用范围包括了系统测试、系统集成测试和验收测试阶段,适用于测试人员、测试组长、测试经理、项目经理、开发组长、开发人员、需求人员等。
3.3流程开始
测试活动开始,测试执行人员识别出缺陷或继承上一版本暂不修复缺陷,本流程即开始。
3.4流程结束
缺陷的JIRA状态为”已关闭”,即为缺陷在本项目中流程结束。
缺陷的JIRA状态为”已关闭”,但解决结果为“问题遗留暂不修复”,视为该缺陷在项目中流程结束。
但是该缺陷在产品/系统维度的生命周期未终结,在后续的相关项目中该缺陷需要被重新打开进行修复和验证。
3.5解决结果说明
在解决结果被设置为以下选项时,需要确认相关的依据和证据已经被提交在JIRA中,才允许关闭缺陷:
✓设置解决结果为“重复问题”的缺陷,必须在备注中填写被重复的缺陷单号,并由测试经理或测试组长确认后允许关闭;
✓设置解决结果为“需求变更”的缺陷,必须在备注中填写需求变更的JIRA单号,并由测试经理或测试组长确认后允许关闭;
✓设置解决结果为“非问题”的缺陷,必须在备注中填写说明为非问题的详细原因,可以添加附件说明.,由测试经理或测试组长确认后允许关闭;
✓设置解决结果为“无法复现”的缺陷,开发人员必须和测试人员充分沟通,由测试经理或测试组长确认后允许关闭;
✓设置为“已解决”的缺陷,必须由缺陷提出人进行验证后关闭,并最终将解决结果置为“已验证通过”;
✓设置解决结果为“问题遗留不修复”的缺陷,必须是在JIRA中留下同意遗留的证据(领导备注确认遗留信息或附件领导同意遗留的邮件、ST聊天记录)。
最后由测试经理或测试组长确认有相关的证据后,允许在本项目中关闭缺陷:
⏹缺陷等级为阻塞、致命的缺陷,需要提供中心领导确认同意遗留的信息至JIRA中;
⏹缺陷等级为严重的缺陷,需要提供项目经理和对应产品部门的领导确认同意遗留的信息至JIRA中;
⏹缺陷等级为一般和提示的缺陷,需要提供项目经理和对应产品经理确认同意遗留的信息至JIRA中。
3.6遗留缺陷定期清理
各中心的测试负责人有责任参与和推动遗留缺陷的清理工作。
测试负责人需在每个项目开始前统计JIRA中对应系统遗留的缺陷清单,并在该项目发布会上,由中心领导和项目经理确定本次项目中需要修复的遗留缺陷。
确定本次项目需要修复的遗留缺陷后:
✓由项目测试经理/测试组长,在JIRA中重开确定的遗留缺陷;
⏹使用JIRA中“恢复开启问题”功能按钮,重新打开遗留缺陷(缺陷状态被置为“重新打开的”,解决结果被置为“未解决”);
⏹编辑缺陷,在“遗留缺陷修复项目”中填写本次项目名称。
✓遗留缺陷被修复,并在测试人员确认后,该缺陷的状态被置为“已关闭”、解决结果被置为“已验证通过”。
3.7缺陷关闭和删除
✓只有缺陷报告人才能将缺陷的JIRA状态置为“关闭”的状态。
(JIRA中设定的测试经理亦有关闭权限,以备不时之需)。
非缺陷报告人及测试经理关闭的缺陷,该缺陷必须重新打开。
✓只有缺陷报告人才能编辑缺陷,非缺陷报告人无权编辑缺陷。
✓任何缺陷一经提交,均不允许删除。
(JIRA中取消缺陷删除操作)。
4.
缺陷管理流程
4.1流程图
4.2流程解析
活动编号
角色
活动名称
活动说明
010
测试组长/测试工程师
(问题提出人)
识别缺陷
1.在测试执行过程中某一操作/过程/结果是否是缺陷
2.后续020编号活动
015
项目经理
继承本系统的历史遗留缺陷
1.在测试执行开始之前,项目经理确定需要继承并在本项目中修复的本系统历史遗留缺陷
2.后续017编号活动
017
测试组长/测试工程师
重开缺陷
1.测试经理对重新打开历史遗留缺陷(使用JIRA中“恢复开启问题”功能按钮)
2.缺陷状态设为“重新打开”
3.缺陷解决结果为“未解决“
4.编辑缺陷,添加“遗留缺陷修复项目”内容
5.后续070编号活动
020
测试组长/测试工程师
(问题提出人)
记录并提交缺陷
1.在jira中填写新的缺陷记录
(需满足JIRA问题单填写规范的要求)
2.后续030编号活动
030
测试组长/测试经理
判断缺陷是否有效
1.经测试经理/组长判断为非有效缺陷
2.后续120编号活动
3.经测试经理/组长判断为有效缺陷
4.后续040编号活动
040
开发工程师
(问题解决人)
是否非缺陷
1.开发人员判断为有效缺陷
2.后续050编号活动
3.开发人员判断为非有效缺陷
4.后续130编号活动
050
开发工程师
(问题解决人)
是否需求问题
1.开发人员分析是需求问题
2.后续150编号活动
3.开发人员分析判断为非需求问题
4.后续060编号活动
060
开发工程师
(问题解决人)
是否遗留
1.开发人员分析此缺陷需要遗留
2.后续170编号活动
3.开发人员分析此缺陷不需要遗留
4.后续070编号活动
070
开发工程师
(问题解决人)
修复缺陷,并发布安装新版本
1.开发人员开始修复缺陷
2.修复完成后提交发布申请单
3.后续080编号活动
080
测试组长/测试工程师
(问题提出人)
复测缺陷
1.测试人员按照版本发布单中列出的问题修复列表,复测/回归缺陷
2.复测/回归通过
3.后续090编号活动
4.复测/回归不通过
5.后续110编号活动
090
测试组长/测试工程师
(问题提出人)
是否通过复测
1.测试人员确认复测/回归通过
2.在缺陷单的备注中填写XXX版本复测/回归通过
3.后续100编号活动
4.测试人员确认复测/回归不通过
5.在缺陷单的备注中填写XXX版本复测/回归不通过
6.后续110编号活动
100
测试组长/测试工程师
(问题提出人)
关闭缺陷
1.此缺陷单流程结束
2.状态为“已关闭”
3.解决结果为“已关闭”或“问题遗留不修复”(原解决结果为“已解决”、“非问题”、“重复问题”、“需求变更”、“无法重新”的缺陷,在本活动之后,解决结果变为“已关闭”)
110
测试组长/测试工程师
(问题提出人)
重开缺陷
3.测试人员对开发人员提交的修复缺陷进行复测/回归,但不通过
4.把缺陷状态设为“重新打开”
5.缺陷解决结果为“未解决”
120
测试组长/测试经理
取消缺陷
1.所有经测试经理/组长判断的非有效缺陷,并在JIRA中设置为“重复问题”或“非问题”或“无法重现”
2.后续100编号活动
130
开发工程师
(问题解决人)
取消缺陷
1.所有经开发人员判断的非有效缺陷,并在JIRA中设置为“重复问题”或“非问题”
2.后续140编号活动
140
测试组长/测试经理
判断是否取消缺陷
1.测试经理判断来自研发提交的“非问题”或“重复问题”
2.测试经理同意研发的意见
3.后续100编号活动
4.测试经理不同意研发的已经
5.后续040编号活动
150
项目经理
判断是否需求问题
1.项目经理分析后判断是需求问题
2.执行160编号活动
3.项目经理分析后判断不是需求问题
4.后续060编号活动
160
项目经理
需求变更流程
1.项目经理记录需求变更说明
2.缺陷单解决结果为“需求变更”
3.开启需求变更流程
4.缺陷单备注中填写需求编号
5.后续100编号活动
170
开发工程师
(问题解决人)
遗留缺陷
1.开发人员把缺陷解决结果设置为“问题遗留不修复”
2.后续180编号活动
180
项目经理
是否同意遗留
1.项目经理分析判断此缺陷同意遗留
a)在JIRA中备注项目经理同意遗留
b)根据缺陷级别收集遗留缺陷必要的纪要信息(参考3.5章节)
2.执行190编号活动
3.项目经理分析判断此缺陷不同意遗留
4.后续070编号活动
190
测试组长/测试经理
Jira中是否有相关领导确认同意遗留的纪要信息
1.测试经理检查被遗留的缺陷单备注中是否有项目经理及相关领导的缺陷遗留纪要(参考3.5章节)
2.有匹配的缺陷遗留纪要
3.后续100编号活动
4.无匹配的缺陷遗留纪要
5.后续180编号活动
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 缺陷 管理 流程 说明