Bugzilla详细使用手册.docVIP

软件版本 bugzilla-2[1].22.1.tar.gz； 作者：GeneralXU Bugzilla 操作说明 1．用户登录及设置 1.1用户登录 1． 用户输入服务器地址/bug/index.cgi;(以公司公布的地址为准)； 2． 进入主页面后，输入【账号】和【密码】登录系统；这里的账号是邮件地址； 3．登录后自动进入查询页面； 4． 如忘记密码，可以找系统管理员解决； 备注：由于本系统的邮件系统的发送方式主要是针对UNIX系统的，在Windows下使用 ，目前还没有好的解决办法，所以系统中将不再使用邮件系统。 1.2、修改密码及设置 ?? 登录后，进入【个人设置】可以对以下项目进行设置： 1．【账号设置】进行密码修改； 2．【一般设置】进行BUG显示属性项的设置； 3．【Email设置】这里由于没有使用Email，所以可以不用设置； 4．【已存查询】这里进行查询条件的编辑与设定； 4．【权限】这里可以查询自己拥有的权限，并对特定的子权限进行设置； ? 2．Bug 的处理过程 ?2.1报告Bug 2.1.1测试人员报告Bug 　1． 请先进行查询，确认要提交的bug报告不会在原有纪录中存在，若已经存在，不要提交，若有什么建议，可在原有纪录中增加注释，告知其属主，让bug的属主看到这个而自己去修改； 2． 若Bug不存在，创建一份有效的bug报告后进行提交； 3． 操作：点击【新建】，选择产品后，填写下表； 4． 填表注意：【分配给】: 为空则默认为设定的责任人, 也可手工制定。抄送: 可为多人，需用，隔开。“描述”中要详细说明下列情况： 　　1） 发现问题的步骤； 　　2） 执行上述步骤后出现的情况； 　　3） 期望应出现的正确结果； 　　选择“组”设置限定此bug对“组”的权限，若为空，则为公开； 5. 操作结果：Bug状态（status）可以选择Initial state 为New或Unconfirmed（没有确认）； 2.1.2 开发人员报告Bug 1. 具体方法同测试人员报告； 2. 区别： Bug初始状态将自动设为Unconfirmed(未确认)，待测试人员确定后变为“New（新建）； 2.2、Bug的不同处理情况 2.2.1 Bug的属主 (owner) 处理问题后，提出解决意见及方法。 1. 给出解决方法并填写Additional Comments(增加评论)，还可创建附件； 2. 具体操作（填表项如下） 3. 填表注意： 已修复（FIXED）：FIXED 描述的问题已经修改； 无效(INVALID)：描述的问题不是一个bug (输入错误后，通过此项来取消)； 决定不改(WONTFIX)：描述的问题将永远不会被修复； 稍后修改(LATER): 描述的问题将不会在产品的这个版本中解决； BUG复件(DUPLICATE): 描述的问题是一个存在的bug的复件； 另外还有提醒、无法重现的标示； 2.2.2 项目组长或开发者重新指定Bug的属主。（owner） 1． 为此bug不属于自己的范围，可置为 Assigned(分配),等待测试人员重新指定； 2． 为此bug不属于自己的范围，但知道谁应该负责，直接输入被指定人的Email， 进行Ressigned(分配)。 3. 操作：（可选项如下）； 　　接受BUG（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. 重打开(Bug Reopen bug）; 3. 将Bug状态改为已验证(Mark bug as VERIFIED）; 4. 将Bug状态改为关闭 (Mark bug as CLOSED）; 2.2.4 Bug报告者（reporter）或其他有权限的用户修改及补充Bug 1. 可以修改Bug的各项内容。 2.