bugzilla使用手册(缺陷管理系统使用说明书V1.0版)

缺 陷 管 理 系 统 《使 用 说 明 书》

文件状态： [√ ] 草稿 [ ] 正式发布 [ ] 正在修改 作者： 编写日期 2011-4-10

部 门 名 测试部 审 核 人 审核时间 缺陷管理系统使用规范 V1.0 2 文档修改记录 日期 版本 变更说明 作者 2011-07-15 V1.0 草稿 缺陷管理系统使用规范 V1.0

3 目录 1 序言 ....................................................... 4 1.1 什么是Bugzilla ............................................................................................... 4 1.2 为什么使用Bugzilla...................................................................................... 4

2 BUGZILLA基本操作 ............................................ 5 3 BUG提交过程 ................................................. 5 4 BUG处理流程 ................................................. 7 5 对于BUG的不同处理情况 ..................................... 9 6 有关权限说明 .............................................. 10 7 查询操作 .................................................. 10 8 管理员操作指南 ............................................ 13 缺陷管理系统使用规范 V1.0

4 1 序言

1.1 什么是Bugzilla Bugzilla是Mozilla公司向我们提供的一个开源的免费缺陷跟踪工具。作为一个产品缺陷的记录及跟踪工具，它能够为我们建立一个完善的Bug跟踪体系，包括报告Bug、查询Bug记录并产生报表、处理解决、管理员系统初始化和设置四部分。并具有如下特点：  基于Web方式，安装简单、运行方便快捷、管理安全。 有利于缺陷的清楚传达。本系统使用数据库进行管理，提供全面详尽的报告输入项，产生标准化的Bug报告。提供大量的分析选项和强大的查询匹配能力，能根据各种条件组合进行Bug统计。当错误在它的生命周期中变化时，开发人员、测试人员、及管理人员将及时获得动态的变化信息，允许你获取历史纪录，并在检查错误的状态时参考这一记录。  系统灵活，强大的可配置能力。 Bugzilla工具可以对软件产品设定不同的模块，并针对不同的模块设定开发人员和测试人员；这样可以实现提交报告时自动发给指定的责任人；并可设定不同的小组。设定不同的用户对Bug记录的操作权限不同，可进行有效的控制管理。允许设定不同的严重程度和优先级，可以在错误的生命期中管理错误，从最初的报告到最后的解决，都有详细的记录，确保了错误不会被忽略，同时，可以让开发人员将注意力集中在优先级和严重程度高的错误上。  自动发送Email通知相关人员。 根据设定的不同责任人，自动发送最新的动态信息，有效的帮助测试人员和开发人员进行沟通。

1.2 为什么使用Bugzilla BUGZILLA是一个拥有强大功能的缺陷跟踪系统。它可以使我们更好的在软件开发过程中跟踪软件错误的处理过程，为开发和测试工作以及产品质量的度量提供数据支持，从而有效的保证软件产品的质量。 缺陷管理系统使用规范 V1.0 5 2 Bugzilla基本操作

适用范围：高层领导人员、项目经理、开发人员、测试组所有成员 用户登录及设置流程： 打开浏览器，在地址栏中输入： http://10.1.1.109进入Bugzilla主页面。在登陆项中输入E-Mail地址，在密码栏输入用户的初始密码（姓名全拼如wangtong），然后，点击【登陆】即可。 如忘记密码，请联系wangt@devdenter.com 成功登录后，点击页面中的“偏好设定”，然后选择【姓名和密码】，进行密码修改。 点击【设置】->【电子邮件设置】，进行邮件通知设置。 点击【设置】->【权限】，进行权限查询。

注意：在登陆使用系统之后，一定要退出登陆，因为在BUGZILLA中存在一个隐患——当你没有退出登陆而关闭页面，当用同一台机器再次访问的时候，系统会以上次登陆的用户访问。

3 Bug提交过程 适用范围：测试组所有人员 具体操作如下： 成功登陆缺陷管理系统后，在系统首页点击【新建】或点击【输入新BUG】，点击bug所在的项目，系统显示输入缺陷界面（见图1）； 1、选择发现的bug所在的产品名称； 2、子产品（功能模块）：点击选择列表中的子产品。可以查看关于这个产品的子产品的详细信息； 3、选择对应的版本号，严重程度、优先程度信息； 4、硬件平台、操作系统：可以根据发现bug的实际情况来选择，如果确定这个bug可以发生在所有的平台，选择all就可以； 5、严重性：严重、一般、轻微、优化，严重程度逐渐减弱； 缺陷管理系统使用规范 V1.0 6 6、优先级：紧急、优先、一般、次要，优先级逐渐减弱； 7、初始状态：默认状态为“新建（NEW）”； 8、分配给谁负责: 默认是后台设定好的一般不用修改, 也可手工制定，直接修改即可； 9、邮件组（抄送给谁）: 可为多人，需用"，"隔开，一般抄送都默认加到了预设邮件组里这里一般不手工填写； 10、 预设邮件组：后台默认添加的必须抄送人； 11、 估计小时数、截止期限、网址: bug的定位（可选） 12、 摘要：是对bug的概述（必须填写）； 13、 描述中要详细说明下列情况： 1） 发现问题的步骤 2） 执行上述步骤后出现的情况 3） 期望应出现的正确结果 14、 附件：点击【新增附件】，根据实际情况，为了更进一步描述bug，可以提交bug出现的错误图片等文件。 15、 依赖于和会屏蔽的BUG：直接输入与当前bug有依赖关系的bug的编号。简单地说，比如说这里输入“3”，那么就是说当前提交的bug有依赖关系，不是由于3导致了当前bug，就是当前bug导致了bug3。 确认无误后，点击【确认】即可。 缺陷管理系统使用规范 V1.0

7 图1 提交之后，系统会提示：bug 已经提交。在此页面的下半部分，会再次显示刚才提交的bug的详细信息，你可以在这里进行修改，重新提交,也可以在此增加新的附件或是附加说明来进一步说明bug。 冲突:当两个或几个人同时修改一个bug提交信息的时候，bugzilla会有弹出 Mid- air collision!提示，并且列出解决冲突的选择，若提交修改，会导致覆盖别人所做的修改；若不改，返回。建议选择返回，看看别人修改了什么，不同的话，添加一个附加说明来补充吧！！ 以上各项可能会因为权限的关系，有所缺省。 注意：如果要提交的bug已经存在，系统会给出提示相应不能提交的信息，若有什么建议，可在原有记录中增加注释，告知其属主。

4 Bug处理流程 适用范围：项目经理、开发人员、测试组所有成员 1、测试人员发现bug后，判断属于哪个子产品（功能模块）的问题，填写bug报告后，系统自动通过Email通知bug负责人（项目经理或开发人员）。 2、bug负责人根据具体情况，重新分配给bug所属的开发者。 缺陷管理系统使用规范 V1.0 8 3、开发者收到Email信息后，判断是否为自己的修改范围。 1） 若不是,重新分配给项目负责人或应该分配的开发者。 2） 若是，进行处理，并给出解决方法。 4、测试人员查询开发者已修改的bug，进行回归测试。 1） 经验证无误后，测试人员修改状态为已认证（VERIFIED）。待整个产品发布后，修改为已关闭（CLOSED）。 2） 若经验证仍有问题，测试人员修改状态为重开启（REOPENED），并会自动邮件通知。 5、如果这个BUG一周内一直没被处理过。Bugzilla就会一直用email骚扰它的属主，直到采取行动。管理员可以设定最迟采取行动的期限，比如说3天，系统默认为7天。BUG处理流程见下图：

说明：对于测试人员新提交的缺陷，必须经过项目经理分配后，开发人员才可以修改，并注明修改意见。如果项目经理不分配缺陷，开发人员只有浏览缺陷的权利，不可以执行任何修改操作。

Bug开始 初始状态 指派处理人员 二次指派 处理Bug 确认处理 关闭 Bug结束

重新 打开 缺陷管理系统使用规范 V1.0

9 5 对于Bug的不同处理情况

适用范围：项目经理、开发人员、测试组所有成员 1、Bug的属主 (owner) 处理问题，提出解决意见及方法。 给出解决方法并填写附加说明（Additional Comments），并需要选择BUG处理结果，5种处理结果如下： 1) FIXED（已修复）：描述的问题已经修改，该bug已经修复并检查过，源文件已经检入SVN库。 2) NVALID（无效）：描述的问题不是一个bug (输入错误后，通过此项来取消) 3) WONTFIX（决定不改）：描述的问题将永远不会被修复。 4) DUPLICATE(重复bug):描述的问题是一个存在的bug的复件。 5) 好好的WORKSFORME (无法重现)：所有要重新产生这个bug的企图是无效的。如果有更多的信息出现，请重新分配这个bug，而现在只把它归档。 注意：开发人员在修改缺陷后，必须选择以上处理结果。 2、项目经理或开发者重新指定Bug的属主。 bug不属于自己的范围，可在负责人处点击编辑,指定BUG责任人是项目经理，此时等待项目经理重新指定。 1) bug不属于自己的范围，但知道谁应该负责，在负责人处点击编辑直接输入被指定人的Email。 2) 操作结果：此时bug状态又变为“新的”，此bug的负责人变为被指定的人。 3、 测试人员验证已修改的 Bug 1) 测试人员查询开发者已修改的bug，即状态为"已解决", 解决方案为"已修复"，进行回归测试。 2) 经验证无误后，修改“已解决”为“已认证”。待整个产品发布后，修改为“已关闭”。 3) 若测试之后发现还有问题，修改为“重开启”，状态重新变为“新的"，并发邮件通知BUG属主。