BUG处理流程规范.doc

BUG提出和处理步骤规范

1引言
1. 1目
提升测试以及产品缺点修改效率, 避免出现搁置和遗漏缺点, 从而提升产品质量, 降低质量检验和缺点修改成本
1. 2适用范围
适适用于研发部门（Confernece、 Flash、 监控）, 质量确保部门
1.3 定义
bug: 经过测试检验出产品缺点;
新建、 打回、 已确定、 已指派、 已处理、 已关闭: 测试中bug不一样状态, 具体信息见本规范第3部分;

1. 4参考资料
无
2 BUG提交和处理规范说明
1、 在测试人员提交bug时候, 必需对bug信息进描述必需具体全方面、 清楚明确, 假如有条件, 需要描述使用环境, 在BUG出现前具体操作, 假如抓图, 必需抓取jpg全屏图象, 但不能使用BMP格式上传到BUG库中, 有抓包文件需要上传BUG库, 空间不够需要放到\\192.168.0.254\qa\测试\bug日志目录中, 标题以BUG号区分;

2、 在测试人员提交bug时候, 必需按具体情况, 填写关键等级、 出现频率、 优先等级三个栏目, 而非测试人员不得对上述信息进行直接改变, 如认为这三个信息填写不合适, 能够在该bug下注解中提出意见, 并“打回”给bug提交人员或质量部经理处, 经过确定后修改;
3、 开发人员对bug进行处理后变更状态成“打回”时, 或“指派”给产品部门时以及变更成“已确定”时必需进行必需描述和说明,在状态变更时, 必需要指定具体接收人;
4、 开发人员在注解中描述该BUG计划什么时候处理或做其她叙述时候, 要明确写清承诺具体版本号, 严禁使用“上一版本”、 “本版本”、 “下一版本”等字样, 以免造成误会或混淆;
修改完成BUG注释中加入相关确定信息, 如“XXX Review并经过。
5、 假如已经是“关闭”状态BUG, 测试人员在后期测试中又出现了需要重新打开, 重开后BUG状态为“打回”, 测试人员需要再多一个操作, 即“指派”给具体研发人员。
6、 一直处于“打回”状态BUG, 测试人员需要经过两轮（即两个版本测试后仍然没有重现, 能够关闭。不过此两轮测试在该BUG中必需有注释, 比如: “XX版本（要求有具体版本号）测试没有重现”, 当第二轮测试仍没出现时也需要注释一次, 即可进行关闭。
3 Mantis
Mantis是PHP/MySQL/Web-based缺点跟踪系统。
其特点:

个人可定制Email通知功效, 每个用户可依据本身工作特点只订阅相关缺点状态邮件;
支持多项目、 多语言;
权限设置灵活, 不一样角色有不一样权限, 每个项目可设为公开或私有状态, 每个缺点可设为公开或私有状态, 每个缺点能够在不一样项目间移动;
主页可公布项目相关新闻, 方便信息传输;
支持上传文件, 提供深入bug信息;
支持上传项目文档;
方便缺点关联功效, 除反复缺点外, 每个缺点都能够链接到其她相关缺点;
缺点汇报可打印或输出为CSV格式。支持可定制报表输出, 可定制用户输入域;
有多种缺点趋势图和柱状图, 为项目状态分析提供依据, 假如不能满足要求, 能够把数据输出到Excel中深入分析;
步骤定制不方便, 但该步骤可满足通常缺点跟踪。
在提交bug时需要填写相关信息, 还能够上传相关文件（如犯错log或者截图等）, 对于bug添加注释（许可再次更新）。下面是基础信息介绍

[出现频率]
可重现-- 稳定地能重现
常常-- 比较常常出现
偶然 -- 偶然出现
不可重现 -- 无法重现
N/A -- 其她情况

[严重性]
不合理或别扭 -- 使用不方便, 吹毛求疵标准
文本错误-- 文本错误
瓦解死锁 -- 造成死机bug
严重错误 -- 造成功效无法正常运行下去
次要错误---功效性问题

[优先权]
高-- 优先级高
中 -- 一般优先级
低 -- 优先级较低, 有时间就处理
加急 -- 紧急bug,立刻处理
特急 -- 刻不容缓, 立即需要处理
无 -- 无关紧要, 能够慢慢处理

[bug状态]
新建 -- 新加入
打回 -- 需要更多诊疗信息, 需要bug提交者提供
已确定 -- 看过了, 确定问题和指派
已分配 -- 指派给程序员处理
已处理 -- 应该已经处理了, 等候测试确定
已关闭 -- 关闭bug, 确定已经处理

一个经典bug跟踪步骤:
由测试人员提交bug, 假如经过协商确定这不是bug, 由测试人员直接“关闭” bug。假如是bug, 不过可能延期到下一个版本或者不着急处理, 由测试或者开发人员将状态设为“已确定”。假如是需要修改bug, “指派”到相关开发人员负责。开发人员在完成bug修改后将bug状态修改为“已处理”。然后由测试人员再次测试后确定bug修改了, 将bug状态设为“已关闭”。这么一次bug修改就完成了。

但还有特殊情况, 有时候关闭bug会再次出现, 这时候需要重新打开 bug, bug状态变为“打回”, 重新进入“指派”或者“确定”步骤。
能够注意到上面步骤中, “开发人员”是无权关闭bug, 她只能把bug标识为resolved等候“测试人员”或者其她管理人员关闭 bug。

[mantis在权限实现方面支持下面多个权限用户]
查看人员 -- 只能观看bug情况用户
汇报人员 -- 只能提交bug用户
修改人员 -- 能够提交bug和更新bug状态
开发人员 -- 有很高权限, 能够对BUG进行修改、 指定、 处理、 关闭、 删除。
经理 -- 管理project用户, 能够将开发人员指定给某个项目。
管理员 -- 系统管理员

在mantis权限控制系统中“开发人员”拥有对bug生存周期全部权限, 个人感觉这是不妥, 最少关闭、 删除 bug权限要属于bug“汇报者”或者“经理”一级, 有时间话能够对于系统进行相关定制。

另外mantis值得注意功效就是Email通知和图形统计功效, Email通知许可用户经过Email跟踪bug状态, 而且立刻地通知bug全部者（被指派到开发人员）相关信息。
图形统计功效能够统计bug种类和其她基础信息。