BUG处理流程说明

一、        BUG处理流程图:

流程描述:

1、  测试人员发现bug提交给开发。

2、  开发人员判断是否是bug。

3、  如果是bug,进行修改,修改完成后更改bug状态为已解决。

4、  如果不是bug,退回给测试人员并描述退回原因,或为设计如此,或为外部原因,或者不能重现。

5、  开发人员修改完成的bug,由测试人员进行验证,确认修改正确,关闭bug。

6、  验证未通过的bug重新激活,开发人员继续修改,直至验证通过,关闭bug。

7、  测试人员需要对开发人员退回的bug进行确认。

8、  确认不是bug关闭。

9、  如与开发人员意见不一致,认为是bug,需提交项目负责人仲裁。

10、项目负责人确认是bug由开发人员修改,不是bug由测试人员关闭。

注:除提交项目负责人仲裁环节外,其他环节都可以在禅道上完成。

二、    各角色应关注的状态

1.       开发人员:激活、重新打开

激活:开发人员要对处于激活状态的bug进行处理,处理后将其状态置成“已解决”、“设计如此”、“无法重现”、“外部原因”、“重复bug”或“延期处理”。

重新打开:重新打开的bug是已解决的bug经过测试人员验证,未修改正确,需要继续修改。

2.       测试人员:已解决、无法重现、设计如此、外部原因、延期处理

已解决:测试人员发现状态为“已解决”的BUG,要及时验证,如果确实已解决,要将其置为“关闭”。否则“重新打开”

无法重现:测试人员发现状态为“无法重现”的BUG,要及时修改,把步骤描述清楚,并将其状态置为“重新打开”。

设计如此:测试人员发现状态为“设计如此”和“外部原因”的BUG,要及时通知项目经理,由项目经理来决定是否修改;对“延期处理”的问题要进行定期跟踪,如发现问题没有按注释进行修改要及时通知开发人员或汇报给相关负责人。

3.       项目经理:设计如此、外部原因、延期处理

设计如此:因为这些BUG都是测试人员和开发人员有争议的BUG,因此项目经理必须及时关注这些BUG,及时给出合理的定夺,如果不需修改把状态置成“关闭”,如果需要立刻解决置成“重新打开”,否则置成“以后解决”。同时,项目经理也要关注“延期处理”的BUG,以免其被漏掉或遗忘从而影响到项目上线。

三、    缺陷严重级别及类型定义

u  致命错误包括:

1.  造成系统崩溃、死机

2.  造成程序非法退出、死循环、通讯中断或异常

u  严重错误包括:

1.        功能不符

2.        数据流错误

3.        程序接口错误

4.        密码明文显示

u  一般错误包括:

1.        界面错误

2.        打印内容、格式错误

3.        输入限制未放在前台进行控制

4.        删除操作未给出提示

5.        辅助说明描述不清楚

6.        显示格式不规范

7.        长时间操作未给用户进度提示

u  建议(非缺陷)

1.  修改后可获得更好的用户体验

四、   缺陷优先级定义

1、  高:导致测试暂停,无法进行;必须立即解决,优先级高于开发工作。

2、  中:导致部分功能无法测试;需要优先解决,解决周期2天。

3、  低:不影响测试的进行;可在方便时解决,解决周期3-5天。

五、   必须注意的问题

1.        开发人员不能直接关闭bug,关闭bug必须由测试人员完成。

2.        在进行问题处理的时候必须要添加注释,描述不是问题的原因、以后解决的计划版本时间等等。

3.        大家在处理自己的问题时,即使这个问题不是自己的程序引起,也最好不要把问题置之不理,因为这个问题是在你这块表现出来的,到底哪里出问题应该比较清楚,跟其他相关人沟通相对比较容易,这样可以降低沟通成本,劲量做到“首位责任制”或“问题到此为止”

六、    禅道使用说明

1、  禅道地址:http://172.21.39.42/www/index.php

2、  测试人员提交bug

登录成功后,选择测试试图,然后从下拉列表中选择项目,进入对应项目。

点击创建bug,进入bug编辑界面。

选择bug影响版本、当前指派人、输入bug标题和bug重现步骤。

选择bug类型及严重程度、选择bug出现的系统及浏览器、抄送给项目负责人或其它相关人员、插入bug截图,点击保存bug提交完成。

3、  开发人员处理bug

开发人员登录系统后,点击测试试图下的缺陷管理,选择自己所在的项目,进入相关bug页面,发现有指派给自己的bug,点击bug标题,进入bug详细描述。

在浏览bug重现步骤定位bug后,进行bug的修改,bug处理完成后点击解决,进入下一步。如果认为该bug不是问题,也点击解决,进入下一步处理。

如果bug修改完成,解决方案选择已解决;如果认为不是bug,请选择设计如此;如果bug没有重现,请选择不能重现;如果确实bug但近期内无法解决,请选择延迟处理;如还有其他问题,请选择所对应的解决方案。填写备注信息,以说明bug处理情况。点击保存,完成bug修改流程。

4、  测试人员验证bug

测试人员登录系统后,发现指派给自己的bug,点击bug进入bug详细描述。

查看bug解决方案及bug状态,如果为已解决,则验证bug是否确定修改,如果修改完成,点击关闭,如果bug没有修改正确,点击激活重新打开bug。

如果bug状态为无法重现,则需要自己重现bug,如确实无法重现,关闭,如果可以重现,激活并与开发人员沟通或现场演示bug的重现。

如果为其他状态,请与开发人员协商解决。

时间: 2024-08-30 00:38:21

BUG处理流程说明的相关文章

Bug总结流程

这几天随着项目正式上线,bug的问题全面爆发,没有陈述好bug,程序人员和测试人员一直沟通交流,bug无法准确有效的修改关闭,这对上线系统是致命的. Bug总结思想 对线上漏测的问题进行收集 对每一个漏测的问题详细分析Bug机理以及漏测的原因 基于以上的原因思考如何进行改进,避免漏测问题发生 将改进方案实施 重复以上的步骤,通过正向循环推动测试团队的质量改进不断优化 Bug总结流程: 为了便于流程的运转和操作,在公司内部系统上建立了总结流程和表单: 举例说明: 某天,小王测试的erp项目在上线后

程序的bug排查流程总结

只要是人写的程序,不可能没有bug,那么解决bug,将伴随程序员的一生: ? 只会写代码,但不会排查bug的程序员,只能算是业余程序员 ? 能解决一般bug的,只能算是初级程序员 ? 代码写的质量较好,还能查找较难bug的,中级程序员 ? 代码写的质量好,注重性能,不但能排查疑难bug的,还能解决疑难bug的,高级程序员 ? 代码写的质量好,注重性能,稳定性,可靠性,架构设计合理,能解决绝大部分疑难问题,属于资深程序员 以上的话引自某个论坛网站,不一定说的绝对正确,但基本是有道理的. 面对出现的

软件测试面试必问--bug交互流程

目前市场主要用的bug管理工具:禅道.jira.QC.bugfree等,当然也有自己公司开发的. 不过不管哪一种工具,核心交互流程都是差不多的,只是字段的名称不一样而已,参考如下两张示意图: 这是前几天做的一个项目,由于项目组开发成员对交互不是太明白,所以花了点时间画的一个简单交互示意流程图: K12-禅道项目bug交互流程图 下图是bug核心交互流程图(无论目前市场用的哪一款交互工具,都可以说成如下的流程),面试的时候说哪一个都可以: 原文地址:https://blog.51cto.com/d

解决一bug的流程复盘

听同事说有一个功能不好使了,当时有事,过了一段时间来看看这个bug 解决问题时,看的是老的日志,根据老日志看来看去没有发现问题,觉得很困惑 然后手动执行了一下,发现问题没有重现.与另一个团队的同事沟通下,说是他们那边把代码回退了. 总结:解决问题时,要重现bug,并取最新的日志.从引发问题的最接近的原因开始一步步分析,一层层的排查故障

Bug跟踪的流程

本文以翼发云协同项目管理系统为例子来讲解Bug跟踪的流程,它以工作流为中心的集成式Bug跟踪软件,它广泛地应用于研发行业的产品缺陷管理 与跟踪.事务跟踪.问题跟踪.任务跟踪.查询跟踪.需求管理.变更跟踪.企业帮助台和客户服务台等诸多范畴. 该系统提供了一个可靠的中央数据库集中管理多渠道提交至系统的信息,然后由系统按事先定义的条件和流程, 自动分配任务给相关的负责人员.公司员工与部门.部门与 部门.公司与客户之间能在任何时间.任何地点通过简便易行的方式进行 协作和信息交流,并且使任何记录都有据可查

bug的处理流程

又属于一篇普及文,希望自己在被各种技术吸引的同时,能时常来整理和总结软件测试最基本的知识. 从刚工作时接触的第一个缺陷管理工具禅道,到redmine.JIRA.bugzilla ,再到现在的QC,当然还有其它种的开源的或商业的缺陷管理工具,它们的本质是一样的,就是来管理缺陷的生命周期. 其实,你理解任意的一款工具,其它的工具也一定能无师自通.这不谈某款工具,单把它本质的一些东西抽离出来与大家分享. Bug的属性 Bug重现环境 这个应该是我们重现bug的一个前提,如果没有这个前提,我们可能会无法

互联网公司的“敏捷开发”流程是怎么样的,每个职位的角色和分工是什么?

作者:暗灭 第一   为什么需要敏捷开发. 在几万年以前,软件项目的开发都是以年来计算的,这代表什么意思呢 ?需求设计了半年多,方案设计做了半年多,开发了三年多,测试了半年多,修改Bug用了半年多.总计花了很长很长的时间,然后上线后发现有很多需求已经不存在了,同时又出现了很多新的需求. 怎么办?继续改.这一改又是半年多的时间过去了.马丹用户的需求还再改,怎么办? 这是困扰软件开发项目的最大的问题,越大的项目,参与的人越多,风险越大.文档越规范,维护起来的难度就越高,导致项目中遇到的问题越来越多.

五大最受欢迎的BUG管理系统

Google在中国大陆遭遇变故做出临时性的退出大陆市场,也使非常多忠实的用户受到小小的挫折,以本公司为例.原本的BUG都是记录在google的 EXCEL在线文档中,由于常常性的打不开.測试和开发组在线上交流不了,都仅仅能通过其他的方式进行沟通和讨论,非常不便. 于是在測试部经理的要求下,寻 找出一些最受大家青睐的BUG管理系统.从中选择出最适合的来作为公司管理BUG的专用系统.经过认真的查找和比較,选出下面五大为比較受欢迎的BUG管理系统. 下面简介一下其功能优缺点和资源获取方式吧: 1. Q

BUG数量和项目成本

 在说BUG数量对项目成本的影响之前,首先说下软件测试流程,本人所在的公司使用的是maintis作为跟踪BUG的工具,使用其他的工具,对BUG测试流程没有影响 具体流程如下, 测试员执行测试用例 测试员如果发现BUG,在mantis上记录BUG信息,同时将信息转给项目经理 项目经理浏览BUG记录,把相应的BUG转给对应的开发人员 程序员按照maintis记录的内容,执行测试用例,确认是否有BUG 程序员修改BUG 程序员修改BUG结束后,更新mantis上的BUG状态 测试员验证已修复的BUG