《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处理流程规范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，测试人员需要经过两轮（即两个版本）测试后仍然没有重现的，可以关闭。

杭州家和物联技术有限公司附件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的处理流程
1. 根据bug的⼤⼩，如果影响业务逻辑及⽤户提醒及时处理，如果只是⼀些状态、⽂案等等对业务⽆重⼤影响可以跟版本迭代⾛
2. 很严重的bug必然要回滚，想都不要想赶紧去着⼿安排做。

3. 检查回滚版本是否会丢失数据，如果危害⼩可以让⽤户⾃⼰决定是否忽略（推送告知⽤户会丢失哪些数据⼀般说「部分数据」），如
果危害⼤，替问题⽤户保存好数据并告知⽤户不要轻易回滚。

4. 配合开发及测试⼈员，快速定位bug，并且锁定影响范围。

5. 做好备份，及时发出上线公告，产⽣bug的功能暂且不上线，其他功能继续上线。

6. 上线成功后，做⼀个上线总结，后续action。

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处理流程
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的定义和分类。

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的处理流程又属于一篇普及文，希望自己在被各种技术吸引的同时，能时常来整理和总结软件测试最基本的知识。

从刚工作时接触的第一个缺陷管理工具禅道，到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处理规则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处理的规范，达到多部门协同作业的目的。

二、流程图：
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。

《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处理流程规范，主要分为以下几个步骤。

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后，需要进行验证和确认。

验证是指开发人员按照之前编写的测试用例进行测试，确认修复是否有效。

确认是指由报告人或测试人员再次测试，确认修复是否完全解决了问题。