Bug生命周期


状态
决议栏位用来定义和跟踪Bug的生命周期。
状态决议
"状态"栏位用来指示bug的健康状况,只允许确定的状态转换。决议栏位表明bug发生了什么。
未确认[UNCONFIRMED]
    
这种bug已经被添加到数据库里了。但还未验证这种缺陷是对的还是错的。那些有“CAN CONFIRM”权限的用户能验证它,把它的状况转变成NEW。或者,它能直接被解决掉,并被标注成RESOLVED。
新[NEW]    这种bug已经被添加到待分配的列表目录里了,并且必须被处理。在这种状况下的bug可能变成ASSIGNED,传递给其他的用户;否则保留为NEW;或者被解决掉,以RESOLVED作为标记。
已分配[ASSIGNED] 
    这种bug还没有被解决,但是被分派给了合适的用户。在这里,bug能重新指派给其他用户。
 重开[REOPENED]   这种bug曾经被解决过,但是结果看起来好象不正确,这bug仍然够重现出来。
    还没有解决方案。在这些OPEN状态下,bug的决议栏位是空的。其他状态的那些bug将用下面的解决方式标记。
已解决[RESOLVED] 
    已有了决议,正等待QA的验证。从这种途径,bug要么是重启,标注为REOPENED,或者被标记为CLOSED。 

已验证[VERIFIED] 
    QA已经查看了这个bug和它的决议,并且同意采取这种恰当的决议。bug将保持在这种状况下,直到这个项目/产品已完成,在这个程度它们变为 CLOSED。 

已关闭[CLOSED] 
    这种BUG被确认为清除了,而且解决办法是正确的。如果想重新复活这个bug,必须把它变为REOPENED。
已解决[FIXED]
     一个bug已经被修改并已被测试。 

无效[INVALID]
 
    这个问题描述的不是一种bug。 

无法修复[WONTFIX]
    这个描述是一个bug,但无法解决。 

无法重现[NOTREPRO]
    按照重现步骤,无法重现这个bug

重复了[DUPLICATE]
 
    这个bug跟现有bug重复了。

外部的[EXTERNAL]

    这个BUG是由于外部原因引起的。

无线索[WORKSFORME]
    对于解决这个bug的所有努力都是徒劳无益的,并且阅读这些编码也找不到线索。如果更多的信息出现的话,这个bug能够被重启。 

严重性 
这个栏位用来描述的是bug的危害有多严重。
阻塞 [Blocker]阻碍开发或者测试工作
危险 [Critical]崩溃,数据丢失,严重的内存泄露
一般 [Major]主要的功能失效
次要 [Minor]次要的功能失效,或者发生一些简单的问题。
琐碎 [Trivial]象拼错单词那样的表面错误,或者字符位置错误等。
增强 [Enhancement] 对系统的改进要求或需求。


优先级 
    这个栏位描述的是bug应该被修复的重要性和次序。这些工作是通过程序员/工程师来把它们区分优先次序而完成的。可运用的优选范围是从P1(最重要)~P5(最不重要)。 

负责人
 
    这是负责解决bug的人员。分为:
    处理人[Processer]是实际处理这个Bug的人员,
    测试人[Tester]是负责测试这条Bug的人,
    验证人[Validater] 验证这条Bug真的解决了。
    其他人员[Others] 其他类型的参与人员。
在软件开发中,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、付费专栏及课程。

余额充值