目录
一：在了解Bugzilla的使用前，先了解一些基本知识：
1.什么是Bugzilla
在一个产品研发或者软件开发的结束后，对一个产品进行测试后，会发现很多的bug，以前的bug的保留都是以手记，口传，或者文档记录。但是时常会出现bug的消失，bug的追溯和bug的追踪出现问题，所以为了更好的管理bug，记录bug和追踪bug，就出现了bugzilla这个bug管理系统。
简单介绍以下Bugziila，它就是一个Bug的管理系统，Bug的追踪系统，用来帮助你管理软件开发，建立完善的BUG跟踪体系。
2.bug的来源
在使用bugzilla前，我们需要弄懂，bug的来源，bug的生命周期以及在处理bug过程中的所有角色分为哪些。
bug的来源就是产品，和产品的组件。
3.bug的生命周期
bug的生命周期总的来说无非就是属于两个状态，一个是属于开启状态，一个是属于关闭状态的。
开启状态的bug分为三种：
1.unconfirmed:
2.confirmed：
3.in progress
关闭状态的bug分为两种：
1.resolved
2.verified
而resolved和verified下又分为7种处理意见：
fixed，invalid，wontfix，duplicate，worksforme，reopened，closed
1、Bug状态分类（status）
未确认(unconfirmed)
已确认(confirmed）
在处理中(inprogress)
待返测的(Resolved)
待归档的(Verified)
2、Bug处理意见（Resolution）
已修改的（Fixed）
不是问题（INVALID）
无法修改（Wontfix）
重复（Duplicate）
无法重现（Worksforme）
已关闭的(close)
问题未解决的(Reopened)
4.处理bug的所有角色：
1.reporter: filed the bug//报告者，一般为测试工程师进行产品的测试，负责填写bug，可对bug状态进行更改。
2.Assignee:in charge of resolving the bug//受理人:负责处理bug，可对bug的状态进行更改一般为产品的某个部分的工程师，比如软件工程师，硬件工程师。
3.QA contact:confirmed the bugs if it is unconfirm and verifying the fix one the bug has been resovled//判断是否bug是否已经解决
4.CC对象：抄写人：这个角色对bug不进行更改，但是每次bug的状态的更改都会以邮箱方式通知他。一般是领导或者整个项目的负责人，但是不负责解决bug。可以是任意在bugzilla中使用的用户。
5.每一次bug的状态更改，reporter和CC对象都会收到邮件消息。
5.一个bug的生命周期：
6.bugzilla使用时的基本流程图：
二：了解基本知识后，开始进入bugzilla的基本使用：
1.登录用户
在输入邮箱和密码栏中输入邮箱和密码即可登录
2.创建用户
创建用户，点击Open a New Account 进行新用户的创建，输入邮箱后，你的邮箱会收到一封创建用户的邮箱，点击地址会进入bugzilla进行编辑密码和账户信息
3.编写bug
填写bug的注意点：
1.最开始的status没有经过Assignee的确认一般填写是uncomfirm
2.一般默认的assingee是这个产品的component的负责人
3.CC对象是抄写人，这个角色对bug不进行更改，但是每次bug的状态的更改都会以邮箱方式通知他。一般是领导或者整个项目的负责人，但是不负责解决bug。
2.如何填写Severtity和Priority:
Severity（严重性）与Priority（优先级）之间的区别：
软件里的Bug所产生的效果不会自动的与修复它的优先级相关联。一个严重的Bug可能是那种对1%的用户来说也是不太会发生的使软件崩溃的bug。那它的优先级也比那些误操作导致的需要对每个用户每次需要重新键入一部分输入的Bug的优先级要低。
因此：需要分别跟踪Bug优先级和严重性，然后进行适当的修复。Bug的重要性是由项目来决定的，不同于客户对Bug的感知。某些情况下，分别跟踪急迫的或是按照客户观点定义的Bug也是很有意义的。
优先级与项目日程相关，严重性与标准相关。优先级表示需要优先考虑和注意的对象；由重要性顺序构建成优先级；严重性暗示需要严格遵照标准或者是高层原则，比如，一个严重的代码行为。优先级和严重性这2个词出现在Bug跟踪里。某种商业化的，问题跟踪及管理的软件工具是可行的。这些工具，随着测试工程师们逐条的输入，给予团队完整的信息，以致开发人员能明白Bug，明白Bug的严重性，重现它，并修复它。修复建立在优先级和严重性的基础上。严重性的问题按照客户的风险评估来定义，并记录于被选择的跟踪工具中。多Bug的软件会“严重”影响项目进度，依次也能导致对“优先级”重新评估和商榷。
Severity: 一个bug对功能的影响程度
Priority: 一个bug对业务的影响程度
BUG严重级别解释规范
目的：测试工程师在提交Bug时，为选择Bug的严重级别的依据。
测试工程师在提交Bug时，需要选择该Bug的严重程度，不同的选项代表不同的严重程度，解释如下：
Blocker
该Bug不仅造成本产品/项目异常，并且导致其他服务器、数据库、中间件、程序、操作系统等不能提供正常服务（包括客户端）。
Critical
该Bug影响两个或两个模块以上的功能无法应用或者用例无法执行（不包括显示文字以及装饰内容。例如：一级菜单按钮文字，版权消息内容等）；
Major
需求规格说明书中已描述，但是功能未实现，或实现功能与产品需求规格书不符。
Minor
所实现功能，在需求规格说明书中没有定义，所实现功能如果存在缺陷将提出Bug，如果实现功能比较完美，不再提Bug。
Trivial
装饰性问题，主要是界面方面问题，如错别字、画面误显示、页面显示变形或误动作，提示信息有误。
Enhancement
产品易用性、美观性问题，属于用户体验，进行合理化建议。
注：1：报Major 与Minor类Bug的前提为，是否为功能性问题；（提示消息是否准确、有效不在此范围内）
2：提示信息类Bug报在Trivial中。注：如果需求文档中，对该提示信息有明确的样本，但程序实现与样本有差异，此类bug也属于Trivial类bug。
BUG优先级别解释规范
目的：测试工程师在提交Bug时，为选择Bug的优先级的依据。
测试工程师在提交Bug时，需要选择该Bug的优先级，不同的选项代表不同的优先程度，解释如下：
Highest为 最优先修改的Bug。
注：此优先级别的Bug，如果不进行修改会影响到系统主要功能的测试，优先级别最高。
High为较 为优先修改的Bug。
注：此优先级别的Bug，如果不进行修改，会影响到相关此组件其他功能的测试，优先级别较高。
Normal为 一般优先修改的Bug。
注：此优先级别的Bug，如果不进行修改，说明该功能没有实现或实现有错误，优先级别一般。
Low为 次优先修改的Bug。
注：此优先级别的Bug，如果不进行修改，不影响主要功能，属于页面美观和易用性的问题。
Lowest为 最不优先修改的Bug。
注：此优先级别的Bug，不影响主要功能，只是页面上的文字错误或者需要改进的建议5
三：测试demo，对测试流程进行一个使用举例：
完成bug的编写后界面如下：
完成一个bug的编辑后，Assignee对象会收到一封邮箱
完成一个bug的编写后，CC对象会收到一个邮件，内容如下
在Assignee对象的Bugzilla账号中的My Bugs 中的显示是
Assignee查看bug后改bug状态为IN_PROGRESS后reporter会收到一封邮箱
在对bug修改完后，进行bug解决后的描述和状态和处理意见的编辑
在Assignee对bug进行fixed后，reported会收到一封邮箱通知，收到通知后在search中寻找对应bug，再次对bug进行测试，如果测试发现bug已经解决则更改状态为verified，处理意见为closed。
到此一个bug的生命结束。
四：角色的权限设置：
每一个用户的权限是可以被管理员进行授予,下图是所有可以被授予的权限。
管理员没有授予用户权限时的Administrator界面如下：
管理员在User中指定用户后进行设置权限如下：
管理员授予用户指定的权限后的Administrator界面如下：
779
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
