Bugzilla使用手册
- 格式：pdf
- 大小：1.14 MB
- 文档页数：17
Bugzilla使用手册bugzilla使用手册 (3)1简介 (3)1.1编写目的 (3)1.2适用范围 (3)1.3概述 (3)2操作指南---针对开发和测试人员 (4)2.1登录 (4)2.2BUG处理过程 (4)2.3BUG提交过程 (5)2.3.1查询 (5)2.3.2Bug的提交过程 (6)2.4Bug查询 (8)2.4.1Find a Specific Bug (8)2.4.2Advanced Search (8)2.5Bug处理 (9)2.5.1测试or开发人员 (10)2.5.2测试人员验证已修改的Bug (11)2.5.3Bug报告者（reporter）或其他有权限的用户修改及补充Bug (11)3Bugzilla管理员操作指南 (11)3.1创建classification，product，component和version (11)3.2增加groups (13)4权限问题----管理员操作 (14)5问题解答 (15)6全球播bug控制 (16)7全球播测试team和开发team半月赛评分规则 (17)bugzilla使用手册1简介1.1编写目的编写这一文档有助于实现以下目标：✧熟悉bugzilla的使用；✧Bug的提交流程；✧管理员如何进行管理；✧如何设置权限；1.2适用范围本文档的阅读对象是：项目负责人员、开发人员、测试负责人、测试人员。
1.3概述Buzilla作为一个产品缺陷的记录及跟踪工具，它能够为你建立一个完善的Bug跟踪体系，包括报告Bug、查询Bug记录并产生报表、处理解决、管理员系统初始化和设置四部分。
有如下几个特点：1、基于Web方式，安装简单、运行方便快捷、管理安全。
2、有利于缺陷的清楚传达。
本系统使用数据库进行管理，提供全面详尽的报告输入项，产生标准化的Bug报告。
提供大量的分析选项和强大的查询匹配能力，能根据各种条件组合进行Bug统计。
当错误在它的生命周期中变化时，开发人员、测试人员、及管理人员将及时获得动态的变化信息，允许你获取历史纪录，并在检查错误的状态时参考这一记录。
3、系统灵活，强大的可配置能力。
1）Buzilla工具可以对软件产品设定不同的模块，并针对不同的模块设定制定的开发人员和测试人员，这样可以实现提交报告时自动发给指定的责任人；2）可设定不同的小组，权限也可划分。
设定不同的用户对Bug记录的操作权限不同，可有效控制进行管理。
3）允许设定不同的严重程度和优先级可以在错误的生命其中管理错误，从最初的报告到最后的解决，确保了错误不会被忽略，同时可以使注意力集中在优先级和严重程度高的错误上。
4、自动发送Email，通知相关人员。
根据设定的不同责任人，自动发送最新的动态信息，有效的帮助测试人员和开发人员进行沟通。
Bugzilla是一个错误跟踪系统，用于对软件产品程序开发过程的错误跟踪。
它的强大功能表现在以下几个方面：1.强大的检索功能2.用户可配置的通过Email公布Bug变更3.历史变更记录4.通过跟踪和描述处理Bug5.附件管理6.完备的产品分类方案和细致的安全策略7.安全的审核机制8.强大的后端数据库支持9.Web，Xml，Email和控制界面10.友好的网络用户界面11.丰富多样的配置设定12.版本间向下兼容2操作指南---针对开发和测试人员2.1登录输入网址：http://10.0.0.60/bugzilla/，登录bugzilla页面。
由配置管理员统一建立账号和密码，账号为公司邮箱，初始密码：123456。
（为安全起见，用户登录后需及时更改密码）【login】登录系统成功登录后，点击【Preferences】->【Account Information】，进行密码修改。
点击【Preferences】->【Email Preferences】，进行邮件通知设置。
点击【Preferences】->【Permissions】，进行权限查询。
注意：在登陆使用之后，一定要退出登陆，这不仅是一个好不好习惯的问题，在bugzilla 中将成为一个隐患——当你没有退出登陆而关闭页面，当用同一台机器再次访问的时候，系统会以上次登陆的用户访问——小心你的权限被错误使用哦！2.2BUG处理过程（1）测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。
（通过assign to来分发）（2）项目组长根据具体情况，重新reassigned分配给bug所属的开发者。
（3）开发者收到Email信息后，判断是否为自己的修改范围.a.若不是,重新reassigned分配给项目组长或应该分配的开发者。
b.若是，进行处理，resolved+fixe并给出解决方法。
（4）测试人员查询开发者已修改的bug，进行重新测试。
a.经验证无误后，修改状态为VERIFIED+fixe。
b.还有问题，REOPENED，状态重新变为“REOPEN"，并发邮件通知。
（5）如果这个BUG一周内一直没被处理过。
Bugzilla就会一直用email骚扰它的属主，直到采取行动。
管理员可以设定最迟采取行动的期限，比如说3天，系统默认为7天。
2.3BUG提交过程2.3.1查询查询的目的◎确认要提交的bug报告不会在原有纪录中存在，若已经存在，不要提交，若有什么建议，可在原有纪录中增加注释，告知其属主。
◎确认你发现的Bug是否在最新的版本中所发生的。
2.3.2Bug的提交过程第一步：选择待提交bug的项目【New】选择自己要提交的项目，点击进入bug提交页面。
第二步：选择待提交的bug的产品第三步：录入bug【components】可以看到products下的各个模块。
【version】各个components的不同的版本。
（管理员在创建components时，增加不同的version 信息）【Platform&os】平台和操作系统：可根据bug的实际情况来选择，如果发生在每个平台系统，则选择all。
【Severity】严重级别：blocker到enhancement严重程度降低。
Blocker:阻碍了项目开发或者测试的继续进行。
Critical:冲突，数据丢失和严重的内存泄漏等问题。
Major:较大的功能缺陷。
Normal:一般问题Minor:较小的功能缺陷。
Trivial:拼写、对齐类的错误。
Enhancement:需要改进的。
【Priority】优先级：Highest至Lowest优先级逐渐减弱。
【Initial State】初始状态：unconfirmed状态开发人员默认状态：unconfirmed或confirmed测试人员默认状态：unconfirmed或confirmed【Assigned to】为空时默认为管理员指定的owner,也可手工制定。
注意：测试人员提交bug，这项默认填写测试管理员的邮箱；测试管理员根据问题的不同，将问题分发给开发组的负责人；开发组负责人根据bug的内容，将问题分派给开发组人员；【QA Contact】可以发送给QA人员。
【CC】抄送。
【Summary】问题概述：Bug标题描述方法：问题类型-功能/页面/页面栏目名-发现日期-问题概要描述问题类型定义：UI—页面显示UE—用户体验、易用性FC—功能问题PF—性能问题IF—接口问题CK—用户操作提示信息问题BF—程序打包问题AL—程序算法错误问题举例如下：FC-商城通告-090527-商城通告栏目内的内容不会自动滚动。
【Description】os:windows+ie6操作步骤：实际结果：期望结果：【Attachment】附件：添加bug的截图信息，使问题更有说服性。
注意：Access to bugs in the AccessA product是否选择是一个重点，如果只希望此组内的成员看到bug，则勾选此项；如果希望任何人都可以看到此bug，则不勾选此项。
确认无误点击“commit”提交问题2.4Bug查询登录系统后，点击Search，即可看到查询页面。
2.4.1Find a Specific Bug此页面属于模糊查询。
【status】状态：open closed all三个状态【products】项目：可以看到权限范围内所有的products和其下的components【words】输入和bug题目相关的文字，模糊查询即可差吵到bug2.4.2Advanced Search里面的内容很多，但是值得我们关注的主要有以下几点：在Classification、product、component、version选择要查询的内容其他可以不做选择，即默认。
注：1）classification下没有创建products，在classification列表，是不显示的。
2）product下没有创建components，在product列表是不显示的。
其他项可以不做选择，即默认。
注意：重点要理解status、resolution、severity、priority、hardware、os以下的内容都代表什么意思，这个要在下面做重点说明！点击search按钮，即可查询到待查询的信息。
Email addresses，bug numbers，and votes：具体说明。
2.5Bug处理处理bug之前，我们要明确bug的几种状态：Status：bug状态分类新提交的（Unconfirmed）已分配的（confirmed）问题未解决的（Unconfirmed、confirmed）待返测的（Resolved FIXED）待归档的（Verified）重新打开（Reopen）Resolution：bug处理意见Resolved FIXED---描述的问题已经修改Resolved INVALID---描述的问题不是一个bug(输入错误后，通过此项来取消)。
Resolved WONTFIX---描述的问题将永远不会被修复。
Resolved LATER---描述的问题将不会在产品的这个版本中解决。
Resolved DUPLICATE---描述的问题是一个存在的bug的复件。
Resolved WORKSFORME---所有要重新产生这个bug的企图是无效的。
如果有更多的信息出现，请重新分配这个bug，而现在只把它归档。
2.5.1测试or开发人员测试人员提交bug。
Bug状态为Unconfirmed的时候，在bug描述信息的最下方看到的状态如图2.5.1所示：1．为此bug不属于自己的范围，但知道谁应该负责，直接输入被指定人的Email，进行Ressigned。
2.操作：点击下图中的edit3．操作：输入新的被指定人的Email，点击“save changes”按钮即可，具体见下图。
