Bugzilla平台对于BUG的处理流程

引言：

应公司要求正在负责搭建Bugzilla软件平台，目前平台已经搭建完成，下面给没有使用过，或者想了解的小伙伴们介绍一下最新版本的Bugzilla平台中BUG的提交方式和处理流程。

*此阶段已经创建好了对应公司的product、component、version等信息

软件平台的处理流程是：

一、提交BUG

1）点击“New”，选择下方一个对应的产品

2）在上一步选择的产品下，选择对应的component/version以及serverity/hardware等选项（针对以上信息Bugzilla是有默认的选项的，可能不是很适配公司现状，如何做针对性的再定义这些参数大家可以参考我往期的文章《关于Bugzilla的页面定制与修改》）；

选择好以上的选项后，大家不要忘记在summary进行BUG概述（系统自动查重），以及在description进行补充描述；

全部完成后点击submit bug进行该BUG的提交。

3）信息补充

Status：Bug分为三种状态（UNCONFIRMED/CONFIRMED/IN_PROGRESS）

• UNCONFIRMED

此错误最近已添加到数据库中。没有人确认这个错误是有效的。拥有“canconfirm”权限集的用户可以确认此错误，将其状态更改为confirm。或者，可以直接解决并标记为resolved。

• CONFIRMED

此错误是有效的，并且最近已提交。当有人正在处理此状态的Bug时，这些Bug将变为in_PROGRESS，或者已解决并标记为resolved。

• IN_PROGRESS

该错误尚未解决，但已分配给处理该错误的适当人员。从这里开始，错误可以交给另一个人并被确认，或者被解决并被解决。

Alias:一个简短的、唯一的名称，分配给一个bug，以帮助查找它并在Bugzilla的其他地方引用它。
Product:该Bug所属的产品
Component:该Bug所属的产品的组件
Version:该Bug所属的产品的组件的版本
Hardware:产品硬件情况
Importance:Bug的重要性被描述为其优先级和严重性

优先级：Highest代表优先级最高，优先级别自上而下降低，Lowest是优先级最低的；

严重性：serverity代表问题的严重程度Blocker为最严重的，严重程度自上而下降低，enhancement为最轻微的；
Assignee:负责解决错误的人员。
URL:此Bug指向的一个外部链接
Personal Tags:与所有用户都可以看到的全局关键字不同，个人标签是个人标签，只能由作者查看和编辑。编辑它们不会向其他用户发送任何通知。使用它们来标记和跟踪bug。
Depends on（指导描述）:必须先解决此处列出的错误，然后才能解决此错误。
Blocks（指导描述）:必须先解决此错误，才能解决此字段中列出的错误。
Reported:报告此问题的人员和时间
Modified:改进时间（节点）
CC List:抄送列表
Ignore Bug Mail:自动忽略此问题的邮件
See Also:    这允许您参考其他安装中的错误。您可以在“添加bug URL”字段中输入bug的URL，以注意该bug与此bug有关。您可以同时输入多个URL，方法是用空格分隔它们。
您通常应该使用此字段来指代其他安装中的错误。（与其他问题做关联使用）

二、关于提交BUG的时间约束和附件的使用

关于这里我发现这个软件平台并没有非常强的流程的概念，类似于提交一个表单就不能再操作这个表单，之后一环环的去审批；一个最低权用户拥有对自己提交Bug的全部权限，从BUG提交、处理、关闭，可以实现对自己提交BUG的完整闭环流程控制，反过来想，对于目前快节奏且要求技术全面的现在倒也合理哈哈，言归正传，我们来谈一下对于BUG如何去做处理。

首先是涉及时间的表头内容：

• Orig. Est.：开始时估计解决此错误所需的时间。
• Current Est.:目前估计解决此错误所需的时间。
• Hours Worked:到目前为止，在这个bug上花费的总时间。
• Hours Left:这个bug剩下的工作小时数，通过从Orig中减去Worked hours来计算。
• Hours Worked:到目前为止，在这个bug上花费的总时间。
• %Complete:通过比较它的工作时间和原始时间，来计算完成度。
• Gain:增加时间。
• Deadline:最后期限。

继续往下Attachments（附件），通过点击“Add an attachment”了解

File:在计算机上输入文件的路径（或将文本粘贴为附件）。
*注意文件大小限制：1000 KB

Description:简要描述附件。
Content Type:如果附件是修补程序，请选中下面的框。
patch:补丁
*如果不是补丁，需要选择一种确定内容类型的方法。

• 自动检测
• 从列表中选择
• 手动输入

Reassignment：可以选择将此Bug分配给自己，以及修改Bug状态（CONFIRMED/IN_PROGRESS）。

Comment:可以为这个附件添加注释。

三、关于Gug的处理以及关闭

经过上面针对问题的一系列处理，我们终于涉及到对Bug的关闭啦，首先选择将问题的Status的状态调整到以下的“RESOLVED”中，我们可以进行该Bug的关闭以及定义了，我们只有选择过“RESOLVED”，然后才能从关闭的状态的Bug中继续将该Bug的状态改成“VERIFIED”。

• RESOLVED：

已经执行了一个解决方案，正在等待QA的验证。从这里开始，错误要么重新打开并处于打开状态，要么由QA验证并标记为已验证。

• VERIFIED

QA已经查看了错误和解决方案，并同意已经采取了适当的解决方案。这是bug的最终状态。

以下是对于处于关闭状态Bug的定义，我做了翻译，供大家参考。

• FIXED

此错误的修复程序已检查并进行了测试验证。

• INVALID

所描述的问题不是bug。

• WONTFIX

所描述的问题是一个永远无法修复的错误。

• DUPLICATE

该问题是现有错误的重复。当一个bug被标记为“重复”时，您将在解决方案旁边看到它是哪个bug的重复。

• WORKSFORME

所有复制这个bug的尝试都是徒劳的，阅读代码也不会产生所描述的行为为什么会发生的线索。如果稍后出现更多信息，则可以重新打开该错误。

END