缺陷管理Bug状态流程图说课讲解
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 由测试人员发现并上报，最终状态还要落回到测试人员。
说明：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。
Bug管理Bug的3种状态状态说明Active（活动）Bug的初始状态。任何
BUG 生命周期新建的Bug处于Active状态，可以通过编辑指派给合适的解决者。
解决Bug之后，Bug状态变为Resolved，并自动指派给创建者。
创建者验证Bug。
如果未修复，再重新激活，Bug状态重新变为Active；如果已经修复则可以关闭，Bug状态变为Closed，Bug生命周期结束。
已经Closed的Bug如果重新复现，也可以直接激活。
具体流程如下图所示。
BUG 字段说明Bug 标题：为包含关键词的简单问题摘要，要有利于其他人员进行搜索或通过标题快速了解问题项目名/模块路径：指定问题出现在哪个项目的哪个模块。
Bug处理过程中，需要随时根据需要修改项目或模块，方便跟踪。
如果后台管理指定了模块负责人，选择模块时，会自动指派给负责人指派给：Bug的当前处理人。
如果不知道Bug的处理人，可以指派给Active，项目或模块负责人再重新分发、指派给具体人员。
如果设定了邮件通知，被指派者会收到邮件通知。
此外，状态为Closed的Bug，默认会指派给Closed，表示Bug生命周期的结束抄送给：需要通知相关人员时填写，例如测试主管或者开发主管等。
可以同时指派多个，人员之间用逗号分隔。
如果设定了邮件通知，当Bug有任何更新时，被指派者会收到邮件通知严重程度：Bug的严重程度。
由Bug的创建者视情况来指定。
1为最严重的问题，4为最小的问题。
一般来讲，1级为系统崩溃或者数据丢失的问题；2级为主要功能的问题；3级为次要功能的问题；4级为细微的问题优先级：Bug处理的优先级。
一般由Bug的解决人员按照资源和项目的进度指定。
1的优先级最高，需要尽快处理，4的优先级最低其余选项字段（Bug类型、如何发现、操作系统、浏览器）：可以通过编辑Lang/ZH_CN_UTF-8/_COMMON.php来自定义创建Build：Bug是在哪个版本（Build或者Tag）被发现的解决Build：Bug是在哪个版本（Build或者Tag）被解决的解决方案：参考Bug的7中解决方案。
缺陷管理流程图
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缺陷处理流程1.缺陷处理流程图如下：2.缺陷处理流程图中判定说明：1)是否打开缺陷：开发组长/经理查阅缺陷，确认为缺陷后，指定优先级、估计修复日期再指派给相关开发人员；如果确认为不是缺陷的，注释中说明理由，予以否决。
2)处理缺陷：开发处理缺陷；如果缺陷短期内进行修复存在困难，且该缺陷对于功能实现影响不大的，应该给开发组长/经理说明情况，让开发组长/经理与缺陷相关人员协调后延期处理该缺陷，并在注释中说明理由，估计修复日期和指明计划关闭版本。
3)是否关闭：测试人员对回归通过的缺陷进行关闭；否则重新打开缺陷。
并在注释中说明重新打开理由。
3.缺陷处理流程图中流程说明：1)新建缺陷：测试人员（其他人员）根据缺陷填写说明，新建缺陷。
2)已否决：对已否决的缺陷，最后由测试发起会议（形式可以根据情况而定），找到缺陷相关人员进行确认。
如果确认为是无效的缺陷，保持“已否决”状态，否则重新打开缺陷，并指派给相关处理人员。
3)（重新）打开：开发人员应该处理自己手上“打开”和“重新打开”的缺陷。
4)延期处理：开发组长/经理根据情况，对缺陷进行延期处理。
5)已经修复：开发人员处理完缺陷后，把缺陷状态改为“已修复”状态。
并通知测试人员进行回归。
6)回归测试：测试人员对已经修复的缺陷进行回归。
7)关闭缺陷：测试人员回归测试通过后，对缺陷进行关闭。
4.为了说明各个角色在缺陷处理流程中的职责，据测试流程所画泳道图如下：如果上面判定和流程中，某一方存在异议的，应及时反馈上级。
然后上级根据缺陷优先级、实际情况等，找恰当的时间发起会议（或其他）的方式找到缺陷相关人员进行沟通、协调和处理。
2缺陷填写说明1.BUG全部提交到QC中（指定域名的指定项目下）。
2.“摘要”，用简单明了的语句说明白你这个BUG，相当于BUG的中心语句。
3.详细信息填写规范：1)“分配给”，选择这个BUG所属模块是属于那个研发人员，并把问题指派给他（如果不知道，就直接提交给该负责人）。
bug管理流程-图解
状态流程图：软件错误的状态新信息(New)：测试中新报告的软件缺陷；打开 (Open)：被确认并分配给相关开发人员处理；修正(Fixed)：开发人员已完成修正，等待测试人员验证；拒绝(Declined):拒绝修改缺陷；延期(Deferred): 不在当前版本修复的错误，下一版修复关闭(Closed)：错误已被修复；人员角色new—tester（测试工程师）declined-not bug--Test Supervisor（测试主管）declined-duplicated--Test Supervisor（测试主管）open--Project Manager/Technical Manager（项目经理/技术主管）fixed—programer（工发工程师）closed—tester（测试工程师）deferred-next build--Test Supervisor（测试主管）deferred-next main release--TestSupervisor（测试主管）Bug管理的一般流程1. 测试人员提交新的Bug入库，错误状态为New。
2. 高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。
如果不是错误，则拒绝，设置为Declined(拒绝)状态。
3. 开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。
不能解决的Bug，要留下文字说明及保持Bug为Open状态。
对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。
4. 测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。
软件错误流程管理要点为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。
障碍管理流程图
测试人员
起票（bug 票状态）
对应中（bug 票状
态）
对应结束（bug 票
状态）
责任者(测试人员)确认（bug 票状态）
关闭（bug 票状态）
对应人以邮件通知测试者，测试者并修改bug 票状态
对应人对应修改后，修改bug 票状
态
修改bug 状态
PM
邮件专门形式通知
流程描述：
1、测试人员首先进行测试，当有bug 票时，修改其状态为“起票”并对bug 现象进行文字描述，期票之后，测试者可以选择对应人或者选择让系统会自动发邮件给PM 。
2、当PM 收到邮件之后，PM 指定对应人对bug 进行对应。
当对应人收到邮件之后，对bug 进行对应。
3、对应人修改bug 票状态为“对应中”。
4、在“对应中”状态时，对应人对bug 进行对应并对如何解决bug 进行文字描述，上述之后，对应人修改bug 票状态为“对应结束”并以电子邮件形式通知测试者。
5、测试者收到邮件后，修改bug 票状态为“责任者确认”并确认之，若无，则修改bug 票状态为“关闭”。
若有bug ，修改bug 票状态为“关闭”，并重新起票执行步骤1。
对应人
指定
修改bug 票状态
对应人
邮件默认形式通知。
缺陷管理流程PPT课件
针对严重影响产品功能或 用户体验的缺陷，优先进 行紧急修复，确保产品稳 定性和可用性。
计划内修复策略
根据产品迭代计划和缺陷 优先级，合理安排修复计 划，确保按计划完成修复 任务。
临时解决方案
针对暂时无法彻底修复的 缺陷，提供临时解决方案 ，降低缺陷对产品的影响 。
修复过程监控
施
启动缺陷跟踪流程，收集缺陷信息，确认缺陷并分配 给处理人员，对处理过程进行跟踪，最终将处理结果 反馈给相关人员。
案例介绍
报告编制情 况
通过本次案例，我们认识到了缺陷跟踪和报告的重要 性，同时也发现了一些问题和不足之处，需要在今后
的工作中加以改进和完善。
经验教训
根据编制要求，及时编制了完整的缺陷报告，包括缺 陷描述、影响范围、严重程度、处理过程和结果等信 息。
规范性
使用统一的缺陷记录模板，遵 循规定的记录流程和标准。
可追溯性
确保记录的缺陷信息可追溯， 便于后续的跟踪和管理。
实例分析：某产品缺陷识别与记录
• 案例介绍：某公司开发的一款软件产品，在上线后出现了一些问题，需要进行缺陷识别与记录。 • 识别方法与技巧应用：通过观察、询问、测试和分析等方法，发现了软件中存在的多个缺陷，包括界面显示错
缺陷分类
根据严重性、优先级、影响范围 等因素，将缺陷划分为不同类型 ，如严重缺陷、一般缺陷、优化 建议等。
缺陷管理重要性
01
02
03
提高软件质量
通过发现和修复缺陷，提 高软件的稳定性和可靠性 ，减少用户投诉和故障率 。
提升开发效率
合理的缺陷管理可以避免 无效返工和资源浪费，提 高开发团队的协作效率。
进度监控
实时跟踪修复进度，确保按计划完成 修复任务。
缺陷管理流程(附图)
缺陷管理流程【背景】缺陷管理流程背景：自动化报告存在失败或错误的问题，出现这些问题的原因可能是软件bug，也可能是自动化相关bug。
其中软件bug会提在现有的重构TD库中，而自动化的bug并没有记录。
现在增加一套自动化的TD库，可以记录自动化相关bug（服务器复现而本机不复现问题），并定期改掉这些bug。
【缺陷管理目的】1.提出的软件bug，作为度量报告有效率的指标2.记录下服务器复现的问题，以便定期做出修改3.统计并分析服务器复现问题产生的原因，找到解决办法，提高自动化脚本质量【整体流程】（参见下面的流程图）I.每份自动化报告，按照既定原则（即规定的或临时分配的），某成员负责整个报告或其中一部分报告的分析。
II.需要自己分析的报告，如果发现了软件bug，则提软件bug；如果此报告是通性报告，并且是非一次性报告，在本机运行不复现后，则提bug。
分析报告的人即为记录bug的人。
（注：一次性报告是在某个时间段只运行一次的版本报告，如临时版报告；而非一次性报告是在某个时间段内运行多次的版本报告）III.软件bug1.发现软件bug后，首先判断软件bug是通性问题还是特性问题2.通性bug可以选择一个即将发版的地区来提，这样可以很快改掉3.特性bug则提在该地区注意：(1)提bug的位置：同软件手工测试提出bug的位置（目前为TD库，网址为http://server-pmc/tdbin/start_a.htm，Project选择GBQ_Rebuild_Main），测试阶段选择自动化(2)提出bug后，如果此bug阻塞自动化，则给相关负责人发邮件，注明bug id号并且说明影响自动化（如果不影响自动化，可以只提出bug，后续由大区人员跟踪）(3) bug负责人（即发邮件的对象）：需求问题由需求人员负责，数据问题由数据人员负责，软件问题由大区开发负责人负责自动化bug当报告为通性、非一次性报告并且本机运行不复现后，则由分析报告的人提出bug，流程如下：1. 提出bug，状态为默认为new,并置服务器复现次数字段为第一次。
缺陷bug的管理流程
缺陷bug的管理流程嘿，朋友！咱今天来聊聊缺陷 Bug 这让人头疼的家伙，还有怎么对付它们的一套流程。
你想想，缺陷 Bug 就像隐藏在暗处的小怪兽，时不时跳出来捣乱，让我们的工作或者生活变得一团糟。
那可不能让它们肆意妄为，得有一套办法把它们管得服服帖帖！首先呢，发现 Bug 就像是猎人寻找猎物的踪迹。
这可得有一双敏锐的眼睛，不管是在软件运行的时候，还是在各种数据的细枝末节里。
就像侦探在案发现场寻找蛛丝马迹一样，不能放过任何一个可疑的地方。
发现了 Bug 之后，那得赶紧详细记录下来。
这记录啊，就好比给小怪兽画像，要把它的模样、行为特点、出现的时间地点，都描绘得清清楚楚。
要不然，怎么能让后面处理它的人心里有数呢？接下来，得给 Bug 分分类。
是小打小闹的，还是能引起大麻烦的？这就像给病人看病，得分清是头疼脑热，还是大病重疾。
不同的级别，处理的紧急程度可不一样。
然后呢，就得把 Bug 分配给能收拾它的人。
这就像给战士分配战斗任务，得找对人，才能把这小怪兽一举拿下。
在处理 Bug 的过程中，那得不断跟进。
就像盯着锅里煮的汤，时不时瞅瞅，别煮糊了。
看看处理的进度怎么样，有没有遇到新的问题。
处理完了可不算完，还得复查。
这就像打扫完房间要检查一遍，看看有没有遗漏的角落。
确保这个Bug 是真的被解决了，不会死灰复燃。
整个过程中，沟通可是至关重要。
大家得像一个团队一样，齐心协力，有问题及时说，有想法大胆提。
不然，就像一群各自为战的士兵，怎么能打胜仗呢？你说，要是没有这么一套清晰的管理流程，那面对缺陷 Bug 还不得手忙脚乱？所以啊，咱们得重视这个流程，把每一个环节都做好，让那些讨厌的 Bug 无处可逃！总之，缺陷 Bug 不可怕，只要咱们有一套行之有效的管理流程，就能把它们治得服服帖帖，让我们的工作和生活更加顺利！。
BUG描述及缺陷管理工具培训课件
Bug统计3
•各 Bug解决平均工作日
PPT文档演模板
•1. 一 bug (blocker, critical) （平均 1 天） •2. 二 bug (major, normal) （平均1.29天） •3. 三 bug (minor, trivial) （平均2.20天） •4. 四 bug (enhancement) （平均2天） •注： LATE状 的 不在 之列
PPT文档演模板
BUG描述及缺陷管理工具培训
Bug的生命周期
Bug的生命周期就是指Bug从开始提出到最后完全 解决，并通过复查的过程。在这个过程中Bug报告 的状态不断发生着变化，记录着Bug的处理进程。
PPT文档演模板
BUG描述及缺陷管理工具培训
PPT文档演模板
BUG描述及缺陷管理工具培训
有效描述Bug
BUG描述及缺陷管理工具培训
BugZilla操作指南1
•注册、登陆 •用户输入服务器地址：http://192.168.0.16/bugzilla/，进入 主页面后，点击“登陆”。
PPT文档演模板
BUG描述及缺陷管理工具培训
BugZilla操作指南2
修改密码 进入主页面，点击“设置”。
PPT文档演模板
• 短小：只解释事实和演示、描述Bug必需的细节； • 单一：每一个报告中针对一个Bug； • 步骤清晰：要清楚地描述出Bug的发生场景，包括前置条
件和操作的详细步骤；
• 再现：按照预定步骤可以重现相同状况； • 在报告Bug时只描述事实，不做评价，也不要有人身攻击； • 必要的时候可以添加注释（remarks）； • 可以上载屏幕抓图和其他附件。
• 更重要的是它还记录着Bug的处理过程和状态。Bug的处理
缺陷管理Bug状态流程图说课讲解
缺陷管理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. 定期整理By Design其它⼀些字段（及所定义的枚举值）的定义解释，供有需要⽤到的组参考：测试状态（TestState）：新提交的Bug定位标准。
软件测试缺陷管理流程图
缺陷管理流程图是为了有效的跟踪，管理bug的处理情况，指导测试团队和开发人员有效的处理相关的bug。
不同角色的人，对bug处理的权限不一样，我们需要借助类似缺陷管理工具比如：QC进行实施。
下面就不同角色的人主要的只能进行简单说明：
测试人员：提交bug，并对修复的bug进行审核；
测试组长：审核bug，并将bug提交给开发组长；
开发组长：将确认正确的bug分配给相应的开发人员；
开发人员：修复开发组长分配的bug。
具体的测试流程，请参见图1 缺陷管理流程图：
每个状态表示的具体含义说明如下：
不断的总结，才能不断的提高；不断的思考，才能不断的进步！。
缺陷管理流程(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会根据申请人的角色开放操作权限
缺陷管理流程说明剖析
苏宁易购缺陷管理流程错误！未找到引用源。
错误！未找到引用源。
文档记录修订记录批准者此文档需要以下人员批准分发此文档分发给以下部门或单位相关人员：目录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缺陷根源缺陷根源可用于对测试过程中所发现的缺陷进行根因分析，识别根本原因，并按照度量结果采取有针对性的解决方法和改进措施。
- 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尽快解决。