缺陷管理Bug状态流程图
Bug状态流程
-Yang
Bug状态流程图 Bug状态流程图
Bug 处理流程
开发组长/ 开发组长/经理 每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产 每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产 品共同确定）。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是 留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出 留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出 错的模块，进行代码审查。 开发人员 分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B Major类或紧急程度 分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B-Major类或紧急程度 3-High类以上（包含）bug5个或5个以上，停止新功能的开发。 High类以上（包含）bug5个或5 需求人员 解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计 解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计 划 测试人员 不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解 不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解 测试组长/ 测试组长/经理 审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测 审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测 趋势。在测试总结报告中给出意见 产品人员 可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺
新Bug 复测时新出现的Bug 偶发性 原来修改过的问题又重新出现 需求要求但没有做的功能 需求需要完善 与需求不一致 设计要求但没有做的功能
BUG管理规范与流程图
. BUG管理流程与规目录1概述 (5)1.1编写目的 (5)1.2适用围 (5)2关键角色及应负责任 (5)3BUG流程图 (6)4活动描述 (6)5BUG书写规 (8)5.1测试人员BUG提交 (8)5.1.1主题 (8)5.1.2步骤 (8)5.1.3实际结果 (8)5.1.4预期结果 (8)5.1.5备注 (9)5.2开发人员解决BUG (9)6BUG严重等级 (10)6.1致命 (10)6.2严重 (10)6.3一般 (11)6.4优化 (11)7BUG优先级 (12)7.1紧急 (12)7.2高 (12)7.3中 (12)7.4低 (12)8BUG解决方案 (12)8.1设计如此 (12)8.2重复BUG (12)8.3已解决 (12)8.4无法重现 (12)8.5延期处理 (12)8.6新增/变更需求 (12)9BUG状态 (12)9.1激活 (12)9.2已解决 (13)9.3关闭 (13)10其他要求 (13)11相关文件 (13)12附件 (13)1概述1.1编写目的本文档定义bug的整个生命周期，规bug的管理流程。
Bug在流转的过程中有章可循。
规bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug 的严重程度并加以解决。
1.2适用围本文档适用测试人员、开发人员。
2关键角色及应负责任5BUG书写规5.1测试人员BUG提交5.1.1主题•用一个简短的句子描述问题，不要写成一大段•以进入问题模块路径开头，方便项目经理分派任务，以及开发人员定位问题•描述问题时要详细、简练、抓住要点，直接切入正题，不要罗嗦•不要夸大或缩小问题的严重程度5.1.2步骤•用数字编号，一步步的描述重现问题的所有操作步骤•提供明确的再现问题的步骤，避免问题被以“不能重现”关掉•设置区域需要详细描述，如：各设置项值为默认、**值更改为“”，其他设置项值为默认；•尽量用动词作为开头，描述每个步骤。
Bug状态流程图
Bug状态流程图
对Bug的处理
开发组长/经理
每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产品共同确定）。
问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。
有可能是需求的问题，分配给需求人员。
定期对Bug库分析，找出常出错的模块，进行代码审查
开发人员
分析Bug，写出问题原因，修改Bug;实行Bug优先原则，严重程度B-Major类或紧急程度3- High 类以上（包含）bug5个或5个以上，停止新功能的开发。
需求人员解释需求，给出处理意见，将Bug库中的建议整理成需求文档。
评审确定后列入开发计
划
测试人员不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。
验证Bug是否已被解决
测试组长/经理
审核测试人员提交的Bug。
定期对Bug库进行分析，描绘出曲线图等，报告现状、预测趋势在测试总结报告中给出意见
产品人员
可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺
Bug状态（Status）:指缺陷通过一个跟踪修复过程的进展情况。
包括New Open Reopen Fixed、Closed 及Rejected 等。
缺陷管理Bug状态流程图
Bug状态流程图对Bug的处理开发组长/经理每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方:需求、开发、产品共同确定).问题分配时,应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。
有可能是需求的问题，分配给需求人员。
定期对Bug库分析，找出常出错的模块，进行代码审查开发人员分析Bug，写出问题原因，修改Bug;实行Bug优先原则，严重程度B-Major类或紧急程度3-High类以上（包含)bug5个或5个以上，停止新功能的开发。
需求人员解释需求，给出处理意见，将Bug库中的建议整理成需求文档.评审确定后列入开发计划测试人员不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。
验证Bug是否已被解决测试组长/经理审核测试人员提交的Bug。
定期对Bug库进行分析，描绘出曲线图等,报告现状、预测趋势。
在测试总结报告中给出意见产品人员可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺Bug状态(Status)：指缺陷通过一个跟踪修复过程的进展情况。
包括New、Open、Reopen、Fixed、Closed及Rejected等Bug严重级别(Severity，Bug级别):是指因缺陷引起的故障对软件产品的影响程度。
由测试人员指定。
Bug优先级(Priority):指缺陷必须被修复的紧急程度。
由Bug分配者(开发组长/经理)指定。
功能模块(Subject)：TD中需在Test Plan页中定义好Subject,才能在Defects页中使用。
问题描述、附件附图请参见后面第四部分‘Bug描述要求’的有关内容.处理意见:开发组长/经理(或具体Bug分配人员) 在审核新Bug时、将Bug分配给开发人员解决前，需要给出该Bug的处理意见.说明：1. 定为Duplicated的Bug，必须注明和XXXbug重复2。
测试人员对标明为Duplicated的Bug复测，需要XXXBug修改后方可进行3. 定期回顾Can’t Reproduce，Postponed4。
缺陷管理过程中bug流向示意图
缺陷管理过程中bug 流向示意图Bug 由测试人员发现并上报，最终状态还要落回到测试人员。
说明：1. new ——》fixed ——》closetester 发现新问题，developer 修改问题（fixed ），tester 验证问题通过，关闭bug 。
2. New ——》fixed ——》open ——》fixed ——》closeTester 发现新问题，developer 修改问题（fixed ），tester 验证问题没有通过（open ），developer 再次修改问题（fixed ），tester 验证问题通过，关闭bug 。
3. New ——》worksforme ——》invalidTester 发现新问题，developer 发现问题不能重现（worksforme ），且由于tester 自身操作错误引起，tester 将此bug 置为invalid ，此bug 无效。
4. New ——》worksforme ——》laterTester 发现新问题，developer 发现问题不能重现（worksforme ），或只能偶尔复现，在不影响进度的前提下，tester 可暂时将此bug 置于later ，表示之后版本或指定时间修改。
5. New ——》worksforme ——》open ——》fixed ——》closeTester 发现新问题，developer发现问题不能重现（worksforme），经过测试人员演示，问题确实存在，但在之后的版本可能由于其他bug的修改致使此bug也被修改，tester重新open这个bug给developer，进入fixed ——》close流程。
6. New ——》Duplication ——》invalidTester 发现新问题，developer发现这个问题已经有原理类似的bug或完全一致的bug，则将此bug置为Duplication，表示重复了，tester确认是否真的和其他bug重复，如果是，就将此bug置为invalide。
软件缺陷管理流程图
软件缺陷管理办法1.目的本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性，以保证项目研发质量。
2.适用范围适用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规范。
3.定义3.1 术语缺陷（Defect）：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。
Bug：缺陷一种表现形态，系统或程序存在的任何一种破坏正常运转能力的问题。
3.2 缺陷定义（1）软件未达到需求规格说明书的功能；（2）软件出现了需求规格说明书指明不会出现的错误；（3）软件功能超出需求规格说明书的范围；（4）软件未达到需求规格说明书未指出但应达到的目标；（5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。
4.缺陷生命周期4.1 缺陷生命周期图4.2 缺陷状态说明5. 缺陷处理过程5.1 正常处理过程（1）创建问题在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。
创建问题时，需要描述清楚，并选择正确的选项，详细请参考5.4和5.5。
（2）指派问题创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。
如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。
（3）确认问题通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。
如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。
当创建者收到确认指派时，需要进行及时确认。
如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。
如果问题确认指派次数大于6次时，需要进入“争议处理”流程，详细请参考5.2。
（4）解决问题此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。
开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则请参考5.4中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。
缺陷流程图
设备缺陷管理流程图
危 急 缺 陷 巡 视 人 员 现 场 巡 视 整 理 分 类 所 发 现 缺 陷
分 局
提出停电方案及申请 停电处理或 带电处理 汇报分局和用电处同时根 据巡视人员提供情况组织 所需处理人员和物资 若暂不能处理请示局长 或总工批准，同时安排 运行班加强监视，作记 巡 视 或 验 收 申请停电组 织处理 填写记录 填写缺陷及消除记录 （填写带电作业记录）
重 大 缺 陷
班 长ห้องสมุดไป่ตู้审 阅
配 电 专 责
汇报分局和 用电处
一 般 缺 陷
班组自行处理并作好记录 统计汇总每月20日前报配 电专责 每月25日前根据汇总情 况安排月度停电计划 上报用电处 继续汇总 编写年度反事故措施计划，事故备品 备件计划，调整大修项目计划，大修 奖金计划 每月统计一次，组织定期分 析每年进行总统计分析规律 （作运行分析记录） 安排消缺缺并作好记录
缺陷管理流程图
Y
流程结束
节点:
标题:
缺陷管理流程图
编号:
N 运维室专责 缺陷信息审核
Y 检修室专责 缺陷信息审核
运维、检修专责应认真核对班组录入的缺陷信息，确认 字段填写无误，缺陷分级正确。检修室签发消缺工作 票，需停电处理的向调度申请停电计划
检修班组 履行消缺流程 检修班组依据工作票内容处理设备缺陷，完成消缺， 将详细消缺过程和处理详情及消缺人员填入PMS系统 对应表格中。由运维人员对消缺情况进行验收，确认 设备缺陷已消除，完成设备缺陷处理流程。 运维班组验收 N
变电运维
变电检修
流程开始
发现缺陷
运维专业通过设备巡视等方式发现缺陷，或者检修等其他 专业发现缺陷后告知运维单位
录入PMS系统 启动缺陷处理流程
相应运维班组将缺陷内容录入PMS系统缺陷管理模块，同 时告知相应检修班组。要求检修班组告知预计消缺时间， 运维人员应做记录，预计消缺时间应适当提前于消缺考核 期限。如因故未能在预计消缺时间处理，运维人员应提醒 检修人员，确保在规定期限内完成消缺
缺陷管理过程中bug流向示意图
缺陷管理过程中bug 流向示意图Bug 由测试人员发现并上报，最终状态还要落回到测试人员。
说明：1. new ——》fixed ——》closetester 发现新问题，developer 修改问题（fixed ），tester 验证问题通过，关闭bug 。
2. New ——》fixed ——》open ——》fixed ——》closeTester 发现新问题，developer 修改问题（fixed ），tester 验证问题没有通过（open ），developer 再次修改问题（fixed ），tester 验证问题通过，关闭bug 。
3. New ——》worksforme ——》invalidTester 发现新问题，developer 发现问题不能重现（worksforme ），且由于tester 自身操作错误引起，tester 将此bug 置为invalid ，此bug 无效。
4. New ——》worksforme ——》laterTester 发现新问题，developer 发现问题不能重现（worksforme ），或只能偶尔复现，在不影响进度的前提下，tester 可暂时将此bug 置于later ，表示之后版本或指定时间修改。
5. New ——》worksforme ——》open ——》fixed ——》closeTester 发现新问题，developer发现问题不能重现（worksforme），经过测试人员演示，问题确实存在，但在之后的版本可能由于其他bug的修改致使此bug也被修改，tester重新open这个bug给developer，进入fixed ——》close流程。
6. New ——》Duplication ——》invalidTester 发现新问题，developer发现这个问题已经有原理类似的bug或完全一致的bug，则将此bug置为Duplication，表示重复了，tester确认是否真的和其他bug重复，如果是，就将此bug置为invalide。
缺陷管理流程说明剖析
苏宁易购缺陷管理流程错误！未找到引用源。
错误！未找到引用源。
文档记录修订记录批准者此文档需要以下人员批准分发此文档分发给以下部门或单位相关人员：目录1.综述 (5)2.缺陷定义 (6)2.1缺陷状态 (6)2.1.1Jira缺陷流程图 (6)2.1.2JIRA缺陷状态描述 (6)2.2解决结果 (7)2.3JIRA状态与解决结果对应表 (7)2.4缺陷严重程度 (8)2.5缺陷引入阶段 (10)2.6缺陷根源 (11)2.7紧急程度 (12)2.8缺陷管理流程的角色和工作说明 (12)3.流程总览 (14)3.1流程目的 (14)3.2流程范围 (14)3.3流程开始 (14)3.4流程结束 (14)3.5解决结果说明 (14)3.6遗留缺陷定期清理 (15)3.7缺陷关闭和删除 (16)4.缺陷管理流程 (17)4.1流程图 (17)4.2流程解析 (18)1.综述缺陷不仅仅是指软件的Bug，还包括需求、设计上的问题等；通常使用缺陷管理系统管理软件开发过程中所发现的缺陷。
苏宁所有项目均需要统一使用JIRA工具进行缺陷管理。
本文档将从缺陷定义、缺陷流程方面进行介绍，重点介绍缺陷管理的流程，涵盖的主要内容有流程目的、范围，缺陷的相关概念，缺陷管理的阶段和活动详细描述，以及主要角色和工作职责。
2.缺陷定义2.1缺陷状态2.1.1Jira缺陷流程图2.1.2JIRA缺陷状态描述2.2解决结果缺陷生命周期内的解决结果：2.3JIRA状态与解决结果对应表2.4缺陷严重程度在测试过程中发现的缺陷按照严重程度分为五级：阻塞，致命，严重，一般，提示。
只要满足定义描述中的一种情况，就可以判定为相应的严重程度。
对每个严重程度的缺陷，有对修复时间的要求和对复测时间的要求，需要开发团队和测试团队的响应配合，其详细定义及描述如下表：2.5缺陷引入阶段注：日常运维阶段引入的缺陷，属于运维故障，缺陷引入阶段不包含这个阶段。
2.6缺陷根源缺陷根源可用于对测试过程中所发现的缺陷进行根因分析，识别根本原因，并按照度量结果采取有针对性的解决方法和改进措施。
缺陷管理流程(PPT35页)
Bug处理过程实施基本原则
Company Confidential
❖ CQ中提交Bug的操作过程
1.测试人员提交Bug时，需要先选择Owner department，确认是SW的问题，即 选SW，HW即选HW，其他同理
2.再根据项目名称，选择Project 3.其他字段可以不分顺序进行填写，标识红色字段为必填项，如果有必填项为空，
5. 分配过程中如出现转Bug、Reject Bug，Duplicate Bug的需求，申请人首先要和关联人 员进行充分沟通，达成一致后发出正式邮件向项目管理层申请并将邮件内容通过modify notes字段填写到CQ中
1）沟通
▪ Feature/Team间转bug：Feature owner之间的沟通
3.Due date的选择需要符合release plan
4.如果是交叉bug，测试人员识别的module name不够准确，PDM是可以在
assign的时候进行修改的
5.需要必填carrier字段，标识Bug在哪些版本上存在(通常用于指明不同的运营 商)
Page 14
Doc No:FMZ06-0006 Ver:1.1
是不能提交当前记录的 4.提交Bug时填写的字段注释如下：
Page 8
Doc No:FMZ06-0006 Ver:1.1
Bug处理过程实施基本原则
Company Confidential
1. Cust_ID:自动生成 (项目名称简写_P+自定义的连续ID) 2. State: Bug当前处理状态，参考Bug状态迁移图 3. Headline: Bug的概要描述，测试人员要使用能突出Bug失效现象的词语，
3.确认CQ的操作权限 CQ为bug处理过程中涉及到的角色分配了操作权限。 如果没有权限，请向CM提出申请，CM会根据申请人的角色开放操作权限
CBOD-SIT缺陷流程操作ppt课件
附3：缺陷管理流程状态概述
在测试问题管理平台中，为了使测试人员的问题从提出到关闭能 顺利的传递到不同的问题解决人手中，问题管理平台设置了10个
问题状态，描述如下：
附3：缺陷管理流程状态概述
附3：缺陷管理流程状态概述
CQ安装
http://66.10.10.3/cqweb/login http://66.10.10.4/cqweb/login \\66.10.10.4客户端使用cc客户端使用cc用
严重程度二级
› 生产系统部分功能或者软件出现故障，但仍可全面运行且无账务性差错，对客户业务系统的正常运行有一定 的或轻微的操作影响。
› 例如：一个用户无法联接到服务器。
严重程度一级
› 需要硬件、软件产品功能、安装、或配置方面的信息或支援。对客户的业务运作几乎没有影响或根本没有影 响。
每个严重性等级的问题/缺陷从
测试人员工作区
➢ 复测通过，缺陷流程结束，状态为已关闭
➢ 复测未能通过，返回到待审核状态（问题编号不变）
SIT缺陷管理流程图
SIT缺陷流程——各角色工作区
技术排错组长 （开发技术组长）
技术排错组长
开发人员
复测不通过
版本组/环境组 测试人员
测试组长及 登记人员
提交
待 审核
缺陷排错 返回
待 排错
分配 正在开发
SIT缺陷管理流程
——操作流程培训
Outline
SIT缺陷管理流程。 缺陷管理流程步骤演示 。
SIT缺陷管理流程图
SIT缺陷流程——各角色工作区
技术排错组长 （开发技术组长）
技术排错组长
开发人员
复测不通过
版本组/环境组 测试人员
《bug处理流程》
《bug处理流程》BUG处理流程说明⼀、BUG处理流程图：流程描述：1、测试⼈员发现bug提交给开发。
2、开发⼈员判断是否是bug。
3、如果是bug，进⾏修改，修改完成后更改bug状态为已解决。
4、如果不是bug，退回给测试⼈员并描述退回原因，或为设计如此，或为外部原因，或者不能重现。
5、开发⼈员修改完成的bug，由测试⼈员进⾏验证，确认修改正确，关闭bug。
6、验证未通过的bug重新激活，开发⼈员继续修改，直⾄验证通过，关闭bug。
7、测试⼈员需要对开发⼈员退回的bug进⾏确认。
8、确认不是bug关闭。
9、如与开发⼈员意见不⼀致，认为是bug，需提交项⽬负责⼈仲裁。
10、项⽬负责⼈确认是bug由开发⼈员修改，不是bug由测试⼈员关闭。
注：除提交项⽬负责⼈仲裁环节外，其他环节都可以在禅道上完成。
⼆、各⾓⾊应关注的状态1.开发⼈员：激活、重新打开激活：开发⼈员要对处于激活状态的bug进⾏处理，处理后将其状态置成“已解决”、“设计如此”、“⽆法重现”、“外部原因”、“重复bug”或“延期处理”。
重新打开：重新打开的bug是已解决的bug经过测试⼈员验证，未修改正确，需要继续修改。
2.测试⼈员：已解决、⽆法重现、设计如此、外部原因、延期处理已解决：测试⼈员发现状态为“已解决”的BUG，要及时验证，如果确实已解决，要将其置为“关闭”。
否则“重新打开”⽆法重现：测试⼈员发现状态为“⽆法重现”的BUG，要及时修改，把步骤描述清楚，并将其状态置为“重新打开”。
设计如此：测试⼈员发现状态为“设计如此”和“外部原因”的BUG，要及时通知项⽬经理，由项⽬经理来决定是否修改；对“延期处理”的问题要进⾏定期跟踪，如发现问题没有按注释进⾏修改要及时通知开发⼈员或汇报给相关负责⼈。
3.项⽬经理：设计如此、外部原因、延期处理设计如此：因为这些BUG都是测试⼈员和开发⼈员有争议的BUG，因此项⽬经理必须及时关注这些BUG，及时给出合理的定夺，如果不需修改把状态置成“关闭”，如果需要⽴刻解决置成“重新打开”，否则置成“以后解决”。
BUG管理规范与流程
标准化文件发布号：(9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-....................................................................................................................................编写目的 (5)合用范围 (5).........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................测试人员BUG 提交 (8)主题 (8)步骤 (8)实际结果 (8)预期结果 (8)备注 (9)开辟人员解决BUG (9).....................................................................................................................致命 (10)严重 (10)普通 (11)优化 (11).........................................................................................................................紧急 (12)高 (12)中 (12)低 (12).....................................................................................................................设计如此 (12)重复BUG (12)已解决 (12)无法重现 (12)延期处理 (12)新增/变更需求 (12).............................................................................................................................激活 (12)已解决 (13)关闭 (13)...............................................................................................................................................................................................................................................................................................................................................本文档定义bug 的整个生命周期，规范bug 的管理流程。
缺陷处理流程
缺陷处理流程1缺陷处理流程1.缺陷处理流程图如下：2.缺陷处理流程图中判定说明：1)是否打开缺陷：开发组长/经理查阅缺陷，确认为缺陷后，指定优先级、估计修复日期再指派给相关开发人员；如果确认为不是缺陷的，注释中说明理由，予以否决。
2)处理缺陷：开发处理缺陷；如果缺陷短期内进行修复存在困难，且该缺陷对于功能实现影响不大的，应该给开发组长/经理说明情况，让开发组长/经理与缺陷相关人员协调后延期处理该缺陷，并在注释中说明理由，估计修复日期和指明计划关闭版本。
3)是否关闭：测试人员对回归通过的缺陷进行关闭；否则重新打开缺陷。
并在注释中说明重新打开理由。
3.缺陷处理流程图中流程说明：1)新建缺陷：测试人员（其他人员）根据缺陷填写说明，新建缺陷。
2)已否决：对已否决的缺陷，最后由测试发起会议（形式可以根据情况而定），找到缺陷相关人员进行确认。
如果确认为是无效的缺陷，保持“已否决”状态，否则重新打开缺陷，并指派给相关处理人员。
3)（重新）打开：开发人员应该处理自己手上“打开”和“重新打开”的缺陷。
4)延期处理：开发组长/经理根据情况，对缺陷进行延期处理。
5)已经修复：开发人员处理完缺陷后，把缺陷状态改为“已修复”状态。
并通知测试人员进行回归。
6)回归测试：测试人员对已经修复的缺陷进行回归。
7)关闭缺陷：测试人员回归测试通过后，对缺陷进行关闭。
4.为了说明各个角色在缺陷处理流程中的职责，据测试流程所画泳道图如下：如果上面判定和流程中，某一方存在异议的，应及时反馈上级。
然后上级根据缺陷优先级、实际情况等，找恰当的时间发起会议（或其他）的方式找到缺陷相关人员进行沟通、协调和处理。
2缺陷填写说明1.BUG全部提交到QC中（指定域名的指定项目下）。
2.“摘要”，用简单明了的语句说明白你这个BUG，相当于BUG的中心语句。
3.详细信息填写规范：1)“分配给”，选择这个BUG所属模块是属于那个研发人员，并把问题指派给他（如果不知道，就直接提交给该负责人）。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Bug状态流程图
对Bug的处理
开发组长/经理
每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产品共同确定）。
问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。
有可能是需求的问题，分配给需求人员。
定期对Bug库分析，找出常出错的模块，进行代码审查
开发人员
分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B-Major类或紧急程度3-High 类以上（包含）bug5个或5个以上，停止新功能的开发。
需求人员
解释需求，给出处理意见，将Bug库中的建议整理成需求文档。
评审确定后列入开发计划
测试人员
不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。
验证Bug是否已被解决
测试组长/经理
审核测试人员提交的Bug。
定期对Bug库进行分析，描绘出曲线图等，报告现状、预测趋势。
在测试总结报告中给出意见
产品人员
可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺
Bug状态(Status)：指缺陷通过一个跟踪修复过程的进展情况。
包括New、Open、Reopen、Fixed、Closed及Rejected等
Bug严重级别(Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响程度。
由测试人员指定。
Bug优先级(Priority)：指缺陷必须被修复的紧急程度。
由Bug分配者（开发组长/经理）指定。
功能模块(Subject)：TD中需在Test Plan页中定义好Subject，才能在Defects页中使用。
问题描述、附件附图请参见后面第四部分‘Bug描述要求’的有关内容。
处理意见:开发组长/经理(或具体Bug分配人员) 在审核新Bug时、将Bug分配给开发人员解决前，需要给出该Bug的处理意见。
说明：
1. 定为Duplicated的Bug，必须注明和XXXbug重复
2. 测试人员对标明为Duplicated的Bug复测，需要XXXBug修改后方可进行
3. 定期回顾Can't Reproduce,Postponed
4. 定期整理By Design
其它一些字段（及所定义的枚举值）的定义解释，供有需要用到的组参考：
测试状态（TestState）：新提交的Bug定位标准。
由测试人员指定。
一般有8个（提交Bug时给出）
复测状态(ReTestState)：复测时给出的状态，测试人员对于经过验证的Bug应按以下几种标准进行定位。
由测试人员指定。
一般有1－OK、2－PD、3－DV、4－NB、5－NR、6－AR。
问题定位：
缺陷来源(Source)：指引起缺陷的起因。
类型(Type)：是根据缺陷的自然属性划分的缺陷种类。
（以上依各组实际情况可以作适当调整）
项目组各角色在Bug库中的权限
管理员：全部权限
测试组长/经理：全部权限
测试人员：可添加Bug、不能删除Bug、可添加注释评论(R&D Comments)、不可修改他人所提Bug、可调整：Bug概要(题目，Summary)、问题描述、附件附图(Attachments)、Bug状态、Bug级别、测试版本、测试产品、功能模块、测试状态、问题定位、复测状态、注释评论(R&D Comments)、复测人、复测日期、修改人
开发人员/需求人员：不能删除Bug、可添加注释评论(R&D Comments)、可调整：注释评论(R&D Comments)、是否复现、Bug状态（不过无法直接标为closed）、问题描述、处理意见、待测版本、修改人、修改日期。
可添加Bug。
开发组长/经理/需求经理：除了开发人员的权限，还可调整：优先级别、责任人、Bug概要(题目，Summary) 、附件附图(Attachments)
项目经理：可添加Bug、可添加注释评论(R&D Comments)、可修改字段：Bug概要(题目，
Summary) 、问题描述、附件附图(Attachments) 、Bug状态（不过无法直接标为closed）、修改人、优先级别、问题定位、处理意见、注释评论(R&D Comments) 、是否复现、责任人、待测版本。
也可删除Bug，但要与测试组长/经理协商。
不属于项目组成员的其他人如研发中心经理组成员等，有必要查看TD库的话，可分配给其帐号及查看的权限。
Bug描述要求
Bug描述的要求为分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查（截图或其它形式的附件）。
测试组长/经理把关，以开发人员的角度来审查Bug描述，看其是否描述清楚了Bug，不好描述的把工程文件或截图作为附件提交。
具体要求为：
•问题描述一般格式：问题描述时，建议分几步描述：模块或功能点=>测试步骤=>期望结果=>实际结果=>其它信息，可依实际情况调整；
•单一：尽量一个报告只针对一个软件缺陷，报告形式应方便阅读。
在主报告之后应注明不同的条件；
•简洁：每个步骤的描述应尽可能简洁明了。
只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息；
•再现：问题必须在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）；
•复杂的问题应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的文件格式建议用JPG或GIF，不建议用BMP；抓图可用TestDirector自带的功能，亦可
用HyperSnap之类的专用抓图工具。
•报告中不允许使用抽象词句：比如“有错误”之类；
•有关操作系统特征问题：应在不同操作系统上进行操作，看是否能重现，并在Bug报告中标识；
•Bug描述示例：
注：所有项目采用TestDirector进行Bug管理，该工具能从测试步骤自动生成Bug报告，因此对于Bug描述要求在测试方案用例设计（在Test Plan页中）阶段就可以进行控制。
附：好的Bug报告应满足以下几方面的要求：
•结构清晰
•复现故障再写报告
•隔离Bug：更改条件复测
•归纳：是否其他模块也有相同的Bug
•比较：其他测试用例是否使用到此Bug
•总结：报告的开头有Bug的总结
•精简：不要有多余的步骤和语言
•无歧义：语言明确
•中立：无批评性语言
•讨论：将要发出的报告送其他测试人员讨论
小结
•通过专业的技术测试出精确的Bug；
•通过准确的文档报告Bug；
•通过良好的沟通使Bug尽快解决。