精华内容
下载资源
问答
  • BUG处理流程

    2015-07-03 16:43:59
    BUG处理流程,BUG状态流转,BUG书写标准
  • bug处理流程

    2019-10-31 22:27:00
    bug处理流程 (1)新建bug单 写上bug的标题, 复现这个bug的具体步骤, 一些前置条件和截图, 把bug单指定给相关的开发人员 (2)待修改 等开发人员修改完毕 把bug单置成待验证状态 返回给测试 (3)...

    bug处理流程

    (1)新建bug单

     写上bug的标题,

     复现这个bug的具体步骤,

     一些前置条件和截图,

     把bug单指定给相关的开发人员

     

    (2)待修改

     等开发人员修改完毕

     把bug单置成待验证状态

     返回给测试

     

    (3)待验证

     测试人员获取最新的产品,如果发现bug已经修复则置成已验证,

     如果发现bug还存在,则置成待验证,如果开发人员发现这个bug

     是无法处理的,把这个问题指定给产品人员,由产品人员确定是否遗留

     有些bug是由于测试环境问题或其他一些因素造成的,或许并不是一个问题,

     测试人员可能会出现误判,此时开发人员会把这个问题置成不是问题,返回给

     测试人员,确认后直接关闭

     

    (4)已验证

    (5)关闭

    展开全文
  • Bug 处理流程

    2015-06-25 22:22:34
    处理流程图,更深刻的理解 bug 的状态以一个 bug 的生命周期。 提交(打开)缺陷  在提交一个缺陷的缺陷,首先尽量描述这个缺陷的属性。 Bug 重现环境, bug 类型, bug 等级, bug 的...

    又属于一篇普及文,希望自己在被各种技术吸引的同时,能时常来整理和总结软件测试最基本的知识。

      从刚工作时接触的第一个缺陷管理工具禅道,到redmineJIRAbugzilla ,再到现在的QC,当然还有其它种的开源的或商业的缺陷管理工具,它们的本质是一样的,就是来管理缺陷的生命周期。

      其实,你理解任意的一款工具,其它的工具也一定能无师自通。这不谈某款工具,单把它本质的一些东西抽离出来与大家分享。

    Bug的属性

    Bug重现环境

    这个应该是我们重现bug的一个前提,如果没有这个前提,我们可能会无法重现问题,或者跟本就无从下手。

    操作系统

      这个是一般软件运行的一大前提,基本上所有的软件都依赖于操作系统之上的,对于一个软件来说,要想在某个操作系统上运行,必须要对这个操作系统支持,这就需要有真对性的设计与开发。对于不同的操作系统,其可能存在差异(如:win xp win 7)或本质的区别(如 win 7 CentOS linux ),所以,操作系统环境是重现问题的一个重要前提。

    浏览器

      对于B/S系统,或面向大众的互联网产品(网站,邮箱等),浏览器的兼容性也是必须测试的一个重点,对于现在的浏览器市场,各式的浏览器都有其用户群,要想使产品大众化,必须考虑这些产品的兼容性问题。

      不同的浏览器之间(IEfirefoxchromeopera 等),甚至同一系列不同版本(ie6/ie7/ie8/ie9等)都可能存在兼容性问题,所以,对于这类应用,浏览器环境重现bug前提条件之一。

    其它(这个“其它”非常重要)

      对于不同的系统发现重现问题,都会有其特定的前提,拿我测试的邮箱来说,必须要描述其是在测试线还是现网环境,而且还要附带一重现问题的帐号等。

    对于c/s软件,可能还要考虑与其它常用软的兼容等,例如,是在安装的某款软件后,对本软件的安装和使用造成影响。这些都是重现问题的必须描述的环境。

    问题类型

      根据JIRA的管理系统的划分,bug 只是问题的一种,它可以用于跟踪多种不同类型的问题(其实,他只是将bug做为一子类而已)。

      JIRA系统缺省提供的问题类型(大部分的系统都可以自定义类型的,这样就增加了灵活性。)

    • Bug : 测试过程、维护过程发现影响系统运行的缺陷。(这就是一般测试人员所提交的bug

    • New Feature : 对系统提出的新功能。(单个的小需求可以,如果大的话,就相当于一个需求,放到这里是不合理的。)

    • Task : 需要完成的一任务。(开发或测试任务指派。)

    • Improvement : 对现有系统功能的改进。(一般产品经理或产品体验师做的事)

      当然,不同的公司,他们的人员定位与职责是不太相同的,按照上面的分类,JIRA就不是简单的缺陷管理系统了,它涵盖一项目(或产品)所需要处理的任务、需求与缺陷。

    Bug 类型

      这里缩小范围,单指我们测试人员在测试过程中发现的缺陷,发现产品缺陷其实就是测试人员工作的主要目的。当然,你要确定一个问题的类型,也需要对项目(或产品)有比较深的理解。是代码缺陷还是设计缺陷有时候就不太容易区分,当然,这个划分,对于开发定位问题影响很小,但对于问题类型的统计就比较重要了。

    下面看一些常见的分类:

    划分方式一:

      代码错误

      设计缺陷

      界面优化

      配置相关

      安装部署

      性能问题

      标准规范

      测试代码

      其它

    划分方式二:

      功能类(function

      性能类(performance

      界面类(UI

      易用性类(usability

      兼容性类(compatibility

      其它(else

      这个分类当然是可以自定义的,具我接触的缺陷管理都是可以自定义的,既然是对问题的管理,那么你当然可以拿来做特定环境下的系统来使用,或我就想用这个系统来指派任务,那么我的自定义类型为前端任务、后端任务、测试任务、配置部署...

    缺陷等级

      缺陷等级,这个划分也比较灵活,有分三级或四级,也有分五级的。

    致命

      一招毙命的缺陷,使你的系统无法运行,有造成数据泄漏的安全性问题。

    严重

      可以引起易于纠正的异常情况、可能引起易于修复的故障或对产品外观难以接受的缺陷。

    一般

      指不影响产品的运转和运行、不会成为故障起因,但对产品外观和下道工序影响较大的缺陷

    轻微

      轻微缺陷是指对产品外观和下道工序可能会有轻微影响的缺陷

    建议

      增加用户使用体验的建议性问题。(一般情况下,建议也为做为缺陷的一种。这个跟系统的类型与需求有关)

    缺陷优先级(priority)

      当问题处理人员在面对许多问题需要处理进,就需要问题进行优先级排序。我们做事情的安排,操作系统有处理进程等都在使用着优先级。

    优先级的划分:

    低——>中——>高——>紧急

    延迟处理——>正常排队——>优先处理——>紧急处理

      Bug 的严重程度和优先级是含义不同但相互联系密切的两个概念,它们从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程序和处理方式。

      一般地,严重程序高的软件缺陷具有较高的优先级。严重程度高说明缺陷对软件造成的危害性大,需要优先处理,而来严重程序低的缺陷可能只是软件不太尽善尽美,可以稍后处理。

    严重程度高优先级不一定高:

      如果某个严重的软件缺陷只在非常极端的条件下产生,则没有必要马上处理。

      如果某一个软件缺陷,需要重新修改软件的整体架构,可能会产生更多的潜在缺陷,而且软件由于市场的压力必须尽快发布,此时即使缺陷的严重性很高,是否需要修正,需要全盘考虑。

    严重程度优先级不一定低

      如果是软件名称或公司名称的拼写错误,虽然说其属于界面错误,严重程度不高,但其关系到软件和公司的市场开解,必须尽快修正。

    缺陷状态

      对于一个问题,其处理过程是一个周期,周期的不同阶段,其所处的状态也是不一样的。不同状态所对应的处理人也是不一样的。

    打开 : 表示问题被提交等待有人处理。

    重新指派 : 问题被重新指派给某人处理。

    处理 : 问题在处理中,尚未完成。

    固定 : 确认此问题存在,但暂时不进行处理。

    回归 : 对已经修复的问题进行回归确认。Reopened :

    关闭 : 问题的最后一个状态。

    Bug处理流程

    下面通过一个比较完整的bug的处理流程图,更深刻的理解bug的状态以一个bug的生命周期。

    提交(打开)缺陷

      在提交一个缺陷的缺陷,首先尽量描述这个缺陷的属性。Bug重现环境,bug类型,bug等级,bug的优先级以及详细的重现步骤,结果与期望等。

      当然,我们在提交一个问题之前首先应该保证,这个缺陷是没有被提过的,以免造成重复缺陷单。

      如果是回归不通过的缺陷,其状态又会变为打开状态。


    分配(转交)缺陷

      这一步不是必须的,跟项目模式有关,有些公司测试部门与开发部门独立,那么测试人员就不确定自己测试的模块是由哪位开发人员负责的,在这种情况下,测试人员统一把问题指派给项目组长或经理,由项目组长(或经理)对问题进行确认后再次分配给相应的开发人员。

      有些测试人员是穿插到不同研发团队中的,所以对不同的开人发员负责的开发模块非常清楚,这个时候就可以将问题直接指派给相应的开发人员。

      也有一种情况,本来此问题应该由A开发人员负责,但由于A开发人员的调离或辞职,些问题为转交给其它人员处理。“分配”强调是上级对下级;“转交”强调的是平级之间。


    确认缺陷

      当开发人员接到一个缺陷时,首先是对其进行分析与重现,如果对其进行分析发现不是缺陷(可能由于测试人员不了解需求)或无法对此问题进行重现,那么就需要将此问题反回给测试人员,并注明原因。如果确认为缺陷则需要对其进行处理。

    推迟处理

      在处理问题之后,还需要进行一次判断,是否需要推迟处理,有些需求已经确认了是问题,由于其可能在极端情况下才会出现,或需要对系统架构进行改动,或其优先级非常低,所以暂时不需要对此问题进行处理(或到下个版本进再进行修复)。


    固定

      对于推迟处理的问题可以暂时进行固定(“固定”为QC中的叫法。)一般固定的问题需要经过项目经理与测试经理协商后才能固定。


    处理缺陷

      开发人员在确认完一个问题需要处理时,那么就对其进行处理工作。(例如,redmine 是支持处理人时时更新问题处理进度的,如 已处理30% ,已处理80% 等,当然,对于短时间内可以修复的问题就没必要时时的去更新处理进度。)

    回归缺陷

      回归缺陷对于测试人员来说是非常重要的工作,其有三个入口两个出口。

      确认非缺陷问题:对于提交的一个缺陷,开人员处理为非问题或无法重现,然后直接转交给测试人员回归。测试人员再次确认,如果真如开发人员所说,则将问题关闭。如果非开发人员所说,是由于问题描述模糊或其它原因喂重现问题,则再次注明原因转给开发人员。

      确认修复问题:对开发人员修复的问题再次进行确认,确认能过,则关闭问题。确认不通过,将问题再次打开并转给开发人员。

      确认固定问题:有计划的对固定问题进行确认,有些固定问题随着时间的推移,版本的更新或已经不存在了,对这类问题应该及时关闭。有些固定问题依然存在且变得紧急,对于这类问题应该及时打开交给开发人员处理。

    关闭缺陷

      对于已经修复的缺陷进行关闭,这也是一个缺陷的最后一个状态。





    1: 文中提到了产品与项目,好多人分不清项目与产品,各自有各自的理解。我个人从用户群上来划分。如果面向的是特定客户的需求,那么称其为项目,如某医院的医疗系统,某公司的管理系统。面向大众用户且长期运营的需求,称为产品,如,某网站,某网络游戏。

      如果小A让我给他做一个网站呢?对于我来说,小A是我的客户,这个网站对我来说就是一个项目,对于小A来说,他的网站是面向大众用户的,那么对于小A来说,网站就是自己的产品。

      富士康带工苹果手机是一样的道理,富士康接到苹果的订单,那么对富士康来说是个项目,完成项目,拿到钱就算项目结束。苹果手机对苹果公司来说是一个产品,它长期持有这个产品的所有权,并且不段的更新自己的产品。


    2: 本文中用到了 bug、缺陷、问题等三个词语,用词比较模糊,本文中表示为一个事物。


    展开全文
  • Bug处理流程规范

    2014-09-01 22:15:13
    基于禅道的BUG处理流程。自己整理的资料,希望能有一些帮助!
  • bug处理流程总结

    2020-07-06 14:19:28
    bug处理流程bug的状态不同状态bug对应的场景bug被关闭的情况工作中bug处理问题 bug的状态 1、新建 2、打开 3、已修复 4、已关闭 5、拒绝 6、延迟 7、激活 不同状态bug对应的场景 1、新建 —测试人员新建,标出bug...

    bug的状态

    1、新建
    2、打开
    3、已修复
    4、已关闭
    5、拒绝
    6、延迟
    7、激活

    不同状态bug对应的场景

    1、新建 —测试人员新建,标出bug发现的版本(指派给研发)
    2、打开 —开发人员确认bug后,将bug改为打开状态
    3、已修复 —开发人员修复后,改为此状态。
    (并标出修复版本和bug产生原因)
    4、已关闭 —测试人员验证通过后,关闭bug,并标出验证版本
    5、拒绝 —该bug逻辑错误或和需求不符,更改状态时,标注原因
    6、延迟 —因优先级原因,并经项目经理同意后,推迟到下个版本 解决,更改状态时,标注原因
    7、激活 —bug验证不通过,更改状态时,标注原因

    注:
    1、bug各阶段要有版本号做标记跟踪
    2、暂不修改的问题,是出于delay状态,不能改成拒绝(码云目前没有delay状态,可以不改状态,在下面做上文字标记)
    3、bug闭环,任何类型的bug,最终都由测试人员关闭

    bug被关闭的情况

    bug任何种类的bug最终都将由测试人员关闭
    1、回归通过的bug----直接关闭
    2、研发拒绝的(要与测试人员沟通)
    测试人员认可----直接关闭
    测试人员不认可----找项目经理协商,若问题不紧急可暂不处理
    3、重复问题----测试人员确认后关闭
    4、遗留问题
    1、需研发、测试、产品、项目经理开会讨论如何处理
    注:偶发性bug,验证通过不关闭,可先降低优先级,三个以上正式版本都未复现可暂时关闭,后面发现再提,若是现场反馈问题,优先级最高,建议持续观察,直到版本交付

    工作中bug处理问题

    测试:
    bug等级设定不严谨
    截图、日志上传不全
    研发:
    暂不解决的问题直接拒绝
    解决问题后,bug产生原因的描述很少
    里程碑:
    新增bug都绑定最近的里程碑,但事实上不会将所有问题解决掉,建议根据版本发布时间,bug优先级,由项目负责人进行绑定

    展开全文
  • bug状态流程图+bug处理流程+角色..pdf
  • bug状态流程图+bug处理流程+角色
  • BUG处理流程说明

    千次阅读 2018-08-05 16:30:00
    一、 BUG处理流程图: 流程描述: 1、 测试人员发现bug提交给开发。 2、 开发人员判断是否是bug。 3、 如果是bug,进行修改,修改完成后更改bug状态为已解决。 4、 如果不是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的重现。

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

     

    展开全文
  • Mantis Bug处理流程

    2010-02-08 16:11:19
    清晰,准确。规范的描述了。Mantis Bug处理流程
  • 操作手册与BUG处理流程操作手册用户操作手册是什么?编写用户操作手册的意义?如何编写一份好的操作手册?BUG处理流程线上BUG与线下BUG的区别什么是BUG?什么是线下BUG?什么是线上BUG?区别BUG生命周期确认问题记录...
  • bug处理流程规范

    2021-04-15 16:27:10
    本文档定义bug的整个生命周期,规范bug的解决方案及管理流程Bug在流转的过程中有章可循。规范bug严重等级与bug解决优先级,使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决; 2关键角色及职责...
  • Bug处理流程经验

    2019-12-27 23:28:52
    接到一个Bug之后 首先要确认是否是自己的问题,不是自己则要及时转给相应的人处理; 目的:这样做不是逃避责任而是让合适的人处理合适的问题,可以提高团队处理问题的效率; 技巧:I.bug越早转出越好,这样留给...
  • BUG处理流程

    2019-05-10 18:16:00
    流程描述: 1、 测试人员发现bug提交给开发。 2、 开发人员判断是否是bug。 3、 如果是bug,进行修改,修改完成后更改bug状态为已解决。 4、 如果不是bug,退回给测试人员并描述退回原因,或为设计如此,或为外部...
  • “缺陷管理工具”禅道—升华Bug处理流程与相关属性 作为一个软件测试工程师,对缺陷管理工具(缺陷:Bug)的认识和准确操作是有所必要的,缺陷管理工具现在行业中有很多:禅道、QC、Clear Quest、TestLink、Bugfree...
  • bug处理流程》.pdf

    2020-08-30 18:22:27
    bug管理工具使用基本知识,查看 bug 解决方案及 bug 状态,如果为已解决,则验证 bug 是否确定修改,如果 修改完成,点击关闭,如果 bug 没有修改正确,点击激活重新打开 bug。 如果 bug 状态为无法重现,则需要自己...
  • 项目线上Bug处理流程

    千次阅读 2017-09-24 15:41:51
    前言针对线上Release版本出现的Bug问题,我们需要有一套稍微严谨的处理流程,否则很容易忙乱掉。 下面是处理流程初稿。流程处理思维图
  • 紧急bug处理流程

    2015-01-15 18:09:04
    1. 确认问题 2. 严重程度,影响到的相关功能 3. 是否需要回滚代码 4. 判断修复时间 5. 所需人员,资源, 是否需要外援 6. 开始修改 7. 遇到难点,及时反馈 ...8. 改好以后,并测试成功,及时上线 ......
  • 标准的jira最新版本里面的Issue处理流程图,可以作为正规开发流程的参考
  • bug处理流程

    2008-10-30 09:58:00
  • 禅道BUG提出及处理流程规范

    万次阅读 多人点赞 2019-09-27 11:41:31
    禅道BUG提出及处理流程规范 版本说明 版本 作者 时间 备注 1.0 _冷冷 2019/9/27 首版本提交 目录 1 概述 1 2 目的 1 3 作用 1 4 缩略词 1 ...8 BUG处理流程 5 8.1 BUG生命周期 5 8.2 BU...
  • bug处理流程:参与人员,bug状态,bug的处理状态,过程图。
  • bug处理流程

    2021-03-04 04:39:18
    这个应该是我们重现bug的一个前提,如果没有这个前提,我们可能会无法重现问题,或者跟本就无从下手。这个是一般软件运行的一大前提,基本上所有的软件都依赖于操作系统之上的,对于一个软件来说,要想在某个操作...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,058
精华内容 423
关键字:

bug处理流程