Mantis 规范

Mantis 规范

• Mantis中对很多字段，属性分的很细，很多对我们来说意义不大
• 有些反而复杂化了整个系统，使之难以理解和使用
• 我们从中提取对我们有用的，并形成约定，以标准化我们的操作。

---

整体流程规范

 

---

角色分类

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

---

角色分工

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

开发人员无关闭bug的权限，所有bug只有测试人员才能关闭

---

Bug严重性

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

项目结项时不允许有严重性Bug错在

---

Bug优先级

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

高优先级的Bug响应时限是　1　天；中低优先级Bug响应时间是　2　天

---

Bug状态

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

---

Bug出现频率

• 出现一次
• 一直出现
• 随机出现

---

BUG提交规范

摘要：

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

描述：

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

---

注释规范

测试人员：

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

开发人员：

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

---

审计约定

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

触发以上四条准则，则将相应被记录一次过失