• Mantis中对很多字段，属性分的很细，很多对我们来说意义不大
• 有些反而复杂化了整个系统，使之难以理解和使用
• 我们从中提取对我们有用的，并形成约定，以标准化我们的操作。
• 这是根据公司目前状况形成的一套规范，不排除人员扩建后机制会有调整

<note important> 项目负责人遇到无效，重复Bug，会直接关闭，否则只有测试人员才能关闭 </note>

摘要：

• 尽量精简的语句将问题描述清楚，要确保在保证精简的情况下不引起歧义，确保描述完整（字数限制）

描述：

• [软件版本] 提交给问题的软件版本
• [前提条件] 描述复现该问题的前提条件
• [操作步骤] 复现该问题的操作步骤，分为步骤1,2,3……
• [实际结果] 描述软件出现问题的实际现象
• [期望结果] 描述软件正常时的现象

测试人员：

验证问题添加注释时，需要明确标明验证该问题使用的版本，使用当前版本验证后问题是否存在，如问题还存在需简单描述现象
必填字段
* 软件版本：
* 问题描述：该问题不再复现/ 该问题仍然存在

开发人员：

问题修复之后，需要添加注释标明修复的软件版本并针对添加该问题出现的原因
必填字段
* 修复版本：
* 问题原因：*************

• Bug在每个过程的停留时间不能超过2天（高优先级的Bug为1天，所有时间以提交，注释时间为准）
• 项目负责人接到Bug之后，要在规定时间将Bug分派出去
• 开发人员接到Bug之后，要在规定时间内给出响应
  • 分派给其他人
  • 添加一条注释，写入解决方案（或声明以接收该bug）
• 测试人员收到已修复的Bug，要在规定的时间内完成验证
• 由于测试人员疏忽，提交一个被确认无效的Bug
• 项目负责人审核不合格，分派了一个本应打回或删除的Bug
• 开发人员确定问题已修复并经测试人员测试后发现问题仍存在

<note important>为了统计我们哪些地方做的不足，以上的行为数据将会被统计</note>

• 管理员（维护整个系统）
• 项目负责人（全局跟进所管辖的Bug）
• 开发员（负责修复Bug）
• 测试员（提交Bug）
• 查看员（查看Bug）

• 管理员：新建项目，管理项目分类，管理项目各个关键字，管理项目人员
• 项目负责人：审核问题指派问题，修改问题，修改问题状态，移动，删除，重启问题
• 开发员：解决问题，分派问题，反馈问题
• 测试员：报告问题，验证问题，关闭问题，重启问题
• 查看员：只能查看公开项目中已经提交的问题

<note important>开发人员无关闭bug的权限，所有bug只有测试人员，项目负责人才能关闭</note>

• 细微　（细微的UI错误，显示格式错误……）
• 正常　（性能，兼容性，功能有误……）
• 严重　（系统无法稳定运行，卡死，宕机……）

<note important>项目结项时不允许有严重性Bug存在</note>

• 高（生产线上的Bug，非常紧急的Bug,但不一定非得是严重性Bug）
• 中（正在开发的应用）
• 低（没什么副作用且没时限性的Bug）

<note important>高优先级的Bug响应时限是　1　天；中低优先级Bug响应时间是　2　天</note>

• 新建（刚报告的一个Bug时的状态）
• 已分派（将Bug分派给其他人时的状态）
• 反馈（开发员对Bug有疑问，反馈给测试时的状态）
• 已解决（开发员修复Bug时的状态）
• 已关闭（测试员严重Bug被修复时的状态）