bug生命周期

首先知道bug的管理工具有禅道,jair,bugfree这些都是bug管理工具

      

      创建bug-----修改bug------验证bug------关闭bug这就是最基本的生命周期


      载体bug的时候会遇到如下问题:

              bug可以改成---已修改---

              不予解决:就是开发不给解决这个bug,这个时候你怎么办:

                    首先找开发去沟通,看看是什么原因造成的不给解决,看看有没有可能简单沟通一下,态度好点的bug解决掉,如果开发还是不解决,有测试经理找测试经理,没有测试经理找项目经理,将问题向上反映;

           

      开发说bug延期处理你该怎么办?

                     首先确定这个bug是什么类型的如果是自己项目里面的bug,而且还影响主要功能的使用,绝对不可能延期,如果是第三方原因造成的bug,比如分享每个平台是不一样的,这样的bug是可以延期的,必须通知项目经理的, 只有项目经理同意延期,才能延期,不然是不能延期的;


      如果说bug是外部原因造成的:

                     比如环信发送消息不能及时收到,这个时候一定要通知项目经理,是需要更换技术框架,还是能接受这个的;


       bug三大分类:致命缺陷,严重缺陷,一般缺陷;

                    致命缺陷:造成系统程序崩溃,系统悬挂,数据丢失,以及主要功能完全丧失都属于致命缺陷;

                     严重缺陷:主要功能存在严重缺陷,但不会影响到系统稳定性。

                                        比如:1. 功能未实现;2.功能存在报错;3.数值轻微的计算错误。

                     一般缺陷:这样的缺陷虽然不影响系统的基本使用,但没有很好的实现功能,没有达到预期的效果,

                                       比如:1主要功能丧失;2提示信息不正确;3用户界面较差;4操作时间长


       一个按钮点击没反应,如何判断是前端bug还是后台bug:

                    首先一般我们采用灰盒或者白盒,灰盒测试主要通过fiddler抓包,当点击按钮那一刻,通过fiddler看看有没有进行网络请求,如果没有进行网络请求说明是前端bug,有可能是前端没有调用网络请求的方法,如果进行了网络请求,但是没有返回数据,那就是后台bug,如果进行了网络请求,而且数据也正确返回那就是前端bug,如果进行了网络请求,返回数据不对那就是后台bug;


        测试需要的文档:需求文档,接口文档,产品原型图,UI设计图,开发规范文档

   

在软件开发中,Bug生命周期管理是一个系统化的过程,旨在跟踪和处理缺陷从发现到最终解决的全过程。Bug生命周期通常包括多个状态,这些状态描述了缺陷在不同阶段的处理情况。 当一个 Bug 被首次发现时,它通常会被标记为 "New" 状态,这意味着缺陷已经被记录,但尚未被评估。随后,这个 Bug 会被提交给开发团队进行评估,在此阶段,Bug 的状态可能会被更新为 "Assigned",表示已经指派给特定的开发人员来处理。 一旦开发人员开始调查 Bug,它的状态可能会变为 "Open",这表明开发人员正在分析问题,并准备着手修复。如果确认这是一个有效的问题,开发人员将开始修复工作,此时 Bug 进入修复阶段。修复完成后,Bug 的状态通常会更改为 "Fixed" 或者类似的术语,表明问题已经被解决。 修复后的 Bug 需要经过验证,以确保修复确实解决了问题,并且没有引入新的问题。在这个阶段,Bug 的状态可能是 "Testing" 或者 "Verification"。如果验证成功,Bug 的状态将变为 "Closed" 或 "Resolved",表示问题已经得到解决并且经过验证。 然而,有时候在验证过程中可能会发现修复并没有解决问题,或者出现了新的问题,这时 Bug 可能会被重新打开,状态回到 "Open" 或者被标记为 "Reopened",以便进一步处理。 此外,还有可能出现这样的情况:某个 Bug 被认为是由于需求变更或其他原因而不需要修复,这时它的状态可能会是 "Won't Fix" 或者 "Deferred"。 在整个生命周期中,有效的沟通和协作对于确保 Bug 得到及时处理至关重要。测试人员、开发人员以及其他相关人员需要紧密合作,共同确保软件产品的质量和稳定性。 对于一些特殊情况,例如时间紧迫导致无法进行充分的回归测试,测试人员需要权衡是否修复 Bug 的利弊,有时选择不立即修复可能是更为合理的决策 [^3]。 ### 示例 Bug 生命周期状态转换 ```plaintext New -> Assigned -> Open -> Fixed -> Testing -> Closed ``` ### 示例 Bug 管理流程中的状态转换 ```plaintext New -> Assigned -> Open -> Fixed -> Testing -> Reopened -> ... ``` 需要注意的是,不同的组织和项目可能会有不同的命名习惯和流程细节,上述流程提供了一个通用的框架。实际应用中,可以根据项目的具体情况调整 Bug生命周期管理流程。例如,一些项目可能会使用更加细化的状态来更好地控制 Bug 的处理流程。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值