Bugzilla系统使用规范有哪些

Bugzilla系统使用规范有哪些，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。一 Bugzilla的状态
状态 说明二 Bugzilla的解决途径解决途径 说明三 Bugzilla的提交形式
注：提交形式只在状态为resolved，解决途径为fixed时才可使用四 Bug优先级定义1 因我公司设备导致客户网络或业务系统中断或瘫痪；【时限要求】：24小时2 设备出现严重问题或者不可用，并导致客户网络或业务系统无法正常工作【时限要求】：48小时1 阻碍测试继续运行2 项目测试进度计划受到极大影响3 影响结项通过的4 影响当前测试升级包发布的5 已知问题在对外发布版本也存在，并且有导致客户网络或业务系统中断或瘫痪风险的【时限要求】：48小时在线串联设备出现严重问题，但客户网络或业务没有受到影响【时限要求】：72小时从当前时间点上看问题紧急程度不高，时限要求：1 必须在结项版本解决2 必须在当前测试升级包发布版本解决3 在测试和开发双方商议的deadline期限内解决低 设备出现问题，但仍可正常运行 问题在时限上没有特别要求 不影响客户正常使用 开发有时间则纳入计划解决
【时限要求】一周
注：缺陷的优先级可以随着时间推移根据实际情况作调整五 Bug严重级别规范1 导致客户网络或业务系统中断或瘫痪2 系统崩溃/挂起 数据丢失或内存严重泄漏等导致系统不可用3 系统存在易于***且危害高的安全漏洞【公共平台】Bug 24149：设备外网口疑似LAND***后NAT池资源耗尽导致TCP通讯异常【eps】bug 10581 发现内存，句柄泄漏现象1 功能严重不可用，或影响系统自身业务流程完成2 系统存在易于***或危害高的安全漏洞【公共平台】Bug 25432 URL过滤功能失效【EPS】Bug 13915 代理端口开机5分钟左右以后，自保护功能失效1、功能部分不可用，影响一般：不影响客户业务系统正常运转，同时也不影响系统自身业务流程完成；
2、系统存在一般性的安全漏洞
[公共平台] Bug 25657:清除报表后，页面出现http404提示
UI显示、文本、文字等错误，且不影响功能六 反馈的缺陷处理说明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(确认中)状态的反馈需求，必须先将状态变更为unconfirmed7.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系统使用规范有哪些问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注开发云行业资讯频道了解更多相关知识。

相关推荐: Qemu0.10.0发布有哪些特点

这篇文章主要介绍Qemu0.10.0发布有哪些特点，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！Qemu 团队已发布 0.10.0 版本。该版本历经一年多的开发，从 80 位开发者带来了几近 3000 个改动。Qemu 0.10.0 的…