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

----

==== 整体流程规范 ====
{{:images:mantis-standard.png}}
<note important>
项目负责人遇到无效，重复Bug，会直接关闭，否则只有测试人员才能关闭
</note>
----


==== BUG提交规范 ====

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

描述：
  * [软件版本] 提交给问题的软件版本
  * [前提条件] 描述复现该问题的前提条件
  * [操作步骤] 复现该问题的操作步骤，分为步骤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>


----

==== Bug严重性 ====
  * 细微　（细微的UI错误，显示格式错误……）
  * 正常　（性能，兼容性，功能有误……）
  * 严重　（系统无法稳定运行，卡死，宕机……）
<note important>项目结项时不允许有严重性Bug存在</note>

----

==== Bug优先级 ====
  * 高（生产线上的Bug，非常紧急的Bug,但不一定非得是严重性Bug）
  * 中（正在开发的应用）
  * 低（没什么副作用且没时限性的Bug）
<note important>高优先级的Bug响应时限是　1　天；中低优先级Bug响应时间是　2　天</note>

----

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