软件测试之bugzilla对bug跟踪的管理流程、bug报告分类和处理意见

描述使用bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程

1． 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，通过Email通知项目组长或直接通知开发者。

2． 项目组长根据具体情况，重新reassigned分配给bug所属的开发者。

3． 开发者收到Email信息后，判断是否为自己的修改范围.

    1） 若不是,重新reassigned分配给项目组长或应该分配的开发者。

    2） 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充明）

4． 测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件）

    1） 经验证无误后，修改状态为VERIFIED。待整个产品发布后，修改为CLOSED

    2） 还有问题，REOPENED，状态重新变为“New”，并发邮件通知。

5． 如果这个BUG一周内一直没被处理过。Bugzilla就会一直用email骚扰它的owner，直到采取行动。

补充说明：

Bug报告分类

• 待确认的（Unconfirmed）
• 新提交的（New）
• 已分配的（Assigned）
• 问题未解决的（Reopened）
• 待返测的（Resolved）
• 待归档的（Verified）
• 已归档的（Closed）

Bug处理意见

• 已修改的（Fixed）
• 不是问题（Invalid）
• 无法修改（Wontfix）
• 以后版本解决（Later）
• 保留（Remind）
• 重复（Duplicate）
• 无法重现（Worksforme）

指定处理人：可以指定一个处理人，如不指定处理人，则系统指定管理员为默认处理人

链接：输入超链接地址，引导处理人找到与报告相关联的信息

概述：概述部分“Summary”的描述，应保证处理人在阅读时能够清楚提交者在进行什么操作的时候发现了什么问题。如果是通用组件部分的测试，则必须将这一通用组件对应的功能名称写入概述中，以便今后查询。

平台操作系统：测试应用的硬件平台（Platform），通常选择“PC”