禅道bug流程样本.docx
- 文档编号:4351754
- 上传时间:2022-11-30
- 格式:DOCX
- 页数:10
- 大小:246.35KB
禅道bug流程样本.docx
《禅道bug流程样本.docx》由会员分享,可在线阅读,更多相关《禅道bug流程样本.docx(10页珍藏版)》请在冰豆网上搜索。
禅道bug流程样本
bug管理规范及流程
1 概述
本文档定义bug整个生命周期,规范bug解决方案及管理流程。
Bug在流转过程中有章可循。
规范bug严重级别与bug解决优先级,使开发人员与测试人员能依照此文档精确判断bug严重限度并加以解决;
2 核心角色及职责
角色
职责
测试工程师
1.依照规范提交bug;
2.及时验证bug与否已解决;
3.及时关注开发回绝bug,和有关人员沟通讨论解决方式;
测试负责人
1.审核测试工程师提交bug;
2.定期reviewbug,报告现状,并给出解决意见;
开发工程师
1.以优先级为根据分析解决bug
研发经理
1.定期reviewbug,对bug多模块加强codereview和单元测试;
2.分析bug解决进度,对产品质量及进度进行风险评估;
产品
1、当开发和测试存在乎见分歧时,进行需求确认
2、从产品角度划分bug修改优先级;
3 Bug生命周期
4 Bug解决方案
Bug解决方案分为:
已解决、外部因素、设计如此、重复bug、无法重现、延期解决、不予解决
一、无争议类
A.解决方案已解决
开发已修复bug:
bug解决方案置为已解决;同步添加阐明错误因素、解决办法;
示例:
问题因素:
未作条件判断
解决办法:
进行合理边界判断
B.解决方案外部因素
开发以为不是bug:
bug解决方案置为外部因素;指派给bug提出者;同步注明置为外部因素理由;
示例:
C.解决方案无法重现
无法重现bug:
重要依赖日记分析问题因素,然后进行相应修改;开发修改后,测试追溯3个版本、或者使用测试工具重复测试,如没有重现则先关闭;并注明关闭版本号;
D.解决方案延期解决
需延期bug:
将bug解决方案置为延期解决,并注明延期理由;
示例:
E.解决方案重复bug
开发以为bug重复:
将bug解决方案置为重复bug,并标注重复bugID,并备注因素。
二、争议类
测试、开发有争议bug:
备注争议内容,并指派给相应产品,进行讨论确认修改方案;讨论后产品备注解决办法,并指派给相应开发or测试;
A、产品确认需要修改bug:
将bug指派给相应开发人员,并注明修改内容;
示例:
B、产品确认不需要修改bug:
将bug解决方案置为设计如此、不予解决,并注明不需要修改因素,指派给bug创立人员;
示例:
三、测试关注点:
开发已修复,测实验证通过bug:
关闭bug,并注明通过或者现状;
示例:
验证通过
开发已修复,测实验证不通过bug:
将bug激活,并依照实际状况注明激活理由;
示例:
5 Bug状态
激活:
开发尚未解决问题状态;
已解决:
开发人员已确认或已修复问题状态;
已关闭:
测实验证,拟定已解决问题状态;
6 Bug严重限度
1级:
不能执行正常功能操作,或者因产品因素导致系统死机,需立即修复问题
示例:
程序无法启动,或者登录;
程序崩溃、停止运营,系统死机,无法进行下一步操作
2级:
某些功能存在严重缺陷,尚可继续测试,不影响产品稳定性;
示例:
偶现程序崩溃、停止运营
功能未实现
数据不同步
功能错误,无法进行后续操作
3级:
次要功能或者界面存在某些错误,不影响正常测试;
示例:
界面UI显示和效果图不一致;
提示语不对的;
错别字;
查询成果显示错误
4级:
测试对于产品某些改进建议;
7 Bug优先级
4级:
对产品影响比较小,在时间不容许状况下可以暂时不修改;
3级:
必要修改,不一定立即修改,需讨论拟定在某个特定里程碑前修改完;
2级:
必要在版本发布之前修改完;
1级:
影响测试,需及时或者下一种版本修复;
8 其她注意事项
1) 开发人员没关于闭bug权限,所有问题均需通过测实验证无误后才可关闭;
2) 开发、测试双方有争议bug,必要通过产品确认才可进行下一步操作;
3) 测试需及时验证已修复bug;
4) 产品人员可以依照产品阶段性需求重新分派bug解决优先级;
5) 重新指派bug后,需要口头或者QQ告知对方;
6) bug优先级划分比较重要;
7)开发人员解决bug时,动了已经测试通过模块,需要备注一下影响范畴;
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 禅道 bug 流程 样本