Bugzilla系统使用规范
一 Bugzilla的状态
状态 说明
unconfirmed | 未确定(针对反馈Bug/需求) |
confirming | 确认中(针对反馈需求) |
new | 新建 |
assigned | 已分配 |
resolved | 已解决 |
verified | 已验证 |
closed | 已关闭 |
reopened | 重新打开 |
二 Bugzilla的解决途径
解决途径 说明
fixed | 已修复 |
waitpacket | 等待打包(已经废弃,待删除 ) |
invaild | 无效 |
wontfix | 决定不改 |
later | 后续版本 |
duplicate | 重复 |
worksforme | 无法重试 |
walkaround | 以规避 |
remind | 提醒 |
moved | 已移出 |
三 Bugzilla的提交形式
提交形式 | 说明 |
file | 文件 |
built | 升级包 |
code | 代码 |
注:提交形式只在状态为resolved,解决途径为fixed时才可使用
四 Bug优先级定义
优先级 | 缺陷反馈BUG | 内部BUG |
高 |
1 因我公司设备导致客户网络或业务系统中断或瘫痪;【时限要求】:24小时 2 设备出现严重问题或者不可用,并导致客户网络或业务系统无法正常工作【时限要求】:48小时 |
1 阻碍测试继续运行 2 项目测试进度计划受到极大影响 3 影响结项通过的 4 影响当前测试升级包发布的 5 已知问题在对外发布版本也存在,并且有导致客户网络或业务系统中断或瘫痪风险的 【时限要求】:48小时 |
中 |
在线串联设备出现严重问题,但客户网络或业务没有受到影响 【时限要求】:72小时 |
从当前时间点上看问题紧急程度不高,时限要求: 1 必须在结项版本解决 2 必须在当前测试升级包发布版本解决 3 在测试和开发双方商议的deadline期限内解决 |
低 设备出现问题,但仍可正常运行 问题在时限上没有特别要求
不影响客户正常使用 开发有时间则纳入计划解决
【时限要求】一周
注:缺陷的优先级可以随着时间推移根据实际情况作调整
五 Bug严重级别规范
严重程度等级 | 定义标准 | 示例 Bug相关产品 |
critical |
1 导致客户网络或业务系统中断或瘫痪 2 系统崩溃/挂起 数据丢失或内存严重泄漏等导致系统不可用 3 系统存在易于***且危害高的安全漏洞 |
【公共平台】Bug 24149:设备外网口疑似LAND***后NAT池资源耗尽导致TCP通讯异常 【eps】bug 10581 发现内存,句柄泄漏现象 |
major |
1 功能严重不可用,或影响系统自身业务流程完成 2 系统存在易于***或危害高的安全漏洞 |
【公共平台】Bug 25432 URL过滤功能失效 【EPS】Bug 13915 代理端口开机5分钟左右以后,自保护功能失效 |
nornal |
1、功能部分不可用,影响一般:不影响客户业务系统正常运转,同时也不影响系统自身业务流程完成; |
IPS] Bug 23624:29001号规则误阻断风行在线视频
[公共平台] Bug 25657:清除报表后,页面出现http404提示 |
trivial |
UI显示、文本、文字等错误,且不影响功能 |
|
enhancement | 建议性质的意见 |
六 反馈的缺陷处理说明
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管理规范
十五 主要字段说明
转载于:https://blog.51cto.com/12730159/1946835
Bugzilla系统使用规范相关推荐
- 简化服装ERP系统的规范流程和规范功用
简化服装ERP系统的根底数据 根底数据的收拾是服装ERP系统施行过程中十分冗杂的作业,一起事务的改变大多需求从头收拾根底数据. 根底数据的收拾需求记载事务数据,但公司每天产生的事务各种各样. 想把什么 ...
- 最标准的系统字体规范font-family
最标准的系统字体规范font-family 注意系统默认字体和浏览器默认字体这个差别. 直接提供方案: font: 14px/1.6 /*西文*/-apple-system,BlinkMacSyste ...
- Android系统字体规范
我们在做Android移动APP设计的时候,字号的选择也是很让人头疼,转载一份有关Android系统字体规范,如果在做Android项目的用户应该看看,如果有任何建议欢迎在留言处与我们交流探讨. 主要 ...
- 进销存仓库管理系统:规范数据、流程与管理
库存管理是仓储管理的重要组成部分,但营运过程中更多重视货品售出和采购,忽视货品存货对整体营运效果的影响. 传统仓储通过人力经验与感觉对整个仓库库存管理,缺乏科学规范的库存管理方法,库存管理方面存在着整 ...
- oracle系统开发规范,SQL编写规范与优化(适用于Oracle).ppt
<SQL编写规范与优化(适用于Oracle).ppt>由会员分享,可在线阅读,更多相关<SQL编写规范与优化(适用于Oracle).ppt(23页珍藏版)>请在装配图网上搜索. ...
- 介绍信贷产品进件要求及系统录入规范
关注 "番茄风控大数据",获取更多数据分析与风控大数据的实用干货. 本文基于产品的进件逻辑,从渠道营业厅采集的数据规划化入手,跟各位分享下目前,那些依赖线下进件的产品的录入规划化的 ...
- 地铁车站疏散指示系统新规范标准
随着国家对消防设计重视程度的提高,2019年3月1日起实施的GB51309-2018<消防应急照明及疏散指示系统技术标准>(简称"<应急照明标准>")对消防 ...
- 应用系统安全规范-自己想到和网络搜索到的点子记录整合一下
应用系统安全是当前众多大型企业要重点关注的问题,但这块有好多工作要做,现状是现在很多做安全的人,不怎么太做开发,做开发的人懂安全的人又少之又少,这里我从应用系统安全,提出几点自己的建议,当然不足之处还 ...
- 软件智能:aaas系统 语言规范的基础
一.需求分析与概要设计 需求分析的 模板.模式和模型: 概要设计的组织图:图解.图例.和图样 一个图算法- 图式推理[图解],一个图实例- 实物陈列[图例],一个图- 样式呈现[图样] 1.对应三种模 ...
最新文章
- Python的优点?
- 什么样的文献有html阅读,有关html的参考文献
- SQL中的Null值
- [译] 最佳安全实践:在 Java 和 Android 中使用 AES 进行对称加密
- 3天html自学教程,html自学教程(八)html5基础
- 移动spa商城优化记(一)---首屏优化篇
- graphics | 基础绘图系统(十)——星形图、四瓣图、马赛克图
- 《易扫码》APP技术服务支持与隐私政策
- Android Dialog详解
- gvdp哪个工厂用_ppr铝塑管和ppr水管哪个更适合家装?
- 2022年计算机软件水平考试嵌入式系统设计师(中级)练习题及答案
- 学习廖雪峰的Git教程
- C++洛谷题解(1)
- Blender几个简单建模
- JSR规范系列(1)——Java版本、JSR规范和JCP社区流程概述
- EBS-自动获取/创建CCID
- 如何在CentOS 7系统搭建企业常用的远程yum仓库,详细教学!
- 必备的Word软件应用技巧
- 西安交通大学轴承公共数据集(文末附数据)
- 图文并茂详解服务器密码忘记了怎么办?
热门文章
- 亚声速 – 超声速等熵喷管流动 数值模拟(文字)
- Windows10下安装Elasticsearch8.1.1过程遇到的问题
- notepad++使用一行多个关键字的与搜索,同时搜索多个关键词的或搜索
- springcloud-alibaba-sentinel(1)sentinel流量卫兵介绍
- RMQ---csu1809
- NOI / 2.1基本算法之枚举 1809:两倍
- 带栩字的优美古诗句_带栩字有寓意的男孩名字
- Java实现最近点问题
- mysql优化的魅力,从20s优化到500ms,仅需三招(荣耀典藏版)
- 深度学习基础--输出层的神经元数应该与分类数匹配(分类数大于等于2)则是一个监督学习任务,对吗?