Bugzilla系统使用规范有哪些

Bugzilla系统使用规范有哪些，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

一 Bugzilla的状态

状态                                              说明

二 Bugzilla的解决途径

解决途径                                         说明

三 Bugzilla的提交形式

注：提交形式只在状态为resolved，解决途径为fixed时才可使用

四 Bug优先级定义

低                               设备出现问题，但仍可正常运行    问题在时限上没有特别要求  

                                 不影响客户正常使用              开发有时间则纳入计划解决

                                 【时限要求】一周

注：缺陷的优先级可以随着时间推移根据实际情况作调整

五 Bug严重级别规范

六 反馈的缺陷处理说明

6.1 反馈的缺陷处理说明

1) 有关于反馈Bug所涉及的绩效统计，参见《绩效辞典》。

2) 处于resolved（已解决）状态的Bug，必须先将状态变更到verified（已验证）后，才能将状态再变更为closed（已关闭）。变更到verified状态之前，必须填写“缺陷引入阶段”字段（解决途径是：invaild（无效）、duplicate（重复）、worksforme（无法重现）的除外）；

3) 客户现场存在问题，而内部无法重现的反馈Bug，如果能判断较大的可能是由产品缺陷引起的问题，测试经理和产品经理沟通确认后，可以先将Bug状态设置为NEW。后续如果最终确认不是产品缺陷的，将Bug的解决途径设置成INVAILD(无效)；如果最终确认是产品缺陷的，按照缺陷的情况进行处理。（注：与此相关的绩效“产品维护阶段反馈缺陷的平均解决周期”的统计方法是从第一个unconfirmed(未确定 针对反馈bug/需求)到VERIFIED，不包括无效Bug。）

4) 客户现场重现周期长或重现困难，而内部无法重现的反馈Bug，在能保证其他客户处不重复出现，且相关方面可接受规避方案的情况下，可以先规避解决，将解决途径设置成WALKAROUND，状态为RESOLVED，技术支持经理在此之后，等待一个月客户现场不再继续出现问题，也没有再收到同样的缺陷反馈，可将该反馈Bug关闭。如果在等待过程中，再出现问题或收到相同缺陷反馈，将该反馈Bug重新打开REOPENED。在该反馈Bug关闭之后再出现同样问题的话，建立新的反馈Bug进行跟踪，不再重新打开已关闭的反馈Bug。

5) 反馈缺陷的问题确认及复现，由产品质量部负责（特殊或紧急情况开发人员可以进行紧急处理）。UNCONFIRMED状态变更为NEW状态的操作，一般由测试经理或测试人员在问题确认后完成。

七 反馈的需求处理说明

7.1 反馈的需求处理说明

1处于unconfirmed(未确定)状态的反馈需求，必须先将状态更改为new，不能将状态直接更变为resolved(解决途径为invaild无效 duplicate重复的除外 

2 处于new状态的反馈需求，必须先将状态变为assigned（已分配），不能将状态直接变为resolved（解决途径为invaild duplicate的除外）。再变更到assigned之前，必须填写完‘最后期限’（deadline）字段

3 处于confirming(确认中)状态的反馈需求，必须先将状态变更为unconfirmed

7.2 反馈的需求状态机

八 过程bug的处理说明

8.1 过程bug的状态机

九 Deadline填写说明

1 对于可行的，计划在后续予以实现的产品反馈需求，产品经理和测试经理一同评估需求实现周期，提出需求实现计划，计入需求处理系统，并通知系统工程师，产品市场经理

需求实现计划至少包含城垛计划完成的时间点（deadline，指到已验证verified状态的时间点）工作量预计（以 人*小时 为单位），可以包括计划实现的版本号，实现方式等；要求产品经理接到需求处理通知后在2个工作日内完成该任务，同时在bugzilla中将需求记录状态设置为已分配assigned

2 对应确认需要进行修复的产品反馈缺陷，产品经理和测试经理一同评估缺陷修复及完成验证周期。完成讨论之后，产品经理给出修复处理方案，包括承诺计划完成的时间点（deadline，指到已验证verified状态的时间点），记录到bugzilla系统中，分配责任人，并将缺陷记录状态设置为已分配（assigned）

3如果系统工程师，产品市场经理或产品支持经理等认为时间承诺等无法满足市场要求的，可以考虑召集评审会议重新审核，或升级事件到更高一层的领导协调

十 bug引入阶段字段的使用说明

10.1 目的

问题回溯——产品发布后的缺陷分析，用于产品系统质量改进

流程相关问题发掘和流程改进

10.2 范围

在buggilla中新增一个字段，用来定位和回溯发布后反馈bug在生命周期中的引入阶段

用于buggilla中反馈的bug，内部测试暂不执行

10.3 使用说明

10.3.1 引入阶段的定义

对于引入阶段，初步定义为6项：“市场需求”阶段，“测频需求”阶段，“设计”阶段，“编码”阶段，“版本管理”和“历史遗留”，在查询bug 更新bug时可以看到，如下图所示：

10,3,2 填写说明

此阶段定位由开发人员填写，当反馈bug的责任人指向某开发人员时，开发人员响应，处理此bug期间，同时定位bug的引入阶段，如上图所示，在“缺陷引入阶段”右侧的下拉框中选定引入阶段即可

当开发人员不能定位时，须告知产品经理，由产品经理进行定位

为保证问题定位的准确性，以降低后续系统改进趋势分析的偏差，对问题定位需由相关人员进行确认，确保问题定位在组内达成一致，不存在分歧，确任人员如下：

ü 定位为“设计”阶段的反馈bug需架构师或产品经理确认；

ü 定位为“产品需求”阶段的反馈bug需SE或产品经理确认；

ü 定位为“市场需求”阶段的反馈bug需产品市场经理确认；

ü 定位为“版本管理”的反馈bug需项目级配置管理员或产品经理确认；

ü 定位为“历史遗留”的反馈bug需产品经理确认等。

通常建议在反馈bug关闭时，bug引入阶段的定位也需要确定完毕，例外为定位出现分歧的情况，允许直到达成一致时填写完毕；

  因流程改进和系统改进需要，开发中心项目管理组会定期抽取相关数据，周期为2周（每月中旬）或4周（每月最后一周）左右，请各产品组尽量在相关周期内提交完毕。

  此字段填写于2009年5月开始试行。

十一 测试bug提交内容规范

测试人员在提交BUG时，应该按照以下的格式要求，提交BUG相关的信息。

    ENV等处的内容，各个产品可以根据产品自身的特点，增加或裁减相关内容项，例如，RCM组的可能还需要包括插件数、漏洞数、被扫描系统的版本等信息。

十二 开发bug回复内容规范

开发人员在完成BUG定位、BUG修复工作之后，更新BUG状态的同时，应该按照以下的格式要求，对BUG进行回复。尽量将以下内容填写清楚，对的确不涉及的内容，可以省略。

十三 bug验证规范

十四 bugzilla管理规范

十五 主要字段说明

关于Bugzilla系统使用规范有哪些问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注亿速云行业资讯频道了解更多相关知识。