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：需要立即进行修改
说明：优先级与BUG自身的等级并不是完全一致的，例如有些bug属于严重级别的错误,但是却只是偶尔的出现一次,不影响软件的正常使用,这样的bug的优先级可以适当的降低， 而有些bug虽然是不严重的错误，但是却是一直出现的，对软件的使用者造成比较大的困扰，这样的bug就要根据情况适当的提高优先级了，即bug的优先级可以认为是上面的Severity(严重等级)和Reproducibility(出现频率)的综合考虑。
当然,优先级的选择问题是与reporter本身的理解关系很大的，不同的reporter对于同样的一个bug可能会选择不相同的优先级，主要是根据自己的经验和理解来做出比较合适的选择
Mantis中的BUG状态(Status)和解决状态(Resolution)的说明
状态:
新建New：测试人员报告一个新bug并且没有指派给具体的开发人员修改时的状态
打回Feedback：开发人员认为此bug不需要修改，就将其反馈。测试人员和开发人员讨论评估后，决定是否将其关闭
公认Acknowledged：该bug在大部分模块中或页面中都会出现，将其设为Acknowledged（由开发人员确认）
已确认Confirmed：开发人员（QA）确认存在此bug，并准备修改，将其设为confirmed
已分派Assigned：将新建bug指派给某个指定的开发人员后，状态变为Assigned（一般由项目经理做）
已解决Resolved：开发人员（QA）确认bug已经解决，测试人员可以进行验证测试了
已关闭Closed：确认bug已解决,关闭
解决状况:
未处理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
说明：status主要是QA来设置修改,而resolution则是相关的开发人员和项目经理来进行修改的.但是也并不完全如此,中间还是有交叉的几项,例如status中的“打回”是当开发人员或者项目经理没有看明白bug的描述的时候将bug设置成为的状态;而resolution中的“重新打开”则应该是QA在测试相关的解决方案后发现其不正确后将resolution修改为重新打开。
QA：即英文QUALITY ASSURANCE 的简称，中文意思是品质保证，其在ISO8402：1994中的定义是“为了提供足够的信任表明实体能够满足品质要求，而在品质管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。有些推行ISO9000的组织会设置这样的部门或岗位，负责ISO9000标准所要求的有关品质保证的职能，担任这类工作的人员就叫做QA人员。
