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

本文来源：https://www.bwwdw.com/article/2ts.html