精华内容
下载资源
问答
  • 2022-04-28 16:28:48

    什么是bug?

            软件缺陷:通常又被叫做Defect或者Bug。 产品需求文档中规定要做的事情,而软件没有实现。

            产品需求文档中规定不要做的事情,而软件确实现了。 产品需求文档中中没有提到过的事情,而软件确实现了。

            产品需求文档中没有提到但是必须要做的事情,软件确没有实现。

            软件很难理解,很难使用,速度超慢,测试人员站在最终用户的角度看到的问题是平常的但不是正确的。

    创建BUG需要填写以下关键信息:

            1.所属产品(必填)

            2.所属项目(必填)

            3.所属模块(必填)

            4.影响版本(必填)

            5.当前指派(必填)

            6.截止日期、BUG类型(必填)

            7.操作系统、浏览器

            8.BUG标题(必填)

            9.严重程度(必填)

            10.优先级(必填)

            11.BUG内容(必填)

            12.相关需求、相关任务、抄送人员、关键词、附件,未标红的选项可根据实际情况酌情填写。

    1.所属产品

            提出的BUG是属于哪个产品的。当有不止一个产品时,需填写,以方便研发确认是哪个产品的问题,也方便测试人员后期统计分析BUG,确认BUG是属于哪个产品的;

    2.所属项目

            提出的BUG是属于哪个项目的。当同一个产品不止一个项目时,需填写,以方便研发确认是哪个项目的问题,也方便测试人员后期统计分析BUG,确认BUG是属于哪个项目的;

    3.所属模块

            提出的BUG是属于哪个模块的。方便研发快速定位问题是哪个模块的,也方便测试人员后期统计分析BUG,确认BUG是哪个模块的,以定位哪些模块BUG率较高,后期加强测试;

    4.影响版本

            提出的BUG是属于哪个版本的。方便测试人员后期统计分析BUG以及确认BUG是在哪个版本解决的;

    5.截止日期

            期望问题能在什么时间内解决;

    6.当前指派

            提出的BUG指派给谁(一般指派给对应开发进行问题确认及解决,也可以指给研发经理或测试主管,经研发经理或测试主管确认后再进行问题指派);

    7.Bug的类型

            禅道中BUG类型包含以下几种:

            ·代码错误:由于研发人员代码编写不合理或错误导致的问题,属于代码错误;

            ·设计缺陷:由于产品人员或设计人员逻辑、功能、交互等方面设计的不合理导致的问题, 属于设计缺陷;

            ·配置相关:由于环境配置不正确导致的问题,属于配置相关的缺陷;

            ·安全相关:由于数据有效性检测不合理、重要数据在传输中没有加密、缺少身份认证机制 或认证不合理等安 全相关的问题,属于安全相关缺陷;

            ·性能问题:与程序性能相关的问题,例如:并发量、吞吐量、响应时间等不达标问题,属 于性能问题;

            ·界面优化:界面设计不合理、颜色不合适、显示位置不合适、文字说明或标题名称不合适 等界面显示问题, 属于界面优化问题;

            ·其他:不属于以上类型的问题,例如兼容性问题,选择此类型。

    8.BUG标题

            BUG的标题为必填项,最好以精确简练的语句描述出问题所在模块及问题内容,方便研发经理、测试主管、研发人员、测试人员快速了解问题的大概内容,后期进行问题分派、问题解决以及问题回归时,也可快速区分不同的BUG;

            Bug标题中需包含Bug的具体位置并以【】标注 举例:【模块-子模块-页面】XXXXXXXXXXXX

            Bug标题尽量简明

    •   做什么操作 + 出现什么结果,比如(点击提交按钮,出现卡顿现象)

    •   字数一般不超过20个字

            Bug标题中切勿出现错别字 错误示例: 奔溃(崩溃),电击(点击),登陆,(登录),重置(充值),现实(显示)

    9.BUG内容

            BUG内容一般必须包括:操作步骤、实际结果、期望结果。但也可根据实际情况,写出问题模块、测试数据、BUG重现的概率(一般为偶发或特殊次数之后才会出现的问题),或添加问题截图、需求附件等,可以更加直观的快速定位问题。

            1.操作步骤:

            要简明清晰分步骤描述如何复现Bug问题,步骤用序号编排。

            要按照自己的操作的实际步骤写清楚每一步是怎么操作的,最后操作到哪个页面或者点击哪个按键。

            如:

                    1.进入进货订单页面

                    2.点击取消订单按钮

            2.实际结果

                    按照测试步骤实际出现的错误结果

            3.预期结果

                    按照测试步骤应当得到的正确结果,按照产品需求的期望清晰准确的填写预期结果

            4.截图和附件

                    ---UI类型:Bug需要上传截图,并且增加相应的红框标识;

                    ---功能类型:问题必须上传视频文件,上传格式MP4为主;

                    ---崩溃类型:bug则需要上传视频和接口日志

            5.接口问题的bug

            需要填写

                    1.出错的接口地址

                    2.传入接口的参数

                    3.接口的返回数据

                    4.接口的请求方式

    10.优先级

            禅道中BUG优先级分为四级:1、2、3、4,分别对应:紧急、高、中、低

            1-非常紧急

                    影响测试,需立即修复;

            2-紧急

                    希望能尽快修复,除非常紧急之外的,优先处理;

            3-一般紧急

                    在版本发布之前修改完;

            4-

                    对产品的影响比较小,在时间不允许的情况下可以暂时不修改。

    11.严重程度

            禅道中BUG严重程度分为四级:1、2、3、4,分别对应:致命缺陷、严重缺陷、普通缺陷、轻微缺陷

            1-致命缺陷

            阻碍开发和测试工作,致命性的缺陷。例如:系统无法登录、经常闪退或主流程应用模块无法启动、异常退出、用户数据受到破坏、系统崩溃,阻断性问题,造成系统不稳定;

            2-严重缺陷

            系统的主要功能部分丧失、数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显的影响;

            3-普通缺陷

            系统的次要功能没有完全实现,但不影响用户的正常使用,或由于兼容性问题,导致界面布局变形、图片无法显示等致使某个小功能无法使用;

            4-轻微缺陷

            不影响功能的、有关易用性的、文字、操作可以提出一些建议的问题。

    12.相关需求

            若发现的BUG与需求相关,则可选择关联对应需求,方便研发人员了解问题的前因后果及具体需求内容,也方便测试人员后期查阅BUG/需求内容,回归测试时了解正确功能内容。

    13.相关任务

            若发现的BUG与任务相关,则可以选择关联任务,此任务一般为测试人员的任务,方便后期BUG统计、回归等。

    14.抄送给

            添加的bug可以抄送给研发经理和测试主管,让他们可以看到你提的bug对你提的bug进行关注和审核

    BUG处理流程

            一般BUG的生命周期为:创建(激活)–确认(已确认)–解决(已解决)–关闭(已关闭)

            1)测试人员在测试过程中,发现并创建BUG(创建完成后状态为:激活状态),记录产品 缺陷,分析并跟踪BUG直至问题解决;

            2)BUG创建后会指派给对应人员,若存在中间分析/分配BUG人员,则指派给该人员,分析/分配BUG的人员查看BUG并进行分析,确定为BUG则确认BUG(状态变为:已确认)并将问题指派给对应解决人员(一般为研发人员);

            3)研发人员及时分析处理问题,问题解决后修改BUG状态为:已解决,并填写解决方案、解决版本,然后指派给测试人员(一般为创建BUG的人员),若有特殊说明,则在备注中说明;

            4)测试人员对已解决状态的问题及时进行回归,若问题解决则关闭BUG,若问题未解决则激活。

    BUG解决方案

            禅道中BUG解决方案有:设计如此、重复BUG、外部原因、已解决、无法重现、延期处理、 不予解决。

            【设计如此】若BUG所述内容与产品或设计图是一致的,则研发人员在将BUG置为已解决 状态时,可选择:设计如此 解决方案,但建议在备注内进行说明;

            【重复BUG】若BUG为重复BUG,即已经存在与此相同的BUG,则研发人员在将BUG置为已 解决状态时,可选择:重复BUG 解决方案,并填写重复BUG的ID,若有特殊说明可在备 注内进行说明;

            【外部原因】若BUG的出现原因为外部原因(例如硬件、第三方软件等导致的问题),则 研发人员在将BUG置为已解决时,可选择:外部原因 解决方案并在备注内进行说明;

            【已解决】若BUG中描述的问题已解决,则研发人员在将BUG置为已解决状态时选择:已 解决 解决方案;

            【无法重现】若BUG为无法重现的BUG,则研发人员在将BUG置为已解决状态时,可选择: 无法重现 解决方案,并在备注内进行说明,建议研发人员遇到此类问题联系测试人员进 行复现;

            【延期处理】若研发人员考虑到时间等原因,觉得BUG需要延期进行处理,则在将BUG置 为已解决时,选择:延期处理 解决方案,并填写计划在哪个版本进行修复,在备注内进 行原因说明;

            【不予解决】若研发人员在分析问题后觉得不是问题或者无需修改,则选择:不予解决 解 决方案 并在备注内写明不予解决的原因。

    BUG回归

            【设计如此】针对解决方案为:设计如此 的BUG,测试人员在回归时进行验证,若无法接 受此方案,则激活BUG,若接受此解决方案,则关闭BUG(可以与产品\设计人员进行确认);

            【重复BUG】针对解决方案为:重复BUG 的BUG,测试人员在回归时进行验证,若为重复 BUG,则关闭BUG,若不为重复BUG则激活并在备注内填写说明;

            【外部原因】针对解决方案为:外部原因 的BUG,测试人员在回归时,查看研发人员给予 的备注,若可以接受则关闭BUG,不接受则记录,可在发版前开会进行讨论,并给予处理 方案;

            【已解决】针对解决方案为:已解决 的BUG,测试人员回归问题,若问题已解决则关闭 BUG,若未解决则激活BUG(注意查看备注);

            【无法重现】针对解决方案为:无法重现 的BUG,测试人员根据操作步骤进行重现BUG, 若无法重现则关闭,若可以重现则激活(可联系研发人员进行当面重现);

            【延期处理】针对解决方案为:延期处理 的BUG,查看备注内容,可以接受则关闭BUG(关 闭BUG则记录问题,也可不关闭待下个版本解决后再关闭),不接受则与产品人员确认是 否延期或发版前会议讨论处理方案;

            【不予解决】针对解决方案为:不予解决 的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的重现。

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

     

    展开全文
  • BUG处理流程

    千次阅读 2019-05-10 18:16:00
    4、 如果不是bug,退回给测试人员并描述退回原因,或为设计如此,或为外部原因,或者不能重现。 5、 开发人员修改完成的bug,由测试人员进行验证,确认修改正确,关闭bug。 6、 验证未通过的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经过测试人员验证,未修改正确,需要继续修改。

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

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

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

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

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

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

    项目线上Bug处理流程

    展开全文
  • 禅道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提出及处理流程规范

    版本说明
    版本 作者 时间 备注
    1.0 _冷冷 2019/9/27 首版本提交

    目录
    1 概述 1
    2 目的 1
    3 作用 1
    4 缩略词 1
    5 适用范围 1
    6 BUG的定义 2
    7 BUG书写规范 2
    7.1 BUG书写必填内容 2
    7.2 BUG书写注意事项 2
    7.3 BUG关键信息释义 2
    8 BUG处理流程 5
    8.1 BUG生命周期 5
    8.2 BUG解决方案 5
    8.3 BUG回归 6
    8.4 BUG处理流程图 7
    8.5 遗留BUG跟踪 7
    8.6 BUG分析 8

    1概述

    本文档规范bug的提出及管理流程,定义BUG的整个生命周期。帮助测试、研发等人员了解BUG的处理流程。提高测试人员工作效率以及产品缺陷修复效率,避免出现搁置和遗漏的缺陷,从而提高产品的质量,降低质量检查和缺陷修改成本。

    2目的

    清晰简单描述好问题,编写有效的BUG,可以帮助开发人员快速有效的进行问题定位,重现问题,从而快速有效的修改问题,提高测试效率。

    3作用

    可以提高开发人员修复BUG的效率;
    可以降低开发人员的二次BUG率;
    可以提高其他部分对测试部门的信用度;
    可以增加开发与测试的协作力,有效提高产品的质量 。

    4缩略词

    5适用范围

    研发、测试、产品人员。

    6BUG的定义

    BUG是一个英文单词,本意是指昆虫、小虫、损坏、犯贫、缺陷、窃听器等意思。现在一般是指在电脑系统或程序中,隐藏着的一些未被发现的缺陷或问题,简称程序漏洞。

    7BUG书写规范

    7.1 BUG书写必填内容

    创建BUG需要填写以下关键信息:所属产品(必填)、所属项目(必填)、所属模块(必填)、影响版本(必填)、当前指派(必填)、截止日期、BUG类型(必填)、操作系统、浏览器、BUG标题(必填)、严重程度(必填)、优先级(必填)、BUG内容(必填)、相关需求、相关任务、抄送人员、关键词、附件,未标红的选项可根据实际情况酌情填写。

    7.2 BUG书写注意事项

    书写BUG时尽量遵循以下规则:
    1)BUG必须标注:严重等级、优先级别并准确表述出问题内容及所在模块等,方便研发等人员快速定位问题并有序解决问题;
    2)BUG标题:要以一个准确简练的句子描述某个模块存在的问题,或者某个操作导致了什么问题;
    3)BUG内容:针对不同的原因导致的问题要包含对应的原因,例如手机的品牌、操作系统或者是浏览器名称、版本等;
    4)BUG内容:常规BUG内容中要包含:操作步骤、实际结果、预期结果,语言要清晰准确;
    5)BUG内容:若为特殊数据造成的问题,需提供具体测试数据;
    6)兼容性问题需在两个以上环境中确认BUG再进行提交;
    7)非必现BUG需进行10次以上测试,标注问题出现概率;
    8)BUG的所有描述中,不要带有个人情绪或诽谤性词汇,要用专业名词、准确、客观的描述问题、实际结果及期望结果。

    7.3 BUG关键信息释义

    【所属产品】
    提出的BUG是属于哪个产品的。当有不止一个产品时,需填写,以方便研发确认是哪个产品的问题,也方便测试人员后期统计分析BUG,确认BUG是属于哪个产品的;

    【所属项目】
    提出的BUG是属于哪个项目的。当同一个产品不止一个项目时,需填写,以方便研发确认是哪个项目的问题,也方便测试人员后期统计分析BUG,确认BUG是属于哪个项目的;

    【所属模块】
    提出的BUG是属于哪个模块的。方便研发快速定位问题是哪个模块的,也方便测试人员后期统计分析BUG,确认BUG是哪个模块的,以定位哪些模块BUG率较高,后期加强测试;

    【影响版本】
    提出的BUG是属于哪个版本的。方便测试人员后期统计分析BUG以及确认BUG是在哪个版本解决的;

    【当前指派】
    提出的BUG指派给谁(一般指派给对应开发进行问题确认及解决,也可以指给研发经理或测试经理,经研发经理或测试经理确认后再进行问题指派);

    【截止日期】
    期望问题能在什么时间内解决;

    【BUG标题】
    BUG的标题为必填项,最好以精确简练的语句描述出问题所在模块及问题内容(也可包含版本信息),方便研发经理、测试经理、研发人员、测试人员快速了解问题的大概内容,后期进行问题分派、问题解决以及问题回归时,也可快速区分不同的BUG;

    【BUG类型】
    禅道中BUG类型包含以下几种

    代码错误:由于研发人员代码编写不合理或错误导致的问题,属于代码错误;

    低级缺陷:轻微级别的小缺陷;

    设计缺陷:由于产品人员或设计人员逻辑、功能、交互等方面设计的不合理导致的问题, 属于设计缺陷;

    配置相关:由于环境配置不正确导致的问题,属于配置相关的缺陷;

    安全相关:由于数据有效性检测不合理、重要数据在传输中没有加密、缺少身份认证机制 或认证不合理等安 全相关的问题,属于安全相关缺陷;

    性能问题:与程序性能相关的问题,例如:并发量、吞吐量、响应时间等不达标问题,属 于性能问题;
    界面优化:界面设计不合理、颜色不合适、显示位置不合适、文字说明或标题名称不合适 等界面显示问题, 属于界面优化问题;

    其他:不属于以上类型的问题,例如兼容性问题,选择此类型。

    【严重程度】
    禅道中BUG严重程度分为四级:1、2、3、4,分别对应:致命缺陷、严重缺陷、普通缺陷、轻微缺陷

    1类-致命缺陷Blocker:
    阻碍开发和测试工作,致命性的缺陷。例如:系统无法登录、经常闪退或主流程应用模块无法启动、异常退出、用户数据受到破坏、系统崩溃,阻断性问题,造成系统不稳定;

    2类-严重缺陷Critical 、Major:
    系统的主要功能部分丧失、数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显的影响;

    3类-普通缺陷Normal 、Minor:
    系统的次要功能没有完全实现,但不影响用户的正常使用,或由于兼容性问题,导致界面布局变形、图片无法显示等致使某个小功能无法使用;

    4类-轻微缺陷trivial:
    不影响功能的、有关易用性的、文字、操作可以提出一些建议的问题。

    【优先级】
    禅道中BUG优先级分为四级:1、2、3、4,分别对应:紧急、高、中、低

    1-非常紧急:
    影响测试,需立即修复;

    2-紧急:
    希望能尽快修复,除非常紧急之外的,优先处理;

    3-一般紧急:
    在版本发布之前修改完;

    4-低:
    对产品的影响比较小,在时间不允许的情况下可以暂时不修改。

    【BUG内容】
    BUG内容一般必须包括:操作步骤、实际结果、期望结果。但也可根据实际情况,写出问题模块、测试数据、BUG重现的概率(一般为偶发或特殊次数之后才会出现的问题),或添加问题截图、需求附件等,可以更加直观的快速定位问题。

    【相关需求】
    若发现的BUG与需求相关,则可选择关联对应需求,方便研发人员了解问题的前因后果及具体需求内容,也方便测试人员后期查阅BUG/需求内容,回归测试时了解正确功能内容。

    【相关任务】
    若发现的BUG与任务相关,则可以选择关联任务,此任务一般为测试人员的任务,方便后期BUG统计、回归等。

    8BUG处理流程

    8.1 BUG生命周期

    一般BUG的生命周期为:创建(激活)–确认(已确认)–解决(已解决)–关闭(已关闭)。
    目前测试按以下流程执行缺陷跟踪流程,主要工具为禅道。
    1)测试人员在测试过程中,发现并创建BUG(创建完成后状态为:激活状态),记录产品 缺陷,分析并跟踪BUG直至问题解决;
    2)BUG创建后会指派给对应人员,若存在中间分析/分配BUG人员,则指派给该人员,分析/分配BUG的人员查看BUG并进行分析,确定为BUG则确认BUG(状态变为:已确认)并将问题指派给对应解决人员(一般为研发人员);
    3)研发人员及时分析处理问题,问题解决后修改BUG状态为:已解决,并填写解决方案、解决版本,然后指派给测试人员(一般为创建BUG的人员),若有特殊说明,则在备注中说明;
    4)测试人员对已解决状态的问题及时进行回归,若问题解决则关闭BUG,若问题未解决则激活。

    8.2 BUG解决方案

    禅道中BUG解决方案有:设计如此、重复BUG、外部原因、已解决、无法重现、延期处理、 不予解决。
    【设计如此】若BUG所述内容与产品或设计图是一致的,则研发人员在将BUG置为已解决 状态时,可选择:设计如此 解决方案,但建议在备注内进行说明;
    【重复BUG】若BUG为重复BUG,即已经存在与此相同的BUG,则研发人员在将BUG置为已 解决状态时,可选择:重复BUG 解决方案,并填写重复BUG的ID,若有特殊说明可在备 注内进行说明;
    【外部原因】若BUG的出现原因为外部原因(例如硬件、第三方软件等导致的问题),则 研发人员在将BUG置为已解决时,可选择:外部原因 解决方案并在备注内进行说明;
    【已解决】若BUG中描述的问题已解决,则研发人员在将BUG置为已解决状态时选择:已 解决 解决方案;
    【无法重现】若BUG为无法重现的BUG,则研发人员在将BUG置为已解决状态时,可选择: 无法重现 解决方案,并在备注内进行说明,建议研发人员遇到此类问题联系测试人员进 行复现;
    【延期处理】若研发人员考虑到时间等原因,觉得BUG需要延期进行处理,则在将BUG置 为已解决时,选择:延期处理 解决方案,并填写计划在哪个版本进行修复,在备注内进 行原因说明;
    【不予解决】若研发人员在分析问题后觉得不是问题或者无需修改,则选择:不予解决 解 决方案 并在备注内写明不予解决的原因。

    8.3 BUG回归

    【设计如此】针对解决方案为:设计如此 的BUG,测试人员在回归时进行验证,若无法接 受此方案,则激活BUG,若接受此解决方案,则关闭BUG(可以与产品\设计人员进行确认);
    【重复BUG】针对解决方案为:重复BUG 的BUG,测试人员在回归时进行验证,若为重复 BUG,则关闭BUG,若不为重复BUG则激活并在备注内填写说明;
    【外部原因】针对解决方案为:外部原因 的BUG,测试人员在回归时,查看研发人员给予 的备注,若可以接受则关闭BUG,不接受则记录,可在发版前开会进行讨论,并给予处理 方案;
    【已解决】针对解决方案为:已解决 的BUG,测试人员回归问题,若问题已解决则关闭 BUG,若未解决则激活BUG(注意查看备注);
    【无法重现】针对解决方案为:无法重现 的BUG,测试人员根据操作步骤进行重现BUG, 若无法重现则关闭,若可以重现则激活(可联系研发人员进行当面重现);
    【延期处理】针对解决方案为:延期处理 的BUG,查看备注内容,可以接受则关闭BUG(关 闭BUG则记录问题,也可不关闭待下个版本解决后再关闭),不接受则与产品人员确认是 否延期或发版前会议讨论处理方案;
    【不予解决】针对解决方案为:不予解决 的BUG,查看备注内容,可以接受则关闭BUG, 不接受则与产品人员确认是否需要解决或发版前会议讨论处理方案。

    8.4 BUG处理流程图

    BUG处理流程

    8.5 遗留BUG跟踪

    【发版前遗留BUG】由于时间问题或其他原因,发版后可能会存在一些遗留BUG未解决,需要将这些BUG进行记录、分析,方便后期迭代进行问题修复;
    【发版后遗留BUG】产品发布后的 bug 来源有:客户、开发、测试人员,该类 bug 在发现后需要提交给项目组,纳入bug管理,该类 bug的发现阶段标识为已发布,便于分析原因及下期优化。

    8.6 BUG分析

    项目结束后,需要对BUG进行分析整理,可以统计BUG的类型、严重程度、所属模块等信息。然后进行分析,得出BUG的出现频率、出现模块、出现类型等,以采取相应措施避免该类 bug再次出现,提高产品质量。测试人员每个项目测试结束以后,将 bug 分析结果写在《测试报告》中。

    展开全文
  • “缺陷管理工具”禅道—升华Bug处理流程与相关属性 作为一个软件测试工程师,对缺陷管理工具(缺陷:Bug)的认识和准确操作是有所必要的,缺陷管理工具现在行业中有很多:禅道、QC、Clear Quest、TestLink、Bugfree...
  • 遇到软件测试bug怎么处理

    千次阅读 2020-09-01 13:41:22
    通俗来说,就是bug管理
  • 敏捷开发bug管理流程

    2020-11-24 17:44:04
    对由本组负责处理的BUG进行管理,通过对BUG的提交、跟踪解释、验证流程进行规范,提高BUG处理效率。 适用范围 测试团队以及其他团队进行的BUG提交、跟进与解释、验证工作。 BUG管理流程 BUG提交...
  • 一、前言提交bug是个既愉快又痛苦的过程。成功的发现一个有效bug是很有成就感的,但是如果bug提交的不规范不清楚,导致开发反复找你确认或者一段时间后自己都忘了是个什么bug那就很痛苦了。特别是有时候bug会很多...
  • BUG优先级的标准

    2021-11-19 16:52:02
    业务Bug优先级说明 一:Bug优先级参考维度 1:业务的重要程度 2:问题严重程度 3:发生的概率 二:如何评估业务重要程度 1:新需求:评估功能重要结合“需求功能”+“业务功能” 2:非新需求:评估功能重要...
  • 测试提bug相关注意事项
  • 笔者总结了工作中遇到bug处理流程,如下:   一、bug确认 分配到一个bug后,要根据bug单号到bug管理系统查看该bug的详细信息。 1. 查看问题现象,了解问题 2. 查看软件版本和操作流程,检查当前版本和操作...
  • Bug编写规范及要求

    2021-12-08 17:40:20
    Bug编写规范及要求 标题规范: 出现bug的模块或页面,可用一句话完整描述问题现象 一个合规的bug: 按照复现步骤可复现bug; 涉及造数据的部分须在复现步骤中写明; 及时跟踪bug状态,密集测试期间应以天为单位,...
  • 如果公司bug管理混乱,bug未划分优先级,将会导致许多优先级高的bug未能及时解决,同时研发部门会花费大量的时间处理非紧急bug,将会严重影响研发中心、产品中心、运营中心、商务中心的工作效率。 2. 影响范围 研发...
  • 在经历过的创业公司中,我经常看到下面这些情况: 兢兢业业,认真负责的...什么样的bug是没必要提的bug,这里面恐怕颇多争议,我们来举几个例子: bug1:如果老师没有使用授课系统上课,但是布置了作业,进入到查...
  • 三种bug定位方法

    2020-12-29 03:36:54
    1、定位bug产生的过程测试用例的执行,基本上是程序运行过程bug产生的开始,若测试结果与期望结果有出入,即出现了错误征兆,定位bug过程首先要找出bug产生的原因,然后对bug进行修正。因此定位bug过程有两种可能:...
  • 深入理解bug的相关概念

    千次阅读 2018-11-08 20:51:18
    功能不符合需求, 不正确或缺失的异常处理,不符合用户使用习惯的(要根据实际情况来), 超出用户期望的需求(画蛇添足,也不一定)   一个bug单包含哪些要素 1、所属的系统(产品) 2、发现的版本(轮次) 3、发现...
  • 经历过几家创业公司,发现大部分测试和开发人员,包括项目经理,对于bug状态与解决方案竟然傻傻分不清楚,导致bug管理与统计上的混乱,在费尽了我的三寸不烂之舌团队成员解释之后,索性将这个问题做个整理写下来,...
  • 1、Bug操作流程 2、Bug的几种解决方案 已解决 延期处理 不予处理 外部原因: 第三方问题 设计如此: 无效Bug 无法重现: 无效Bug 重复Bug : 无效Bug 3、Bug等级简介 Priority: bug的重要性及其解决顺序。 Notes: ...
  • BUG漏测的原因总结,以及如何处理

    千次阅读 2018-04-24 22:50:14
    对于外部反馈的缺陷,是因为场景设计不全引起的,我们先分析出现问题的场景是客户必须的场景还是偶然的场景,如果该场景是客户操作习惯,我们可以通过和技术接口人沟通,确认该场景的一些具体细节,在完善测试用例的...
  • Bug 跟踪流程 我们先来定义一下什么是 bug 跟踪(或者 bug 跟踪流程)。Bug 跟踪是报告、安排优先级以及处理 bugs 和问题的过程。它听起来不怎么有趣,但是如果想要提供良好的服务,除了建立一个 bug 跟踪和修复...
  • 所以程序员如何减少开发中的 Bug,既反映了代码质量,也反映了个人综合能力。 那么我们该如何有效的减少开发中的 Bug 呢? 我觉得应该从两方面说起:业务层和代码层。 二、业务层 软件开发过程我们就不细说了,...
  • 软件测试——bug相关知识

    千次阅读 2020-04-27 15:32:05
    软件测试需求来自需求规格说明书中的原始需求,应覆盖已定义的业务流程以及功能和非功能方面的需求。所谓的测试需求就是在项目中要测试什么。 为什么需要软件测试需求? 1)软件测试需求是设计测试用例的依据。 2)...
  • 12 个顶级 Bug 跟踪工具(建议收藏)

    千次阅读 2021-03-10 00:17:38
    屏幕截图、屏幕记录或工作流程都会非常有用 问题的时间和日期 严重程度 复现细节 bug 状态 bug 负责人 那么,什么是一个 bug 跟踪工具呢?简而言之:bug 跟踪系统有一套能够帮助有效解决和管理问题的功能。此外,bug...
  • 禅道项目管理——bug管理工具

    千次阅读 2021-12-20 18:10:55
    禅道项目管理——bug管理工具 禅道地址:https://www.zentao.net/ 【重要】:需先开通禅道账号;向项目管理负责人 xxx 申请(申请方式: 飞书、企业微信、邮箱xxx@xxx.com均可) BUG的一生 1、基本信息 所属产品、...
  • Bug软件缺陷管理制度

    千次阅读 2022-03-25 10:38:36
    软件缺陷又被叫做Bug。所谓软件缺陷,即为软件中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义:从...
  • 软件测试整理三:测试方法、bug

    千次阅读 2021-08-28 22:00:25
    在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 45,105
精华内容 18,042
关键字:

外部bug处理流程