E盾移动办公产品汇报.PPT

轻量级的开源缺陷跟踪系统 MANTISBT(Mantis Bug Tracker) ——WePu 2014-4-15 Mantis ？ How ？ Why Mantis ? 目 录 1、来到公司，看看我参与的Bug进度如何 email email email email 2、提交一个昨晚发现的Bug Bug 1 Bug 2 我的视图 提交问题 手动发海量的邮件 全自动，包括模板 自定义一个Bug说明模板，带着疑问把Bug报告上去（别人是否已经报告过这个Bug呢？） 邮件给项目负责人，负责人转发给开发…… 开发对觉得问题描述不清？ 简单，邮件反操作…… …… 流程模糊，谁在处理？ 流程清晰，分工明确 每个人都在迷雾中摸索 每个人都能纵观全局 分派问题 Why Mantis ? Why Mantis ? Mantis ？ How ？ 目 录 Mantis ? How ？ Mantis 介绍 Bug 结构 Bug 基本属性 角色 职责 Bug 处理流程 Mantis 规则 总结、回顾 Bug 结构 [V100R001C01]项目1 [V100R002C01]项目2 系统类Bug（公） 摄像头类（私） 系统类Bug（公） UI类（私） Bug 邮件通知 Bug 基本属性 Bug状态：新建、反馈、已分派、已修改（已解决）、已关闭 Bug严重性：细微、正常、严重 Bug出现频率：出现一次、一直出现、随机出现 Bug优先级：高、中、低 Bug的优先级代表开发修改的优先顺序。现分：高，中，低 开发负责人可以修改相应的级别，高优先级的问题开发必须当前做出反馈 在项目结项时无特殊情况不允许严重问题存在 角色 职责 报告 验证 解决 分派 协调 测试员 项目负责人 开发员 分派 管理员 维护系统 查看员 查看 关闭 重启 反馈 Bug流程 注释规范如下 软件版本： 问题描述： 问题原因：修复员最终需明确Bug产生原因 ！每个过程都必须要有相应注释 Mantis 规则 Bug在每个过程的停留时间不能超过2天（高优先级的Bug为1天，所有时间以提交，注释时间为准） 项目负责人接到Bug之后，要在规定时间将Bug分派出去 开发人员接到Bug之后，要在规定时间内给出响应 分派给其他人 添加一条注释，写入解决方案（或声明以接收该bug） 测试人员收到已修复的Bug，要在规定的时间内完成验证 测试人员提交一个被确认无效的Bug，或确定验证Bug已修复后仍有错误 项目负责人审核不合格，分派了一个本应打回或删除的Bug 开发人员确定问题已修复并经测试人员测试后发现问题仍存在 ！以上四条准则被触发，则将相应被记录在案 手动发送海量邮件，定义模板 人员混乱，分工不清晰 Bug处理流程不明确 所有人都看不到全局 回顾、总结 模板，邮件自动化 明确各自的角色和职责 Bug 流程清晰明确 人人都能纵观全局 Bug统计报表 发布新闻 …… Bug 结构：项目，分类，Bug，分类负责人 Bug 基本属性：状态，严重性，频率，优先级（与Bug时限为1天） 角色 职责：管理员，查看员，测试员，开发员，项目负责人 Bug 处理流程：报告— 审核—修复 — 验证—关闭（！每个步骤附相应注释） 约定的规则：Bug每个环节都具有时限 谢谢！ 制作人：方强 2014年 4 月 17 日