BUG处理流程规范

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的种类和其他基本信息。