禅道BUG编写及处理流程规范

什么是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, 不接受则与产品人员确认是否需要解决或发版前会议讨论处理方案。

相关推荐

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:数字20 设计师:CSDN官方博客 返回首页
评论

打赏作者

慕小芜

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值