[请教]Mantis中的issue的status＆resolution

apron

^_^,这几天问题问的很频繁哦
不过没办法啊
实在是不明白啊

就是mantis中的issue有这样的两个属性

status＆resolution

其中
status有如下的选项:
New
Feedback
Acknowledged
Confirmed
Assigned
Resolved
Closed

resolutin有如下的选项
Open
Fixed
Reopen
Unable to reproduce
Not fixable
Duplicate
No change required
Suspended
Won't fix

偶有点迷惑,只知道当reporter提交issue没有指派给任何人的时候,status会自动的成为new的状态;当指派给某个人的时候,status会自动的成为assigned的状态
至于其他的几个状态,想请问大家什么时候指定bug为那种状态的.还有一般是什么人去指定这个状态的呢?

resolution偶就更迷糊了,还请大家指教是什么样的情况下才去改变bug到某种特定的状态的啊

先谢过大侠们!

apron

这个是参考了很多种的理解以后我自己觉得比较合适的一些解释
有什么不一样的理解大家要提出来哦,顺便贴个word的小文档

Mantis中的BUG等级的划分(Severity)
Feature —— 新特性  一般用来指系统缺乏一个所需要的特性
Trivial ——  微不足道  比较小的问题,例如用户界面中Button位置等
Text ——    文字错误  文字上的拼写错误
Tweak ——  不合理/别扭  如: ￥123.345等
Minor ——   次要错误  不能用上述分类界定的,报告人认为是严重程度比较轻的问题
Major ——   严重错误  不属于系统崩溃和死锁类的,但报告人认为比较严重的错误
Crash ——   系统崩溃  引起系统崩溃的错误
Block ——   系统死锁  引起系统死锁的错误
Mantis中的BUG可重现性的说明(Reproducibility)
Always ——  总是出现,每次尝试都会出现
Sometimes ——  有时出现,相对于下面的“随机”频率要高一些
Random  ——   随机出现
Have not tried ——  还没有尝试  即发现bug的操作只进行了一次
Unable to reproduce —— 不可重现  只发现一次,之后的尝试都无法再现
N/A  ——  Not Applicable/Acceptable  不可/适用 即再次尝试的时候出现bug的功能不能用了
Mantis中的BUG优先级的说明:
None —— 相关的bug已经resolve不存在了或者觉得优先级没有必要体现
Low —— 低优先级,留到最后解决,如果项目的进度很紧张可以在产品发布以前不解决
Normal —— 中等优先级
High —— 高优先级,将处于Immediate和Urgent优先级的bug修改完毕后要进行修改
Urgent —— 紧急,一到两天之内必须进行修改
Immediate —— 需要立即进行修改

NOTE: 优先级与BUG自身的等级并不是完全一致的
例如有些bug属于严重级别的错误,但是却只是偶尔的出现一次,不影响软件的正常使用,这样的bug的优先级可以适当的降低. 而有些bug虽然是不严重的错误,但是却是一直出现的,对软件的使用者造成比较大的困扰,这样的bug就要根据情况适当的提高优先级了.即bug的优先级可以认为是上面的Severity(严重等级)和Reproducibility(出现频率)的综合考虑.
当然,优先级的选择问题是与reporter本身的理解关系很大的.不同的reporter对于同样的一个bug可能会选择不相同的优先级.这个也很难有一个统一的标准来衡量的,还是要根据自己的经验和理解来做出比较合适的选择.经验越丰富,这个选择就会相应的越合适越有说服力了!

Mantis中的BUG状态(Status)和解决状态(Resolution)的说明
Status:
New —— 当reporter新提交一个bug,不给其指派所有者的时候,bug的状态会自动的成为new的状态.(我们的权限设置,默认的reporter并没有指派的权利,所以reporter提交的一定是new状态的bug.)
Feedback —— 要求reporter再次对bug进行说明
Acknowledged —— 开发人员解决了bug以后QA已经了解但是还没有来得及确认
Confirmed —— bug的解决方案得到了QA的确认
Assigned —— 当将bug指派给他所属的开发人员之后,bug的status会自动的并成为assigned
Resolved —— bug已经被解决但是还没有得到QA的验证
Closed —— 当bug已经确认被解决或者确认不是bug的时候将bug的状态改为closed
Resolution:
Open —— bug没有被解决
Fixed —— bug的修改已经登记并经过测试
Reopen —— bug曾经被解决,但是解决方案被认为不正确
Unable to reproduce —— 不可重现,被指派的开发人员想要再现bug进行修改的时候发现bug始终不能再现的时候将bug的resolution设置为此项
Not fixable —— 不能修改这个bug
Duplicate —— 与某个已经存在的bug重复
No change required —— 经理和相关开发人员经过需求和设计的核实后决定不需要修改
Suspended —— 延期,一般是指当前版本不进行修改,下个版本再提供解决方案
Won’t fix —— 不准备修改这个bug

NOTE: 个人的理解, status主要是QA来设置修改,而resolution则是相关的开发人员和项目经理来进行修改的.但是也并不完全如此,中间还是有交叉的几项,例如status中的”feedback”是当开发人员或者项目经理没有看明白bug的描述的时候将bug设置成为的状态;而resolution中的”reopen”则应该是QA在测试相关的解决方案后发现其不正确后将resolution修改为reopen.如果将reopen和feedback交换一下位置的话就不会有这样的交叉了!^_^

apron

作一点点小的更正或者说明吧
confirmed和acknowledged的一点小更正
如果你们的mantis是挂在网上同时用于customer的issue反馈的话
confirmed可以理解成客户反馈的bug得到了QA的确认,确实是个bug
而acknowledged这个时候的理解就可以变成是开发人员的解决方案得到了QA的公认了

yolander

我的理解是confirmed也可以认为是bug提交人员对开发人员修改的bug进行确认后的状态，接下来就可以关闭了
因为有的软件测试公司他们的工作流程中就有这样一个已确认状态，由bug reporter确认bug，由测试工程师关闭

apron

^_^,原始的理解就是这样的

yolander

你说的是QA的确认，我说的是经过提交者进行的确认测试后的一个状态，还是有点差别的吧

testsky

status有如下的选项:
New                  报告一个bug时,没有指派给具体的开发人员修改时,就是new状态
Feedback          反馈,当开发人员修改不正确时,把该bug反馈给他,重新修改
Acknowledged   bug问题是公共的,所多页面,都在这样的情况,设为Acknowledged   
Confirmed          开发人员改完一个 bug后,就把该bug的状态,变成已确认,测试人员看bug状态变成确认时,就来再次检查
Assigned            已指派,当新建一个bug时,已经知道这个bug将由who修改了,就直接修改该bug
Resolved           bug已经确认,认定是bug但因为技术的问题,暂时不解决
Closed               确认bug已解决,关闭

lzpcn

有没有搞错啊!骗分的

盈非莹

New                 测试人员报告一个新bug并且没有指派给具体的开发人员修改时的状态
Feedback          开发人员认为此bug不需要修改，就将其反馈。测试人员和开发人员讨论评估  
                       后，决定是否将其关闭。
Acknowledged   该bug在大部分模块中或页面中都会出现，将其设为Acknowledged（由开发人员
                       确认）
Confirmed          开发人员确认存在此bug，并准备修改，将其设为confirmed
Assigned            将新建bug指派给某个指定的开发人员后，状态变为Assigned（一般由项目经理
                       做）
Resolved           开发人员确认bug已经解决，测试人员可以进行验证测试了
Closed              确认bug已解决,关闭

thebestzhao

最近正在研究

bingyu

我们公司也是用的mantis，不过我们用的是中文版的！

刘洪鹏

谢谢哦

fiona82

11

Echo-Sun

謝謝分享

zoeyan

谢谢