目录
一、 概述： - 4 -
二、 目的 - 4 -
三、 执行原则 - 4 -
四、 管理办法 - 4 -
五、 BUG处理流程图 - 5 -
六、 主要职责 - 6 -
七、 需求类问题处理 - 8 -
八、 BUG等级定义 - 8 -
一、概述：
针对目前企业Bugzilla使用情况，发现其中存在很多缺陷，主要表现在：
1、问题模块未划分，导致测试人员查询问题比较困难，出现提交重复问题的现象
2、问题描述不统一、不详细，难理解
3、解决的问题研发人员未及时提交
4、研发人员提交解决的问题，测试人员未及时验证
5、Bugzilla数据庞大，问题查询速度慢
为了能充分利用Bugzilla的各种功能，有效提高工作效率，特制定Bugzilla管理办法。
二、目的
有效控制和管理软件问题，建立一个完善的缺陷跟踪系统，满足各部门的相关需求。
三、执行原则
1、 标准化作业，尊重事实；
2、 测试工程师需要主动与项目组的所有成员保持有效的沟通，以便更好地完成测试任务；
3、 软件开发工程师应及时与测试工程师沟通，尽快重现并解决问题；
4、 尽早发现问题，及时解决问题；减少、预防后序过程中发生问题。
四、管理办法
1、管理流程
2、作业管理办法
1）、测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，通过Email通知项目组长或直接通知开发者。
2）、项目组长根据具体情况，重新reassigned分配给bug所属的开发者。
3）、开发者收到E-Mail信息后，判断是否为自己的修改范围。
A、若不是，重新reassigned分配给项目组长或应该分配的开发者；
B、若是，进行处理，resolved并给出解决方法和处理意见。
4）、测试人员查询开发者已修改的bug，进行重新测试。
A、经验证无误后，修改状态为CLOSED。
B、还有问题，REOPENED，并发邮件通知。
5）、如果这个BUG一周内一直没被处理过。Bugzilla就会一直用E-Mail骚扰它的属主，直到采取行动为止。
一、BUG处理流程图
2、作业管理办法
1）、测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，通过Email通知项目组长或直接通知开发者。
2）、项目组长根据具体情况，重新reassigned分配给bug所属的开发者。
3）、开发者收到E-Mail信息后，判断是否为自己的修改范围。
A、若不是，重新reassigned分配给项目组长或应该分配的开发者；
B、若是，进行处理，resolved并给出解决方法和处理意见。
4）、测试人员查询开发者已修改的bug，进行重新测试。
A、经验证无误后，修改状态为CLOSED。
B、还有问题，REOPENED，并发邮件通知。
5）、如果这个BUG一周内一直没被处理过。Bugzilla就会一直用E-Mail骚扰它的属主，直到采取行动为止。
一、BUG处理流程图
一、主要职责
1、Bugzilla配置管理员：
组织、协调软件配置管理工作，与其它过程之间的关系、协作；管理软件版本。在添加新项目时，把【模块】填写好，并针对不同的模块设定开发人员和测试人员，实现提交报告时自动发给指定的责任人。定时备份结束的项目数据，优化Bugzilla，提高系统运行速度。
2、测试工程师
提交问题：严格按照格式提交问题，详细描述问题实现步骤，如下：
请先进行查询，确认要提交的bug报告不会在原有记录中存在，若已经存在，不要提交，若有什么建议，可在原有记录中增加注释，告知其属主，让bug的属主看到这个后自己去修改。 若Bug不存在，创建一份有效的bug报告后进行提交。
具体操作：点击【新建】，选择产品后，填写一个Bug报告的表格。填表注意：【指派给】为空则默认为设定的owner, 也可手工制定。【抄送】可为多人，需用逗号隔开；【模块】、【软件版本】、【出现机率】、【严重程度】、【领域】，可以根据具体情况自行选择。【注释】【描述】【备注信息】中要详细说明下列内容：
标题--概括描述问题
前提--描述当前测试环境，只针对特殊环境下进行测试时填写
步骤--详细操作步骤
实际结果--执行上述操作步骤后测试机输出结果
期望结果--期望测试机输出结果
死机信息--针对死机问题需要填写
概率--出现问题的概率
例如：
标题：
电话本开启私密保护后,任意输入私秘空间密码界面来电,接听,在通话过程进入选项,选择电话本无效
前提：
步骤：
1、开启电话本私秘保护
2、选择服务中私秘空间或进入开启私密保护的短信或通话记录模块,进入私秘空间密码输入界面
3、来电,接听
4、通话过程进入选项,选择电话本
实际结果：
选择电话本无效,无法进入电话本,功能失效
期望结果：
能正确进入私秘空间密码输入界面
死机信息：
概率：100%
填写完以上所有内容之后，点击提交，系统发送邮件通知给相关人员。
注释：对同系列产品都有的问题，在不同项目上都应该提交，比如A系列问题，如果A1和A2项目上都存在的问题，应该分别在A1和A2上提交，方便对问题进行跟踪，防止研发修改和测试负责人提交报告时遗漏问题。
验证问题：新版本开始测试前，先验证解决的问题，验证完后开始测试。
具体操作：点击【查询】，选择【高级查询】，根据需求，可选择【分类】【产品】、【状态】等查询resolved的问题，在验证问题时，若问题已解决，在【附加说明】中详细描述在那个版本上解决，并CLOSED；若未解决，在【附加说明】中描述验证未解决的版本号，并REOPENED。
只有研发FIXED的问题未修改完全才REOPEN， Reslove状态中其他处理状态的需要重开应选择OPEN。
WORKSFORME的问题测试人员进行跟踪未复现后选择WORKSFORM跟踪的第几个版本并添加附加意见，跟踪到第三个版本未复现后可关闭，待后续有复现再OPEN。
POSTPONE（遗留问题）：客户反馈问题由客户确认遗留或是本地提交未修改先遗留的问题。算DI值，由测试leader设置。
注释：针对研发回馈无法解决、无法重现和设计如此等，不做修改，直接resolved的问题，必须由测试leader进行验证并closed。
跟踪问题：测试人员要一直跟踪提交的Bug，直到Bug修改，验证问题解决为止。对出现概率比较小、很难重现的问题，测试人员应该至少跟踪三个版本后再确认关闭。
1、研发工程师
开发者收到E-Mail信息后，判断是否为自己的修改范围。
A、若不是，重新分配给项目组长或应该分配的开发人员；
B、若是，及时进行处理，分析问题后，resolved并给出解决方法或意见，必须在新版本发布前完成该动作，否则将影响测试进度。描述解决方法或处理意见时，对已解决的问题，尽量写明问题产生原因，以便验证问题的测试人员进行相关波及模块的测试。
研发工程师分析bug后，进行Resolved时，可能出现的情况，以及相关处理要求：
1、fixed（已解决的）：研发需要在“附加信息”中，填写原因分析、测试方案等信息，并注明解决问题的软件版本号。
2、invalid（不是问题）：与质检沟通，确认不是问题可直接关闭；若有争议，由研发项目leader发邮件要求仲裁委员会仲裁，抄送给相关人员。
3、pending（以后解决）：依赖客户或者跨部门资源（研发人员设置状态，VPM SPM主管关注此状态）。
4、wontfix（无法修改）：说明原因，由研发项目leader发邮件要求仲裁委员会仲裁，抄送给相关人员。
5、code_commited：研发修改并提交了代码后由Gerrit根据审核入库的提交说明中的bugID自动触发设置，或是由研发人员手动设置。
6、worksforme（无法重现）：针对出现概率小的问题，由测试人员进行跟踪测试。
7、duplicate （重复）：写明重复bug编号。
注释：针对无法解决、无法重现和设计如此等，不做修改，需关闭的问题，必须由研发leader 来resolved，并详细说明原因。
一、需求类问题处理
1. SPM提出申请创建项目，并提供《项目信息统计表》；
2.SCM根据《项目信息统计表》在Bugzilla创建新项目，并根据《软件模块划分表》创建模块，并通知SPM；
3.SPM根据客户需求提交问题到项目需求中对应产品中，客户需求有更新由SPM同步更新；
4.需求测试人员根据SPM提交的需求类bug进行验证，将需求已实现的bug关闭，未实现的reopen由研发人员继续修改直至需求实现；
5.由需求修改导致的问题，测试人员直接提交到产品中对应的版本及模块，提交bug报告时必须写上对应的导致此bug的需求ID号，另外在该bug对应的需求ID中填写此需求引出的BUG ID号；
二、BUG等级定义
BUG等级分成Critical，Major，Normal,Minor四类。
7.1.Critical
重大致命bug，导致产线停产，客户严重投诉，软件崩溃,冻屏，死机，白屏等现象的缺陷
主要现象
1、 常用操作必现的死机，重启，系统崩溃
2、 产品不符合手机安全标准；
3、 基本功能未实现
4、 12315投诉热点问题。
5、 产品基本功能不可用且通过复位无法恢复
6、 数据丢失（使用过程中用户数据丢失：如信息、联系人、通话记录丢失，重启手 机后无法恢复）
7、 CTS非豁免项问题
8、 版本包问题不符合要求（版本号命名不规则、OTA 升级包缺失、IMEI号擦除）
9、 客户主要需求无法满足（如客户规格书需求、PRI需求等）
10、 基本功能未实现：失效（如：主叫/被叫无作用；通话自动挂断、收发信息无作用按键无作用，失灵等现象）；
11、 白屏、闪屏、发烫问题（测试中出现白屏、闪屏、发烫等问题，要及时提交BUG）
12、 执行正常操作后出现黑屏，按开机键不能开机，需掉电重新启动；
13、 用户投诉最多的问题
14、 产品达不到目标市场法律法规的强制性要求
15、 安装第三方软件导致手机无法再开机问题
16、 充电功能正常，正常充电范围内不会引起电池爆炸等问题
17、 产品对人身安全造成伤害或存在安全隐患，对客户财产构成威胁的缺陷。
18、 可能导致批量性市场或生产故障；
19、 涉及影响运营商形象，涉及影响甲方形象；运营商、甲方的LOGO标志不正确；
20、 可能引起媒体负面报道，包括但不限于燃烧、爆炸、日历错误、漏电、气味
21、 计费错误，以及可能导致直接用户、运营商的意外计费损失或纠纷；
7.2 Major
产品基本功能不可用但用户可通过复位自行恢复，或产品功能失效引起用户投诉退机，导致系统不稳定、或破坏数据、产生错误结果，而且是常规操作中经常发生非常规操作中不可避免的主要问题，但未导致程序死机
主要现象：
- 常用界面显示问题（待机、锁屏、主菜单、通话及各应用主要界面，重叠、缺失、无标识等明显影响用户体验的问题）
- 兼容性：不识卡（如T卡、SIM卡等）
- 工厂自检相关问题：（如某项测试不通过、测试项缺失或多余、相机取景界面蓝屏/花屏现象等。）
- 充电相关问题（如：充电图标不滚动、充电充不满，电池发烫等现象）；
- 有线耳机以及蓝牙耳机无声音（如：耳机通话无声音，听MP3无声音等）；
- 外文版本，待机界面菜单字串/主菜单字串、123级以内菜单字串以及帮助说明字串的显示乱码/空白等；
- 主菜单功能菜单重复、缺失
- 手机触屏效果差、不灵敏，出现无相应、跳屏、鬼手等严重影响用户使用的现象。
- 客户预置APK、用户安装APK恢复出厂设置后还原问题（客户预置的APK恢复后丢失，用户自行安装的恢复后仍然存在的问题）
- 相机像素默认最大插值、相机避免闪烁默认值不符（如：最大差值与配置表不一致、避免闪烁默认值未与该国家的工频保持一致50HZ、60HZ）
- 键盘、输入法问题（默认输入法与默认语言不符、虚拟键盘上的标识与软件实际输出内容不对应）
- 通话过程中有明显的电流声，严重影响用户正常使用；
- 掉电： （1）执行某操作后，黑屏掉电； （2）不进行任何操作，自动掉电；
- 正常使用过程，造成内/外屏花屏、抖动、倒置、严重水波纹等易引起售后退机问题；
- 程序接口错误 如，菜单的进入返回级别错误，导致菜单混乱；页面未完全
按照设计要求显示或刷新等
- 功能不能正常实现 比如发出的声音和设计要求不符合，音质差
- 执行某种正常操作后，手机用户资料自动丢失，重启系统后也无法恢复；
- 常用界面用户容易发现的显示错误，但不影响操作，
- 执行某正常操作后，功能模块或菜单中的用户数据显示乱码，重启后可以恢复；
- 随机问题，未发现规律，但出现概率较大，如：可重现的死机、掉电、自动
重启现象；不能通话、找不到网络、无法开机、无法充电、无法检测耳机；常
用功能失效；不可恢复的花屏、黑屏等现象；电话本丢失；信息丢失；待机耗
流太大等。
7.3. Normal
系统功能目标基本实现，软件功能与需求基本相符，功能实现不完善但不影响用户使用，字串及界面显示问题
主要现象：
- 非正常操作下常用菜单功能的失效，如：按键音失效，调节对比度无作用。
- 单项操作功能可被执行，但在此功能中某些小功能（含指令参数的使用）无法
- 被执行（对系统非致命的）
- 在小功能项的某些项目（选项）使用无效（对系统非致命的）
- 功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现
- 缺陷出现概率很高，但不至于影响基本功能的使用的问题
- 充电显示不正确；（1）充电不提示/充电进度错误；（2）满电或者低电压后电
压值错误；（3）充电时间过长或者过短；（4）插、拔充电器状态显示不正确；
- 某种特定条件下才发生严重故障，操作步骤复杂；
- 非基本功能用户界面提示错误；
- 界面不规范 如： POP框格式不统一，显示图像文字位置形状不规范。
7.4 Minor
简单关联其它操作后故障恢复/在可接受的时间范围内故障自行恢复不易察觉的错误，体验不太令人满意不影响用户使用的错误、失效/标准、规格、协议、性能等偏差小以及建议
主要现象：
1.产品功能可以实现，但用户使用不便；
2.产品与标准、协议、规格存在较小差距，且普通用户难以觉察到；
3.只会影响用户的喜好度，不会影响用户使用的问题，如颜色、界面风格等；
4.对功能、界面显示提交的建议；
5. 简单关联其它操作后故障恢复/在可接受的时间范围内故障自行恢复不易察觉的错误。