《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修改为其他状态的时间不能超过一周。
bug处理流程
bug处理流程一、bug的定义和分类。
1. 什么是bug？在软件开发中，bug指的是程序中存在的错误、缺陷或者导致程序无法正常运行的问题。
bug可能会导致程序崩溃、功能异常、性能下降等各种问题。
2. bug的分类。
根据bug的影响程度和紧急程度，可以将bug分为严重bug、一般bug和轻微bug。
严重bug指的是影响系统整体功能的bug，一般bug指的是影响单个功能或模块的bug，轻微bug指的是影响用户体验但不影响系统功能的bug。
二、bug处理流程。
1. bug的发现。
bug的发现可以通过测试、用户反馈、日志分析等方式进行。
测试人员在测试过程中发现的bug需要及时记录并报告，用户反馈的bug也需要及时收集并确认。
2. bug的记录。
一旦bug被发现，需要及时记录bug的详细信息，包括bug的描述、复现步骤、影响范围、截图、日志等信息。
同时，需要为bug分配一个唯一的标识符，方便跟踪和管理。
3. bug的确认。
确认bug的真实性和重现性是非常重要的，开发人员需要根据记录的信息尝试复现bug，并确认bug的存在。
如果无法复现，需要与测试人员或用户进行沟通，以确定bug的真实性。
4. bug的分析。
一旦bug被确认，需要对bug进行分析，找出bug的根本原因。
分析bug的原因有助于避免类似bug的再次发生，提高软件质量。
5. bug的修复。
在分析完bug原因后，开发人员需要及时修复bug，并进行相应的单元测试和集成测试，确保bug被彻底修复。
6. bug的验证。
修复bug后，需要由测试人员进行验证，确认bug是否被彻底修复，以及修复bug是否引入了新的问题。
7. bug的关闭。
一旦bug被验证修复成功，需要将bug状态设置为关闭，并记录bug的处理过程和结果。
同时，需要通知相关人员bug的处理情况。
三、bug处理流程的优化。
1. 自动化测试。
通过引入自动化测试工具，可以加快bug的发现和修复速度，提高bug的处理效率。
bug的处理流程
bug的处理流程又属于一篇普及文，希望自己在被各种技术吸引的同时，能时常来整理和总结软件测试最基本的知识。
从刚工作时接触的第一个缺陷管理工具禅道，到redmine、JIRA、bugzilla ，再到现在的QC，当然还有其它种的开源的或商业的缺陷管理工具，它们的本质是一样的，就是来管理缺陷的生命周期。
其实，你理解任意的一款工具，其它的工具也一定能无师自通。
这不谈某款工具，单把它本质的一些东西抽离出来与大家分享。
Bug的属性Bug重现环境这个应该是我们重现bug的一个前提，如果没有这个前提，我们可能会无法重现问题，或者跟本就无从下手。
操作系统这个是一般软件运行的一大前提，基本上所有的软件都依赖于操作系统之上的，对于一个软件来说，要想在某个操作系统上运行，必须要对这个操作系统支持，这就需要有真对性的设计与开发。
对于不同的操作系统，其可能存在差异（如：win xp 与 win 7）或本质的区别（如 win 7 与 CentOS linux ），所以，操作系统环境是重现问题的一个重要前提。
浏览器对于B/S系统，或面向大众的互联网产品（网站，邮箱等），浏览器的兼容性也是必须测试的一个重点，对于现在的浏览器市场，各式的浏览器都有其用户群，要想使产品大众化，必须考虑这些产品的兼容性问题。
不同的浏览器之间（IE、 firefox、chrome、opera 等），甚至同一系列不同版本（ie6/ie7/ie8/ie9等）都可能存在兼容性问题，所以，对于这类应用，浏览器环境重现bug前提条件之一。
其它（这个“其它”非常重要）对于不同的系统发现重现问题，都会有其特定的前提，拿我测试的邮箱来说，必须要描述其是在测试线还是现网环境，而且还要附带一重现问题的帐号等。
对于c/s软件，可能还要考虑与其它常用软的兼容等，例如，是在安装的某款软件后，对本软件的安装和使用造成影响。
这些都是重现问题的必须描述的环境。
问题类型根据JIRA的管理系统的划分，bug 只是问题的一种，它可以用于跟踪多种不同类型的问题（其实，他只是将bug做为一子类而已）。
bug处理流程
Bug处理规则1、每一个Bug，开发在修复（Fixed）或者拒绝（Rejected）后，都需要给出一个注释，添加注释之前，需先点一下“添加注释”的按钮，如下图所示，这样添加注释人员的名字就会出现，否则，添加注释的人多了，不知道是谁写的。
具体注释的内容（产生bug原因，修改的地方）是由各个组自己跟开发约定。
2、在Bug处理过程中，如果一个Bug开发方认为A、当前不能做，或者需要延迟开发；B、就应该是这样的，不是Bug遇到这两种情况时，Bug状态可以改为Rejected，同时需转发（Assigned&To）该Bug给项目经理进行确认，项目经理需要对此Bug做一个说明（加一个注释），测试人员根据项目经理的解释决定这个Bug的最终状态。
3、Bug状态的转换：以下几类问题不可以被Rejected回来，一旦发现开发把下列问题Rejected回来，我们不可以直接closed掉，要根据实际情况做出Reop en或Deferred处理。
1)、环境配置问题2)、数据问题3)、历史问题4)、需求问题只有因为我们理解的偏差导致的不需要任何修改，客观上本来就是正确的Bug才可以直接closed掉。
4、Comment问题：除open和closed两种状态可以不加注释外，其它任何的状态改变都要加上注释说明。
5、Deferred问题处理：测试人员需评估deferred的风险，线下跟项目经理和项目测试负责人（或是导师）review。
a)几方讨论都同意deferred：QA应把bug指派给项目经理，项目经理在“Comm ent”中加上注释，对此bug的处理解决方案；然后ＱA把此bug为deferred状态，并说明。
b)几方讨论不同意deferred此bug：ＱＡ需reopen此bug给开发人员。
c)小需求中的bug要deferred，流程和处理方式同项目deferred处理。
d）项目结项后，项目组需要在2周内完成项目Deferred&Bug的修复计划，并按照计划进行修复；如果未能按照计划修复的Deferred&Bug按照Deferred&Bu g处理流程处理。
某知名软件公司程序BUG处理流程
客户BUG处理流程
一、目的：制定客户BUG处理的规范，达到多部门协同作业的目的。
二、流程图：
m
o
c
.
a
f
d
n
a
三、具体职责说明：
A.实施部：
1.接到客户BUG后，分析问题是否客户误操作而产生的，如果是因为客户的误操作
产生的BUG，由实施部对应服务人员给客户提出正确的操作方法。
2.如果不是客户错误操作，确定客户使用的数据库和程序公司是否与公司测试环境一
致，如果一致登记JIRA问题，交测试组处理。
3. 如果不一致，由实施部对应服务人员联系客户取得客户最新的数据库及程序，交测试组测试时使用。
4. 收到测试组交来的修改后程序后，确认是否已修改客户BUG ，确认已修改，给出更新文件通知客户升级。
5. 如果没有修改，退回测试组，重新测试。
B. 测试组： 1. 收到JIRA 问题后，进行问题测试，找到问题发生的原因交编码组修改。
2. 测试编号组修改好的程序，如果已修改完成，交实施部测试。
3. 如果没有修改完成退回编码组重新修改。
C. 编码组： 1. 根据测试组测出的问题原因修改程序，给出修正后程序。
安达发a n d a f a .c o m。
Mantis bug处理流程
测试人员 已解决 重新打开
测试人员 已关闭的 问题 状态 动作 已关闭 重新打开
重新打开 分派问题 状态 动作
开发人员 已分派 解决问题
解决问题 完成度： 已修正 状态 动作
测试人员 已解决 确认是否已修正 No:打回问题 开发人员 状态 动作 打回 解决问题
Yes
关闭 问题
解决问题
完成度： 已修正
测试人员 已解决 确认是否已修正
解决问题 完成度： 已修正 状态 动作
开发人员 打回 解决问题
Yes：
解决问题 完成度： 未处理、 无法修复、 不做修改
测试人员
状态 动作 新建 报告问题
新建、 分派问题
开发人员
状态 动作 已分派 分析问题， 需要项目 经理确认 分派问题 状态 动作
项目经理 已分派 是否同意
测试人员 状态 动作 已解决 关闭问题
No: 打 回 问 题
Yes
关闭问题 状态 No: 打 动作 回 问 题
测试人员 已解决 确认是否已修正
解决问题 完成度： 已修正 状态 动作
开发人员 打回 解决问题
关闭问题
测试人员
状态 动作 新建 报告问题
新建、 分派问题
开发人员
状态 动作 已分派 暂停问题， 需要项目 经理确认 分派问题 状态 动作
状态 新建 打回 已分派 已解决 已关闭
完成度
可否结束对应 × × × × ○
项目经理 已分派 是否暂停
Yes： 解决问题 完成度： 暂停
暂停问题
No: 打 回 问 题
状态 重新打开， 分派给开 发人员 动作
一旦不再 受限，重 新打开
Yes
关闭问题 状态 No: 打 动作 回 问 题
《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处理流程规范
BUG处理流程规范在软件开发过程中，难免会出现各种各样的bug。
为了高效地处理bug，并确保软件质量，需要制定一套规范的处理流程。
以下是一个合理的BUG处理流程规范，主要分为以下几个步骤。
1. Bug的报告和记录在软件开发过程中，任何人都可以发现和报告bug。
当有人发现bug 时，需要及时记录并创建一个bug报告。
bug报告需要包含以下信息：- Bug的描述：清晰明确地描述bug的现象和影响。
- Bug的重现步骤：明确描述如何重现bug，以便开发人员能够复现和定位问题。
-系统环境信息：记录操作系统、浏览器版本等信息，以便开发人员能够排查问题。
-附加信息：可以提供截图、日志等附加信息，以辅助开发人员分析问题。
2. Bug的分类和优先级确定开发人员需要对收到的bug进行分类和优先级确定。
分类可以按照bug的类型、影响范围等进行，如功能性bug、性能bug、界面bug等。
优先级可以根据bug的紧急程度和影响程度进行确定，一般分为高、中、低三个级别。
3. Bug的分析和复现开发人员需要根据bug报告中提供的重现步骤来分析和复现bug。
在分析过程中，开发人员需要仔细研究bug的产生原因和可能的解决方案。
在复现过程中，开发人员需要按照报告中提供的步骤来操作，并确认bug 的现象是否和报告中描述的一致。
4. Bug的修复当开发人员确认bug的存在并定位到问题的根本原因后，就需要进行修复。
在修复过程中，开发人员需要遵循一些原则：- 先修复重要bug：优先修复对系统功能、性能、安全等重要方面有影响的bug。
- 一次只修复一个bug：避免同时修复多个bug，以免引入额外的问题。
- 编写测试用例：在修复bug之后，开发人员需要编写测试用例来验证修复是否有效。
5. 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的重现。
如果为其他状态，请与开发人员协商解决。