下载文档原格式
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 由测试人员发现并上报，最终状态还要落回到测试人员。
说明：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处于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中解决方案。
缺陷管理过程中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所属模块是属于那个研发人员，并把问题指派给他（如果不知道，就直接提交给该负责人）。
状态流程图：软件错误的状态新信息(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 票状态
对应人
邮件默认形式通知。
缺陷管理流程【背景】缺陷管理流程背景：自动化报告存在失败或错误的问题，出现这些问题的原因可能是软件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优先原则，严重程度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尽快解决。
