《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 偶发性 原来修改过的问题又重新出现 需求要求但没有做的功能 需求需要完善 与需求不一致 设计要求但没有做的功能
Jira上Bug处理流程
J i r a上B u g处理流程内部编号：（YUUT-TBBY-MMUT-URRUY-UOOY-DBUYI-0128）J i r a上B u g处理流程第一章LIT的Jira上问题处理流程具体处理流程如下：1、LIT测试过程中发现问题，在JIRA上新建Bug，分配Bug给相关Team组长，Bug为Open状态；2、组长接收到邮件通知后，将Bug分配给相应开发人员，Bug保持Open状态；3、开发人员接收到邮件通知后分析问题，若需要修改将Bug状态改为In progress；若不需要修改直接将Bug状态改为Resolved(Won't Fix )；4、开发人员修改Bug完毕后，将Bug状态变更为Resolved(Fixed)；5、LIT对状态为Resolved的Bug进行验证，若验证通过，将Bug状态改为Closed，若验证不通过，将Bug状态改为Reopen；6、对于Reopen状态的bug，重新按上面3-5步骤进行处理，直至问题Closed；7、对于Open或Reopen状态的Bug若是暂时无法解决可以采取挂起的方式，修改Bug为Resolved状态，并设置解决方式为Pending。
第二章 SIT的Jira上问题处理流程SIT的Jira上问题处理流程分为早期版本和新版本（将来版本）两种，对于新版本的流程在Jira上有单独标识，没有标识的即为早期版本。
两种处理流程有所差异。
2.1 早期版本处理流程1、SIT测试过程中发现问题，在JIRA上新建Bug，分配Bug给相关Team组长，Bug为Open状态；2、组长接收到邮件通知后，将Bug分配给相应开发人员，Bug保持Open状态；3、开发人员接收到邮件通知后分析问题，若不需要修改直接将Bug状态改为Resolved(Won't Fix)；若需要修改，在Bug修改完毕后，将Bug状态改为In progress；4、LIT对In Progress状态的Bug进行验证，若验证通过，将Bug状态改为Resolved（Fixed），若验证不通过，将Bug状态改为先Resolved，然后再改为Reopen（受Jira定义的业务流程限制只能按照这种方式来Reopen）；5、SIT对Resolved的Bug进行验证，若验证通过，将Bug状态改为Closed，若验证不通过，将Bug状态改为Reopen；6、对于Reopen状态的Bug，重新按上面3-5步骤进行处理，直至问题Closed；7、对于Open或Reopen状态的Bug若是暂时无法解决可以采取挂起的方式，修改Bug为Resolved状态，并设置解决方式为Pending。
BUG处理流程规范
BUG处理流程规范1. 1目的提高测试以及产品缺陷修改效率，避免出现搁置和遗漏的缺陷，从而提高产品的质量，降低质量检查和缺陷修改成本1. 2适用范围适用于研发部门（Confernece、Flash、监控），质量保证部门1.3 定义bug：通过测试检查出的产品缺陷；新建、打回、已确认、已指派、已解决、已关闭：测试中bug的不同状态，详细信息见本规范第3部分；1. 4参考资料无2 BUG提交和处理规范说明1、在测试人员提交bug的时候，必须对bug信息进的描述必须详细全面、清晰明确，如果有条件，需要描述使用的环境，在BUG出现前的具体操作，如果抓图，必须抓取jpg全屏图象，但不能使用BMP格式上传到BUG库中，有抓包文件需要上传BUG库，空间不够需要放到\\\\192.168.0.254\\qa\\测试\\bug日志目录中，标题以BUG号区分；2、在测试人员提交bug的时候，必须按具体情况，填写重要级别、出现频率、优先级别三个栏目，而非测试人员不得对上述信息进行直接改变，如觉得这三个信息填写不恰当，可以在该bug下的注解中提出意见，并“打回”给bug提交人员或质量部经理处，经过确认后修改；3、开发人员对bug进行处理后的变更状态成“打回”时，或“指派”给产品部门时以及变更成“已确认”时必须进行必要的描述和说明,在状态变更时，必须要指定具体接收人；4、开发人员在注解中描述该BUG计划什么时候解决或做其他阐述的时候，要明确写清承诺的具体版本号，禁止使用“上一版本”、“本版本”、“下一版本”等字样，以免造成误会或混淆；修改完成的BUG注释中加入相关的确认信息，如“XXX Review并通过。
5、如果已经是“关闭”状态的BUG，测试人员在后期测试中又出现了需要重新打开，重开后的BUG状态为“打回”，测试人员需要再多一个操作，即“指派”给具体的研发人员。
6、一直处于“打回”状态的BUG，测试人员需要经过两轮（即两个版本）测试后仍然没有重现的，可以关闭。
Bug处理流程
杭州家和物联技术有限公司附件2：Bug 处理流程Bug 处理流程市场客服产品测试继续处理研发测试报告填写缺陷与限制，bug 入库，设置状态New研发对提交的Bug 进行重现、评估Bug 收集整理邮件抄送邮件发送Bug 处理判定为无效Bug ，在反馈的测试报告上状态设为Invalid否在JIRA 上创建问题，状态设置为”开始“是判定为拒绝修改或搁置的Bug 测试、产品研发讨论是否搁置是Bug 是否解决JIRA 平台将问题状态设为”已解决“测试测试报告中设Bug 状态为解决是测试报告中将Bug 状态设为Wontfix 并注明原因否缺陷与限制邮件反馈验证Bug 是否修正缺陷与限制邮件反馈是在JIRA 平台上将对应问题状态设为“重新打开”否定期跟踪关注未解决的Bug继续解决JIRA 平台相问题注释进度。
测试报告中设Bug 状态为未解决测试报告中将Bug 状态设置为close否报告Bug ，填写描述情况。
紧急bug 的处理综合技术的Bug 处理结果，更新缺陷与限制分表在JIRA 平台上将对应问题状态设置为“关闭”Bug 管理邮件抄送回复客户反馈流程说明：1、 测试员提交的测试报告缺陷与限制分表将新的Bug 入库，错误状态为New 。
2、 测试员将测试报告发送给相应的开发人员并抄送给产品。
3、 研发对测试报告的缺陷与限制分表中的bug 进行评估反馈。
4、 对于测试报告提交的无效Bug ，研发在表格上其状态置为Invalid 。
5、 对于测试报告提交的Bug ，研发拒绝修改或搁置不改的在表格上设置为Wontfix 。
6、 对于测试报告提交的普通Bug,，研发在JIRA 问题管理平台上创建相关条目，并开始处理，该问题状态为开始，研发修复Bug 后，在平台上将其状态设置为已解决。
7、 对于不能修改或者建议不修改的问题，及时反馈给测试和产品，经讨论决定后，才能置为暂时不修改Wontfix 。
8、 测试员在JIRA 问题管理平台上查询状态为已解决的Bug ，然后验证Bug 是否已解决，如解决则将测试报告缺陷与限制分表中设置Bug 的状态为Close ，如没有解决则让研发在JIRA 问题管理平台上将Bug 状态设置为重新打开。
产品上线后，出现BUG的处理流程
产品上线后，出现BUG的处理流程
1. 根据bug的⼤⼩，如果影响业务逻辑及⽤户提醒及时处理，如果只是⼀些状态、⽂案等等对业务⽆重⼤影响可以跟版本迭代⾛
2. 很严重的bug必然要回滚，想都不要想赶紧去着⼿安排做。
3. 检查回滚版本是否会丢失数据，如果危害⼩可以让⽤户⾃⼰决定是否忽略（推送告知⽤户会丢失哪些数据⼀般说「部分数据」），如
果危害⼤，替问题⽤户保存好数据并告知⽤户不要轻易回滚。
4. 配合开发及测试⼈员，快速定位bug，并且锁定影响范围。
5. 做好备份，及时发出上线公告，产⽣bug的功能暂且不上线，其他功能继续上线。
6. 上线成功后，做⼀个上线总结，后续action。
bug处理流程图
卮佳倀匞exj
凕侗咲仼
否
凕 否 1、操作人员：bug提交人 2、职责：验证bug及相关功 能 3、注意事项： 3.1注意相关功能（可与研发 沟通修改可能影响的内容） 3.2未通过后激活bug为active 状态，指回给bug处理人 3.3关闭bug（无法重新等bug 可暂时保留不关闭） 亿倂儔伱
嘌哆exj
冁乭exj 是
劥响哫哭乷即咹 exj 是
凕侗伏啲亿倂
否
是否有效
凕
厸伒伏啲exj 1、操作人员：功能研发人员或者根据 项目制定的人员（翻译等） 2、职责：解决修复bug 3、注意事项： 3.1新功能开发完成后在提交测试前先 进行自测，尽量保证冒烟测试不会有 太多问题（非bugfree流程） 3.2解决bug依照优先级和严重性来解 决（1到4依次降低） 3.3不能修复的bug说明原因反馈给策 划（bug状态保持active）来处理 3.4bug的注释内容（解决方案、代码 修复后更新的预期时间和服务器） 3.5客户端和服务器端bug的处理流程 按照研发内部流程和沟通方式即可 3.6bug重现或者定位所需的各种信息 可直接与bug提交人交流获取
1、操作人员：问题或者bug 发现人，一般是测试人员（没 有权限的人员可将bug或问题 转交给测试进行创建） 2、职责：编写bug到bugfree 3、注意事项：提交bug步骤 规范、有截图和相关必要信息 备注：该内容依照测试部内2、职责：对bug进行筛选和 处理 3、注意事项：主要针对bug 有效性（是否重复等类bug） 和bug信息内容检查和筛选
是否有效
否
凕侗伏啲亿倂
凕
侗
1、操作人员：策划负责人（项目制定 ug分配人） 2、职责： 2.1将bug分配给具体的程序研发人员（ 或者程序bug接口人）； 2.2-对bug进行判断和筛选 3、注意事项： 3.1对于其中有效性（设计如此、不必 修复、以后修复等类bug）进行筛选 3.2设计如此、不必修复和以后修复类 的bug都需要有策划来处理和确认 3.3一些bug需要添加修改方案和信息（ 比如提示信息错误那么应该给出正确的 提示信息） 3.4需要处理来自研发反馈的不能修复 的bug 3.5一些bug需要添加具体的预期结果（ 比如给出合适的游戏提示）
Bug处理规范
Bug处理规范目录Bug处理规范 (1)目录 (1)1目的 (2)2适用范围 (2)3 Bug处理流程 (2)4研发中心相关活动定义 (3)4.1研发中心Bug (3)4.1.1新建 (3)4.1.2关闭 (4)4.1.3 Reopen (5)4.1.4已知问题 (6)4.2研发中心Bug (7)4.2.1验证通过 (7)4.2.2验证不通过 (8)5研发中心相关活动定义 (9)5.1测试的Bug (9)5.1.1转移/分配 (9)5.1.2接受 (10)5.1.3打回 (11)5.1.4解决 (12)5.1.6挂起 (13)5.1.7已知问题 (14)5.2研发中心的Bug (15)5.2.1转移/分配 (15)5.2.2接受 (16)5.2.3打回 (17)5.2.4解决 (18)5.2.5挂起 (19)6研发中心相关活动定义 (20)6.1新建 (20)6.2关闭 (21)参考 (23)1严重程度的定义 (23)2挂起的标准 (23)3打回的标准 (23)1目的本文档规范了测试人员、工程人员、研发人员如何对公司Bugfree系统中的缺陷进行处理的规则，涉及Bug的各个活动。
所有人员应严格遵循本规范所制定的规则，对Bug进行及时地、规范化地处理。
本规范会根据施行过程中发现的问题不定期进行修正，修正结果将及时公布。
2适用范围本文档是指导测试人员、工程人员、研发人员进行Bug处理时的指导性文档，适用于研发中心所有人员进行Bug处理。
3 Bug处理流程4研发中心相关活动定义4.1研发中心Bug4.1.1新建注意点1、Bug标题：需要简明扼要的说明问题所在。
2、当优先级选择了“指定时间内解决”，请填写“指定日期”。
3、复现步骤中，“步骤”中填写问题重现的具体步骤，“结果”中填写执行的实际结果，“期望”中填写执行的预期结果。
4.1.2关闭4.1.3 Reopen4.1.4已知问题4.2.1验证通过4.2.2验证不通过5研发中心相关活动定义5.1研发中心的Bug5.1.1转移/分配5.1.2接受注意点：1、处理原因：研发人员初步判断Bug的产生原因；5.1.3打回注意点：1、处理原因：当选择已经发现后，必须填写重复Bug；5.1.4解决注意点1、当这个Bug不是总是出现的，请研发人员在注释中描述如何才能每次重现。
BUG处理流程
BUG处理流程
1. 测试人员发现并提交一个BUG，此时BUG的状态为新建（NEW）状态，新增的BUG都提交给项目经理。
2. 项目经理确认是一个BUG后，将BUG的状态置为打开（OPEN）状态，并修改优先级，然后指定研发人员进行修复，并指定预修复时间。
3. 开发人员修改该BUG后，将BUG的状态变为已修复（FIXED），待系统BUG修复完成后，形成一个新的版本提交给测试人员。
4. 测试人员对新版本进行回归测试，如果该BUG确实已经修正，则将GUG状态修改为已关闭（CLOSDE）状态，如果仍有问题，则修改为重新打开（REOPEN）的状态，需要开发人员继续修改该项BUG。
上面是最基本也最常用的处理流程，在实际中我们还会有一些特殊情况，如：
1、如项目经理或开发人员认为测试人员提的某一个BUG不是问题，则修改状态为拒绝（REJECTED）状态，请一定加上注释说明。
2、如果有BUG开发人员采用延后处理的，开发人员在注释中要注明延后到什么时间进行处理，测试人员要进行跟踪。
3、如果项目经理不在，必须指定一位开发人员处理新增的BUG，原则上，新增BUG修改为其他状态的时间不能超过一周。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
BUG处理流程说明
一、B UG处理流程图：
流程描述：
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，以免其被漏掉或遗忘从而影响到项目上线。
三、缺陷严重级别及类型定义
◆致命错误包括：
1．造成系统崩溃、死机
2．造成程序非法退出、死循环、通讯中断或异常
◆严重错误包括：
1.功能不符
2.数据流错误
3.程序接口错误
4.密码明文显示
◆一般错误包括：
1.界面错误
2.打印内容、格式错误
3.输入限制未放在前台进行控制
4.删除操作未给出提示
5.辅助说明描述不清楚
6.显示格式不规范
7.长时间操作未给用户进度提示
◆建议（非缺陷）
1．修改后可获得更好的用户体验
四、缺陷优先级定义
1、高：导致测试暂停，无法进行；必须立即解决，优先级高于开发工作。
2、中：导致部分功能无法测试；需要优先解决，解决周期2天。
3、低：不影响测试的进行；可在方便时解决，解决周期3-5天。
五、必须注意的问题
1.开发人员不能直接关闭bug，关闭bug必须由测试人员完成。
2.在进行问题处理的时候必须要添加注释，描述不是问题的原因、以后解决的计划
版本时间等等。
3.大家在处理自己的问题时，即使这个问题不是自己的程序引起，也最好不要把问
题置之不理，因为这个问题是在你这块表现出来的，到底哪里出问题应该比较清
楚，跟其他相关人沟通相对比较容易，这样可以降低沟通成本，劲量做到“首位
责任制”或“问题到此为止”
六、禅道使用说明
1、禅道地址：http://172.21.39.42/www/index.php
2、测试人员提交bug
登录成功后，选择测试试图，然后从下拉列表中选择项目，进入对应项目。
点击创建bug，进入bug编辑界面。
选择bug影响版本、当前指派人、输入bug标题和bug重现步骤。
选择bug类型及严重程度、选择bug出现的系统及浏览器、抄送给项目负责人或其它相关人员、插入bug截图，点击保存bug提交完成。
3、开发人员处理bug
开发人员登录系统后，点击测试试图下的缺陷管理，选择自己所在的项目，进入相关bug页面，发现有指派给自己的bug，点击bug标题，进入bug详细描述。
在浏览bug重现步骤定位bug后，进行bug的修改，bug处理完成后点击解决，进入下一步。
如果认为该bug不是问题，也点击解决，进入下一步处理。
如果bug修改完成，解决方案选择已解决；如果认为不是bug，请选择设计如此；
如果bug没有重现，请选择不能重现；如果确实bug但近期内无法解决，请选择延迟处理；如还有其他问题，请选择所对应的解决方案。
填写备注信息，以说明bug处理情况。
点击保存，完成bug修改流程。
4、测试人员验证bug
测试人员登录系统后，发现指派给自己的bug，点击bug进入bug详细描述。
查看bug解决方案及bug状态，如果为已解决，则验证bug是否确定修改，如果修改完成，点击关闭，如果bug没有修改正确，点击激活重新打开bug。
如果bug状态为无法重现，则需要自己重现bug，如确实无法重现，关闭，如果可以重现，激活并与开发人员沟通或现场演示bug的重现。
如果为其他状态，请与开发人员协商解决。