Bugzilla介绍
?绪言
什么是Bugzilla
Bugzilla是一个错误跟踪系统，用于对软件产品程序开发过程的错误跟踪。它的强大功能表现在以下几个方面：
1.强大的检索功能
2.用户可配置的通过Email公布Bug变更
3.历史变更记录
4.通过跟踪和描述处理Bug
5.附件管理
6.完备的产品分类方案和细致的安全策略
7.安全的审核机制
8.强大的后端数据库支持
9.Web，Xml，Email和控制界面
10.友好的网络用户界面
11.丰富多样的配置设定
12.版本间向下兼容
为什么使用BugzillaBugzilla是一个拥有强大功能的错误跟踪系统。它可以使我们更好的在软件开发过程中跟踪软件错误的处理过程，为开发和测试工作以及产品质量的度量提供数据支持，从而有效的保证软件产品的质量。
?
Bugzilla使用指南新建一个Bugzilla账号1.? 点击“Open a new Bugzilla account”链接，输入你的Email地址（如：XXX@office）然后点击“Create Account”。
2.? 稍候，你会收到一封邮件。邮件中包含你的登录账号（与你的Email相同）和口令，这个口令时Bugzilla系统随机生成的，你可以根据你的需要进行变更。
3.在页面的黄色页角中点击“Log In”链接，而后输入你的账号和口令。最后点击“Login”
产品和结构（Product and Component）Bug记录按产品分类，每种产品按功能拆分成几类。以Bugzilla产品为例，它由以下几部分构成：
??? Administration
??? Bugzilla-General
??? Creating/Changing Bug
??? Documentation
??? Email
??? Installation
??? Query/Buglist
??? Reporting/Charting
??? User Accounts
??? Changing Passwords
??? User Interface
Bug报告状态分类和Bug处理意见（Status and Resolution）：1.? Bug报告状态分类（Status）
??? 待确认的（Unconfirmed）
??? 新提交的（New）
??? 已分配的（Assigned）
??? 问题未解决的（Reopened）
??? 待返测的（Resolved）
??? 待归档的（Verified）
??? 已归档的（Closed）
2.? Bug处理意见（Resolution）
??? 已修改的（Fixed）
??? 不是问题（Nvalid）
??? 无法修改（Wontfix）
??? 以后版本解决（Later）
??? 保留（Remind）
??? 重复（Duplicate）
??? 无法重现（Worksforme）
指定处理人（Assigned To）??? 可以指定一个处理人
??? 如不指定处理人，则系统指定管理员为默认处理人
超链接（URL）??? 输入超链接地址，引导处理人找到与报告相关联的信息
概述（Summary）??? 概述部分“Summary”的描述，应保证处理人在阅读时能够清楚提交者在进行什么操作的时候发现了什么问题。
??? 如果是通用组件部分的测试，则必须将这一通用组件对应的功能名称写入概述中，以便今后查询。
硬件平台和操作系统（Platform and OS）??? 测试应用的硬件平台（Platform），通常选择“PC”
??? 测试应用的操作系统平台（OS）
版本（Version）??? 产生Bug的软件版本
Bug报告优先级（Priority）??? 分五个等级即P1-P5，P1的优先级别最高之后逐级递减
Bug状态（Severity）??? Blocker，阻碍开发和/或测试工作
??? Critical，死机，丢失数据，内存溢出
??? Major，较大的功能缺陷
??? Normal，普通的功能缺陷
??? Minor，较轻的功能缺陷
??? Trivial，产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等等
??? Enhancement，建议或意见
报告人（Reporter）??? Bug报告提交者的账号
邮件抄送列表（CC List）??? Bug报告抄送对象，该项可以不填
??? 如需要抄送多人，可将邮件地址用“，”分隔
从属关系（Bug “ID” depends on，Bug “ID” blocks）??? “Bug “ID” depends on”如果该Bug必须在其他Bug修改以后才能够修改，则在此项目后填写那个Bug的编号
??? “Bug “ID” blocks”如果该Bug的存在影响了其他Bug的修改，则在此项目后填写被影响的Bug编号
附加描述（Additional Comments）??? 在Bug跟踪过程中测试与开发人员通过这里进行沟通
??? 开发人员可以在这里填写处理意见和处理记录
??? 测试人员可以在这里填写返测意见和对在返测过程中发现的新问题进行描述
Bug查找??? 可以通过页脚中的“Query”链接进入查找界面
??? 根据查找的需要在界面中选择对象或输入关键字
??? 查找功能能够进行字符或字串的匹配查找
??? 查找功能具有布尔逻辑检索功能
??? 你可以通过在查找页面中选择“Remember this as my default query”将当前检索页面中设定的项目保存。以后可以从页脚中的My bugs中直接调用这个项目进行检索
??? 你还可以通过在“Remember this query, and name it:”后面输入字符，将你当前检索页面中设定的项目保存命名，同时选中“and put it in my page footer”。则以后这个被命名的检索将出现在页脚中。（有关如何在页脚中设定显示的项目请参见1.5.3）
Bug列表??? 如果你运行了Bug检索功能，系统会根据你的需要列出相关的项目
??? 你可以通过列表页脚附近的“Change Columns”设定在列表中显示的Bug记录中的字段名称
??? 如果你拥有必要的权限，你还可以通过“Change several bugs”修改列表中罗列出的Bug的记录。例如：修改Bug的所有者
??? 通过“Send mail to bug owners”你可以给列表中罗列的Bug记录的所有者发信
??? 如果你对查找的结果不满意，希望重新调整检索设定。你可以通过“Edit this query”实现
??? 通常情况下，检索结果中只显示最基本的信息。你可以通过“Long Format”显示更详细的内容
用户属性设置（Edit prefs）1账号设置（Account Settings）
??? 在这里你可以改变你账号的基本信息，如口令，Email地址，真实姓名
??? 为了安全起见，在此页进行任何更改之前你都必须输入你当前的口令
??? 当你变更了你的Email地址，系统会给你的新老Email地址分别发一封确认邮件，你必须到邮件中指定的地址对你的更改进行确认
2Email设置（Email Settings）
??? 你可以在此通过选择告诉系统，你希望在什么条件下收到和你相关的邮件
3页脚（Page Footer）
??? 设定“Preset Queries”是否在页脚中显示
4用户权限（Permissions）
你可以在此查看自己账号现在的权限
?
?
?
1. 描 述
bugzilla是一个叫mozilla组织开发的缺陷跟踪系统，一般来说可能使用到的bugzilla的人有软件设计人员，开发人员，测试人员以及将来的维护人员等等。通过bugzilla，软件开发人员、测试人员、维护人员等等，就可以对软件的缺陷、有关软件的一些建议等等进行跟踪、记录和交流。对于测试人员来讲，bugzilla更是不可缺少的工具。
具体来说，bugzilla就是一个报告BUG和把BUG指派给合适开发人员的一个系统，这里所指的BUG可以是对于提高软件质量的一些建议等。一般来说，bugzilla的前台基于WEB页的形式，后台采用基于UNIX或LINUX的MYSQL数据库来存储、处理这些BUG。
2. 使 用
2.1 开设账户
?目前bugzilla服务器IP地址是http://192.168.0.254:8080/ 在使用Bugzilla前，必须在bugzilla系统中拥有你自己的账户，如果没有，可以开设。一般来说，如果连接到bugzilla的开始页面，会有一个[Open a new bugzilla Account]的标签，或在其它的页面，在左下角会有一个[New? Account]标签，点击它，可以进行账户的开设，按它的指示填写好内容之后，系统会发一封电子邮件到你的邮箱里去，从邮件中你可以获得你登录bugzilla的密码。登录之后，通过点击[Edit Prefs]进行密码更改和个人资料的设置。设置好账户之后，你就可以在bugzilla报告和查询BUG了。
2.2 报告BUG
2.2.1 BUG内容的填写
登录后，进入查询页面，在页面的左下角会有一个[New]标签，点击它，连接到新建BUG的页面，选择一个产品进入Enter BUG页面，选择版本，组件等。目前在component栏里包括以下几部分：account（出账），billing（计费），card-广通（广通卡业务），营业受理，settlement（结算），采集，计费预处理，库表设计等。
选择软件运行的硬件平台，操作系统，优先级别和严重性等。对于优先级和严重性，可能测试人员和开发人员的看法可能不一样，测试人员认为是比较严重的BUG，而开发人员可能不那么认为，其基本标准请参考本文后面部分所描述的即可。
对于指派（Assigned To）的人，一般是这个模块的开发人员。bug的状态转变为新的(NEW)，并分配到该开发人员的bug列表中。进行默认查询时，状态设置为新(NEW)，已分配(ASSIGNED)和重开(REOPENED)。当需要查找已经解决或验证的bug时，需要正确地对状态设置。对于抄送(CC)的人,一般为程序模块的负责人，或者测试组的负责人等。然后填写好BUG的内容，即可提交（commit）,对于BUG的SUMMARY一般应尽量短，同时最能描述出所出现的问题。
当BUG提交后，系统会根据你填写的内容及个人的资料配置自动发送邮件给与此BUG相关的人员。如果提交的BUG在一定的时间内没有被关注，对于它的状态字没有被修改，那么根据系统的配置，系统将发出邮件，提醒与BUG相关的人员，促使他们早日对BUG进行处理。
2.2.2 对BUG的一些描述字段
2.2.1.1? STATUS：（状态）
状态字段表明了bug的一般的状态，只有某些特定的状态转换是允许的，状态之间是可以转换的。
UNCONFIRMED：（未证实）
表明bug是最近加入到数据库，没有人正式这个bug的存在。拥有“确定/取消Bug"的用户可以对转变bug的状态为：
1. 确认这个bug，改变他的状态为新(NEW)
2. 解决这个bug，标志为已解决(RESOLVED)
NEW（新BUG）
这个bug已经分发给某位开发人员处理。这个状态的bug可以转变为以下状态： 1. 接受该bug，状态转变为指派(ASSIGNED)
2. 指派给别的开发人员，状态维持为新(NEW)
被解决，状态转变为被解决(RESOLVED)
ASSIGNED（已经指派）
这个bug尚未解决，但已经被指派给正确的人进行解决。这个状态的bug可能转换为以下状态:
1. 指派给别的开发人员，状态转变为新(NEW)
2. 被解决，状态转变为被解决(RESOLVED)
?REOPENED（重新打开）
这个bug曾经被解决了，但是解决方案是不正确的。例如，一个处于对我有效（WORKSFORME）的bug，当获得了更多的信息并且能够被再现时，将转变为重开(REOPENED)状态。 这个状态的bug只能转换为以下状态：
1. 指派(ASSIGNED)给某名开发人员
2. 被解决，状态转变为被解决(RESOLVED)
?RESOLVED（已经解决）
已经确定了一种解决方案，这种方案正在等待QA的确认。此状态的bug可转化为以下状态:
1. 重新开放，转变为重开放(REOPENED)
2. QA确认后，转变为已验证(VERIFIED)
3. QA确认后，转变为关闭(CLOSE)
?VERIFIED（已经证实）
QA已经确认对于这个bug的解决方案是成功的。处于这种状态的bug当他们所存在的产品正式发布之后，状态将转变为关闭(CLOSE)
CLOSED（已经关闭）
bug处于这种状态可视为已死亡，其解决方案是正确的。出于这种状态的bug要重新得到处理，只能通过转变他的状态为重开(REOPEN)。
2.2.1.2? Resolution：（解决方案）
??? 解决方案字段表明对bug是如何处理的。
?FIXED（已经修复）
? 对这个bug的源代码做了修改，放入代码库并且经过了测试。
?INVALID（无效）
?BUG确认人员认为所描述的问题不是一个BUG，因此也不会被修复。
?WONTFIX（不做修改）
所描述的问题是一个bug，但由于某种原因不会进行修改。
?LATER（以后修复）
所描述的问题是一个bug，但当前版本不会修改这个bug。
?REMIND（延时提醒）
所描述的问题是一个bug，但尚未确定是否在当前版本进行修改。
?DUPLICATE（重复）
所描述的问题是一个已存在bug。必须使用一个已存在的bug id对该bug进行标志。
?WORKSFORME（不可重现）
无法根据描述对bug进行重现，阅读代码也无法解释所描述的问题。如果以后能够提供更多的细节，再做处理，现在暂时存档。
2.2.1.3? Severity：（严重性）
用于描述BUG的严重级别。
?BLOCKER（阻碍进度）：阻碍开发或测试的进行。
?CRITICAL（严重）：崩溃，丢失数据，严重内存泄漏等等。
?MAJOR（较大的BUG）：缺少主要的功能，或功能不能完成。
? NOMAL（普通的BUG）：缺少一些普通的功能，或者一些用户不会轻易察觉的问题。
? MINOR（次要的BUG）：缺少次要的功能，或者一些能够轻易解决的问题。
? TRIVIAL（轻微的BUG）：很细小的问题如拼写错误，排版错误等。
?ENHANCEMENT（增强）：一般对于增强软件质量或功能的一些建议。
?2.2.1.4? Priority：（优先级）
?P1 最重要
?P2
?P3
?P4
?P5 最不重要
其它还在几个字段为软件运行的硬件环境、操作系统等等。
2.3 查询BUG
在登录后，在页面底部会有[My Bugs]的标签，点击后显示与你有关的BUG。如果要查询指定ID的BUG可以在页面底部的[BUG＃]文本框里输入BUG ID号，点击[find]按纽，可以查找指定的BUG，，对于一个BUG，你可以增加对BUG内容的描述，改变它的状态字等等。
对于比较复杂的查询，点击页面底部的[Query]标签即可进行不同条件组合的BUG查询。其中大部分的条件就是我前面已经所说的那些BUG描述字段。查询页中给出了Email地址输入栏，可以为指派人， 报告BUG的人，抄送的人等等的邮箱地址。
2.3 如何书写优质的BUG报告
http://www.mozilla.org/bugs/
http://www.mozilla.org/quality/bug-writing-guidelines.html
?
?
?
?
?
?
?
一、bugzilla管理员（特殊功能点）
1、增加用户
1.1、 查找出附合条件的所有用户或全部用户
???????????? 点击底下用户选项，分四种情况查出相应用户：
1、 不填用户名直接提交时，可以查出全部。
2、 填用户名，不区分大小写的查出相应用户。
3、 填用户名，区分大小写的查出相应用户。
4、 填用户名，查出此用户名以外的相应用户。
1.2、 添加用户、把用户置为不可用
对上面查出的内容，点击增加一个新用户，输入相关资料，注意停用文本中不要填入内容。确定就可。
把用户置为停用，查出该用户，把停用文本框里填入一些内容，提交就可。
1.3、 修改用户权限
查出用户，点击进入该用户，在相应复选框前打上或去除选择标记，updata就可。
Canconfirm:Can confirm a bug.
确认一个bug，改状态用的，一般所有参与人都要有这个权限。
Creategroups:Can create and destroy groups.
新建用户组用的。
Editbugs:Can edit all aspects of any bug.
可以新建、改状态，以及所有对bug的操作。
Editcomponents:Can create,destroy,and edit components.
增加、修改、删除产品和部件功能。
Editkeywords:Can create,destroy,and edit keywords.
增加、修改、删除关键字操作。
Edit tusers:Can edit or disable users.
能编辑或停用其它用户。
Tweakparams:Can tweak operating parameters.
能修改操作参数的操作。
2、增加产品（项目）
? 2.1、增加产品
????? 点击底下的产品链接，可以修改、删除、增加一个产品。
????? Closed for bug entry:?
?选中表示不能再向该产品提交bug了，但现有bug还是可以查看、编辑。
Maximum votes per person:
这个产品接受每个人的最大投票数。不为0时才有投票功能。
Maximum votes a person can put on a single bug:
在一个bug单上一个用户能投票的最大数目。
Number of votes a bug in this product needs to automatically get out of the UNCONFIRMEO state:
? 2.2、增加部件
????? 增加部件的地方有两个，一个是产品里，一个是在增加一个产品的bug时，该产品没有部件的情况下，会提示你增加部件。而删除和修改部件是地方只有在产品里。
????? Initial owner里必须指定一个用户方可
? 2.3、增加版本
?????? 增加、修改、删除产品的版本在产品链接里实现。
? 2.4、增加产品附件
?????? 产品附件：指对某个整个的产品增加一个附件，可以在里面放一些说明。
?????? 在底部的附件链接里实现。产品附件可以增加、编辑、删除。
???????? 2.5、增加某bug的附件
???????????? 打开需要加附件的bug，点击建立新的附件的链接，按要求填写可以增加bug的附件。查看附件只要点击相应附件就可。
bug 的附件只可以添加和编辑，不可以删除。附件上还可以增加评述。
3、设置参数
? 3.1.1、设置整体参数
??? ◎主要参数（parameters）的设置
1） urlbase: 输入bugzilla 工具所在的服务器IP地址。
2） whinedays：Bug在whinedays设定的期限内若未被处理，将自动重发mail，默认????? 为 7天。
3） defaultpriority:设定默认的优先级
4） commentonresolve：设为ON，系统将强制要求开发者处理完Bug 后，必须填写修改的内容。
说明：若是要更改某一项的设置，不要勾选该项前面的reset选框，这样会使其恢复默认设置的。
4、设置用户组
????? 组是针对项目而设的，当一个用户属于某个项目组时，这时才有提交的该项目链接，可以给其添加bug。但它好像并没有把一些权限封装在组里，也许这里理解有误。
5、设置关键字
?? 关键字的作用是给某个bug加入这个关键字就可以按关键字快速查找到该bug。这里的关键字的设置是对整个系统而言的，并非某个产品。
?? 关键字可以添加、修改、删除，在底部的关键字的链接里实现。
?? 使用时打开某个bug在里面的关键字处填写系统已经定义过的关键字，就可在查询里面按关键字查询出来。
二、一般用户
1、 bug的提交
点击【新建】—〉选择发现的bug所在的产品名称。
在选择的产品bug提交页面中，选择或者输入bug信息。
◎模块：点“模块”两个字，可以查看关于这个产品的模块的详细信息。
◎平台、操作系统：可以根据发现bug的实际情况来选择，如果确定这个bug可以发生在所有的平台，选择all好了！
◎优先级：P1至P5优先级逐渐减弱。
◎严重级：blocker到enhancement严重程度降低。
? Blocker:阻碍了项目开发或者测试的继续进行。
? Critical:冲突，数据丢失和严重的内存泄漏等问题。
? Major:较大的功能缺陷。
? Minor:较小的功能缺陷。
? Trivial:拼写、对齐类的错误。
? Enhancement:需要改进的。
◎初始状态：开发人员的默认状态为“unconfirmed”(这个要由管理员设置，参见管理员操作指南)，测试人员或者管理员此处为可选状态：unconfirmed和new.
◎Assigned to: 为空时默认为管理员指定的 owner, 也可手工制定。
◎CC: 可为多人，需用"，"隔开。
◎URL: bug的定位（可选）。
◎注释：是对bug的概述（必须填写）。
◎Desription中要详细说明下列情况：
1） 发现问题的步骤
2） 执行上述步骤后出现的情况
3） 期望应出现的正确结果
◎关键字：单击“关键字”三个字，会显示管理员已经设定的关键字，选择其一，便于以查询。注意：此处不可以随意添加，必须使用已经存在的关键字才好。另外，如果管理员没有创建关键字的话，那么此项缺省。
◎依赖：直接输入与当前bug有依赖关系的bug的编号。简单地说，比如说这里输入“3”，那么就是说当前提交的bug有依赖关系，不是由于3导致了当前bug，就是当前bug导致了bug3。
确认无误后，“commit”!
提交之后，系统会提示：bug 已经提交。在此页面的下半部分，会再次显示刚才提交的bug的详细信息，你可以在这里进行修改，重新commit,也可以在此增加新的附件或是附加说明来进一步说明bug。
2、 bug的投票
◎投票：可以查看票数,只要点击【显示这个bug的票数】，也可以参加投票，【为这个bug投票】—〉在“票数”一栏中直接输入票数—〉【change my votes】.
需要说明的是：票数并不是任意的，管理员为每一个用户设置了可以投票的最大数目和每个用户为某个bug投票的最大数目。
建议：一次只投一票，多投也没什么意义。主要是用来看用户对该bug的关注程度。
3、 对于Bug的不同处理情况
3.1 Bug的属主 (owner) 处理问题，提出解决意见及方法。
给出解决方法并填写附加说明（Additional Comments），还可创建附件（如：更改提交单）。
填表提示：
FIXED 描述的问题已经修改，该bug已经修复并检查过，源文件已经检入CVS库。
INVALID 描述的问题不是一个bug (输入错误后，通过此项来取消)
WONTFIX 描述的问题将永远不会被修复。
LATER 描述的问题将不会在产品的这个版本中解决。
DUPLICATE 描述的问题是一个存在的bug的复件。
WORKSFORME 所有要重新产生这个bug的企图是无效的。如果有更多的信息出现，请重新分配这个bug，而现在只把它归档。
3.2 项目组长或开发者重新指定Bug的属主。
①bug不属于自己的范围，可置为 Assigned ,等待测试人员重新指定。
②bug不属于自己的范围，但知道谁应该负责，在Reassign bug to的输入框中直接输入被指定人的Email。
③操作结果：此时bug状态又变为New，此bug的owner变为被指定的人。
3.3 测试人员确认开发人员报告的Bug是否存在.
查询状态为“Unconfirmed"的Bug,
测试人员对开发人员提交的Bug进行确认，确认Bug存在。
具体操作：选中“Confirm bug(change status to New)"后，进行commit.
操作结果：状态变为“New".
3.4 测试人员验证已修改的 Bug
① 测试人员查询开发者已修改的bug，即Status为"Resolved", Resolution为"Fixed".进行重新测试。（可创建test case附件）
② 经验证无误后，修改Resolution为VERIFIED。待整个产品发布后，修改为CLOSED。
若测试之后发现还有问题，REOPENED，状态重新变为“New"，并发邮件通知。
4、 冲突
当两个或几个人同时修改一个bug提交信息的时候，bugzilla会有弹出 Mid- air collision!提示，并且列出解决冲突的选择：◎提交修改，但是会导致覆盖别人所做的修改。
◎不改了，返回。
建议选择返回，看看别人修改了什么，不同的话，添加一个附加说明来补充吧！！
以上各项可能会因为权限的关系，有所缺省。
5、 关于权限的说明
◎组内成员对bug具有查询的权利,但不能进行修改。
◎ Bug的owner 和 reporter 具有修改的权利。
◎ 具有特殊权限的用户具有修改的权利。
6、 bug的报告
所有人员都可以按项目也可以所有的查看目前bug数量，所属人员，以及bug状态，从而可以找出项目的修改情况。
?
?
?
?
?
?
?
?
Bugzilla是一个bug追踪系统，用以管理bug提交、bug消除，不仅能降低同样错误的重复发生，提高开效率，而且有助于项目管理的难度
Bugzilla操作说明
1.用户登录及设置
1.1用户登录
1． 用户输入服务器地址http://192.168.1.6/bugzilla/。
<http://192.168.1.6/bugzilla/%E3%80%82>
2． 进入主页面后，点击'Forget the currently stored login'，再点击'login in'进入。
3． 进入注册页面，输入用户名和密码即可登录。用户名为Email 地址，初始密码为用户名缩写。
4． 如忘记密码，输入用户名,点击'submit request',根据收到的邮件进行
重新设置。
1.2、修改密码及设置
1．Login登录后，'Edit prefs'->'accout settings' 进行密码修改。
2．'Edit prefs'->'email settings' 进行邮件设置。
3．'Edit prefs'-> 'permissions' 进行权限查询
2、Bug的处理过程
2.1、报告Bug
2.1.1测试人员报告Bug
1．请先进行查询，确认要提交的bug报告不会在原有纪录中存在，若已经存
在，不要提交，若有什么建议，可在原有纪录中增加注释，告知其属主，让bug的
属主看到这个而自己去修改。
2． 若Bug不存在，创建一份有效的bug报告后进行提交。
3． 操作：点击New，选择产品后，填写下表。
4． 填表注意：Assigned to: 为空则默认为设定的 owner, 也可手工制定。
CC: 可为多人，需用"，"隔开。Desription中要详细说明下列情况：
1） 发现问题的步骤
2） 执行上述步骤后出现的情况。
3） 期望应出现的正确结果。
选择group设置限定此bug对组的权限，若为空，则为公开。
5. 操作结果：Bug状态（status）可以选择Initial state 为New或Unconfirmed.
系统将自动通过Email通知项目组长或直接通知开发者。
6．帮助： Bug writing guidelines
2.1.2 开发人员报告Bug.
1. 具体方法同测试人员报告。
2. 区别： Bug初始状态将自动设为Unconfirmed，待测试人员确定后变为“New".
2.2、Bug的不同处理情况
2.2.1 Bug的属主 (owner) 处理问题后，提出解决意见及方法。
1 . 给出解决方法并填写Additional Comments，还可创建附件（如：更改提
交单）
2．具体操作（填表项如下）
3 . 填表注意：
FIXED 描述的问题已经修改
INVALID 描述的问题不是一个bug (输入错误后，通过此项来取消)
WONTFIX 描述的问题将永远不会被修复。
LATER 描述的问题将不会在产品的这个版本中解决.
DUPLICATE 描述的问题是一个存在的bug的复件。
WORKSFORME 所有要重新产生这个bug的企图是无效的。如果有更多的信息出
现，请重新分配这个bug，而现在只把它归档。
2.2.2 项目组长或开发者重新指定Bug的属主。（owner）
1． 为此bug不属于自己的范围，可置为 Assigned,等待测试人员重新指定。
2．为此bug不属于自己的范围，但知道谁应该负责，直接输入被指定人的
Email， 进行Ressigned。
3. 操作：（可选项如下）
* Accept bug (change status to ASSIGNED)
* Reassign bug to
* Reassign bug to owner and QA contact of selected component
4．操作结果：此时bug状态又变为New，此bug的owner变为被指定的人。
2.2.3测试人员验证已修改的 Bug.
1．测试人员查询开发者已修改的bug，即Status为"Resolved",Resolution为
"Fixed".进行重新测试。（可创建test case附件）
2．经验证无误后，修改Resolution为VERIFIED。待整个产品发布后，修改为
CLOSED。
若还有问题，REOPENED，状态重新变为“New"，并发邮件通知。
3． 具体操作（可选择项）
1. Leave as RESOLVED FIXED
2. Reopen bug
3. Mark bug as VERIFIED
4. Mark bug as CLOSED
2.2.4 Bug报告者（reporter）或其他有权限的用户修改及补充Bug
1. 可以修改Bug的各项内容。
2. 可以增加建立附件，增加了相关性, 并加一些评论来解释你正在做些什么
和你为什么做。
3．操作结果：每当一些人修改了bug报告或加了一个评论，他们将会被加到CC
列表中，bug报告中的改变会显在要发给属主、写报告者和CC列表中的人的电子邮
件中。
2.2.5测试人员确认开发人员报告的Bug是否存在.
1. 查询状态为“Unconfirmed"的Bug,
2. 测试人员对开发人员提交的Bug进行确认，确认Bug存在。
3. 具体操作：选中“Confirm bug(change status to New)"后，进行commit.
4. 操作结果：状态变为“New".
2.3、查询Bug
1．直接输入Bug Id，点击find 查询。可以查看Bug的活动纪录。
2．点击Query，输入条件进行查询。
3．查询Bug活动的历史
4．产生报表。
5．帮助：点击Clue.
3、关于权限的说明
1． 组内成员对bug具有查询的权利,但不能进行修改。
2． Bug的owner 和 reporter 具有修改的权利。
3． 具有特殊权限的用户具有修改的权利。
4、 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骚扰它的
属主，直到采取行动。
5、一个Bug的生存周期
Bugzilla管理员操作指南
1、主要工作内容：
1． 1产品（Product）、版本号(versions)和模块(Components)的定义，同时指定
模块相应的开发者(owner)和测试人员(QA Contact)。
1．2小组的定义和划分
1．3测试中Bug严重程度、优先级的定义
1． 4增加用户，并分别设定全部用户的分组、权限。
1． 5主要参数（parameters）的设置
1） urlbase: 输入bugzilla 工具所在的服务器IP地址。
2） usebuggroupsentry: 设为ON,可以分组。
3） whinedays：Bug在whinedays设定的期限内若未被处理，将自动重发
mail，默认为7天。
4） defaultpriority:设定默认的优先级
5） commentonresolve：设为ON，系统将强制要求开发者处理完Bug 后，必须
填写修改的内容。
2、基本操作：
2．1创建默认的管理员用户。
运行checksetup.pl。若不小心删除管理员，重新运行checksetup.pl.
2．2 管理用户
2．3增加新用户
点击页面右下角【users】,submit后，出现【Add new user】页面。输入相应
输入即可。Login name: 一般为邮件地址，可以设为其他标识。
2．4 禁止一个用户
填写Disabled text 输入框即可。
2．5 修改用户
可以修改用户注册名、密码。
设置权限
QA的权限一般设为: Canconfirm, editbugs
Developer的权限设为: none
分组控制：group
3、管理group
3.1．增加group
edit groupàadd groups (New User Regexp可不填/active 选择则可选)->add
3.2修改group ,submit 即可。
4、管理Product 和 component
a)增加Product
b) Component 对应一个owner(进行fixed),QA Contact（确保已fixed）
c) Component Number of Unconfirmed =10000,此产品将选择bug的初始状态
（Unconfirmed,New）
