禅道BUG提出及处理流程规范

版本说明
版本作者时间备注
1.0 _冷冷 2019/9/27 首版本提交

目录
1 概述 1
2 目的 1
3 作用 1
4 缩略词 1
5 适用范围 1
6 BUG的定义 2
7 BUG书写规范 2
7.1 BUG书写必填内容 2
7.2 BUG书写注意事项 2
7.3 BUG关键信息释义 2
8 BUG处理流程 5
8.1 BUG生命周期 5
8.2 BUG解决方案 5
8.3 BUG回归 6
8.4 BUG处理流程图 7
8.5 遗留BUG跟踪 7
8.6 BUG分析 8

1概述

本文档规范bug的提出及管理流程，定义BUG的整个生命周期。帮助测试、研发等人员了解BUG的处理流程。提高测试人员工作效率以及产品缺陷修复效率，避免出现搁置和遗漏的缺陷，从而提高产品的质量，降低质量检查和缺陷修改成本。

2目的

清晰简单描述好问题，编写有效的BUG，可以帮助开发人员快速有效的进行问题定位，重现问题，从而快速有效的修改问题，提高测试效率。

3作用

可以提高开发人员修复BUG的效率；
可以降低开发人员的二次BUG率；
可以提高其他部分对测试部门的信用度；
可以增加开发与测试的协作力，有效提高产品的质量。

4缩略词

无

5适用范围

研发、测试、产品人员。

6BUG的定义

BUG是一个英文单词，本意是指昆虫、小虫、损坏、犯贫、缺陷、窃听器等意思。现在一般是指在电脑系统或程序中，隐藏着的一些未被发现的缺陷或问题，简称程序漏洞。

7BUG书写规范

7.1 BUG书写必填内容

创建BUG需要填写以下关键信息：所属产品（必填）、所属项目（必填）、所属模块（必填）、影响版本（必填）、当前指派（必填）、截止日期、BUG类型（必填）、操作系统、浏览器、BUG标题（必填）、严重程度（必填）、优先级（必填）、BUG内容（必填）、相关需求、相关任务、抄送人员、关键词、附件，未标红的选项可根据实际情况酌情填写。

7.2 BUG书写注意事项

书写BUG时尽量遵循以下规则：
1）BUG必须标注：严重等级、优先级别并准确表述出问题内容及所在模块等，方便研发等人员快速定位问题并有序解决问题；
2）BUG标题：要以一个准确简练的句子描述某个模块存在的问题，或者某个操作导致了什么问题；
3）BUG内容：针对不同的原因导致的问题要包含对应的原因，例如手机的品牌、操作系统或者是浏览器名称、版本等；
4）BUG内容：常规BUG内容中要包含：操作步骤、实际结果、预期结果，语言要清晰准确；
5）BUG内容：若为特殊数据造成的问题，需提供具体测试数据；
6）兼容性问题需在两个以上环境中确认BUG再进行提交；
7）非必现BUG需进行10次以上测试，标注问题出现概率；
8）BUG的所有描述中，不要带有个人情绪或诽谤性词汇，要用专业名词、准确、客观的描述问题、实际结果及期望结果。

7.3 BUG关键信息释义

【所属产品】
提出的BUG是属于哪个产品的。当有不止一个产品时，需填写，以方便研发确认是哪个产品的问题，也方便测试人员后期统计分析BUG，确认BUG是属于哪个产品的；

【所属项目】
提出的BUG是属于哪个项目的。当同一个产品不止一个项目时，需填写，以方便研发确认是哪个项目的问题，也方便测试人员后期统计分析BUG，确认BUG是属于哪个项目的；

【所属模块】
提出的BUG是属于哪个模块的。方便研发快速定位问题是哪个模块的，也方便测试人员后期统计分析BUG，确认BUG是哪个模块的，以定位哪些模块BUG率较高，后期加强测试；

【影响版本】
提出的BUG是属于哪个版本的。方便测试人员后期统计分析BUG以及确认BUG是在哪个版本解决的；

【当前指派】
提出的BUG指派给谁（一般指派给对应开发进行问题确认及解决，也可以指给研发经理或测试经理，经研发经理或测试经理确认后再进行问题指派）；

【截止日期】
期望问题能在什么时间内解决；

【BUG标题】
BUG的标题为必填项，最好以精确简练的语句描述出问题所在模块及问题内容（也可包含版本信息），方便研发经理、测试经理、研发人员、测试人员快速了解问题的大概内容，后期进行问题分派、问题解决以及问题回归时，也可快速区分不同的BUG；

【BUG类型】
禅道中BUG类型包含以下几种

代码错误：由于研发人员代码编写不合理或错误导致的问题，属于代码错误；

低级缺陷：轻微级别的小缺陷；

设计缺陷：由于产品人员或设计人员逻辑、功能、交互等方面设计的不合理导致的问题，属于设计缺陷；

配置相关：由于环境配置不正确导致的问题，属于配置相关的缺陷；

安全相关：由于数据有效性检测不合理、重要数据在传输中没有加密、缺少身份认证机制或认证不合理等安全相关的问题，属于安全相关缺陷；

性能问题：与程序性能相关的问题，例如：并发量、吞吐量、响应时间等不达标问题，属于性能问题；
界面优化：界面设计不合理、颜色不合适、显示位置不合适、文字说明或标题名称不合适等界面显示问题，属于界面优化问题；

其他：不属于以上类型的问题，例如兼容性问题，选择此类型。

【严重程度】
禅道中BUG严重程度分为四级：1、2、3、4，分别对应：致命缺陷、严重缺陷、普通缺陷、轻微缺陷

1类-致命缺陷Blocker：
阻碍开发和测试工作，致命性的缺陷。例如：系统无法登录、经常闪退或主流程应用模块无法启动、异常退出、用户数据受到破坏、系统崩溃，阻断性问题，造成系统不稳定；

2类-严重缺陷Critical 、Major：
系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响；

3类-普通缺陷Normal 、Minor：
系统的次要功能没有完全实现，但不影响用户的正常使用，或由于兼容性问题，导致界面布局变形、图片无法显示等致使某个小功能无法使用；

4类-轻微缺陷trivial：
不影响功能的、有关易用性的、文字、操作可以提出一些建议的问题。

【优先级】
禅道中BUG优先级分为四级：1、2、3、4，分别对应：紧急、高、中、低

1-非常紧急：
影响测试，需立即修复；

2-紧急：
希望能尽快修复，除非常紧急之外的，优先处理；

3-一般紧急：
在版本发布之前修改完；

4-低：
对产品的影响比较小，在时间不允许的情况下可以暂时不修改。

【BUG内容】
BUG内容一般必须包括：操作步骤、实际结果、期望结果。但也可根据实际情况，写出问题模块、测试数据、BUG重现的概率（一般为偶发或特殊次数之后才会出现的问题），或添加问题截图、需求附件等，可以更加直观的快速定位问题。

【相关需求】
若发现的BUG与需求相关，则可选择关联对应需求，方便研发人员了解问题的前因后果及具体需求内容，也方便测试人员后期查阅BUG/需求内容，回归测试时了解正确功能内容。

【相关任务】
若发现的BUG与任务相关，则可以选择关联任务，此任务一般为测试人员的任务，方便后期BUG统计、回归等。

8BUG处理流程

8.1 BUG生命周期

一般BUG的生命周期为：创建（激活）–确认（已确认）–解决（已解决）–关闭（已关闭）。
目前测试按以下流程执行缺陷跟踪流程，主要工具为禅道。
1）测试人员在测试过程中，发现并创建BUG（创建完成后状态为：激活状态），记录产品缺陷，分析并跟踪BUG直至问题解决；
2）BUG创建后会指派给对应人员，若存在中间分析/分配BUG人员，则指派给该人员，分析/分配BUG的人员查看BUG并进行分析，确定为BUG则确认BUG（状态变为：已确认）并将问题指派给对应解决人员（一般为研发人员）；
3）研发人员及时分析处理问题，问题解决后修改BUG状态为：已解决，并填写解决方案、解决版本，然后指派给测试人员（一般为创建BUG的人员），若有特殊说明，则在备注中说明；
4）测试人员对已解决状态的问题及时进行回归，若问题解决则关闭BUG，若问题未解决则激活。

8.2 BUG解决方案

禅道中BUG解决方案有：设计如此、重复BUG、外部原因、已解决、无法重现、延期处理、不予解决。
【设计如此】若BUG所述内容与产品或设计图是一致的，则研发人员在将BUG置为已解决状态时，可选择：设计如此解决方案，但建议在备注内进行说明；
【重复BUG】若BUG为重复BUG，即已经存在与此相同的BUG，则研发人员在将BUG置为已解决状态时，可选择：重复BUG 解决方案，并填写重复BUG的ID，若有特殊说明可在备注内进行说明；
【外部原因】若BUG的出现原因为外部原因（例如硬件、第三方软件等导致的问题），则研发人员在将BUG置为已解决时，可选择：外部原因解决方案并在备注内进行说明；
【已解决】若BUG中描述的问题已解决，则研发人员在将BUG置为已解决状态时选择：已解决解决方案；
【无法重现】若BUG为无法重现的BUG，则研发人员在将BUG置为已解决状态时，可选择：无法重现解决方案，并在备注内进行说明，建议研发人员遇到此类问题联系测试人员进行复现；
【延期处理】若研发人员考虑到时间等原因，觉得BUG需要延期进行处理，则在将BUG置为已解决时，选择：延期处理解决方案，并填写计划在哪个版本进行修复，在备注内进行原因说明；
【不予解决】若研发人员在分析问题后觉得不是问题或者无需修改，则选择：不予解决解决方案并在备注内写明不予解决的原因。

8.3 BUG回归

【设计如此】针对解决方案为：设计如此的BUG，测试人员在回归时进行验证，若无法接受此方案，则激活BUG，若接受此解决方案，则关闭BUG（可以与产品\设计人员进行确认）；
【重复BUG】针对解决方案为：重复BUG 的BUG，测试人员在回归时进行验证，若为重复 BUG，则关闭BUG，若不为重复BUG则激活并在备注内填写说明；
【外部原因】针对解决方案为：外部原因的BUG，测试人员在回归时，查看研发人员给予的备注，若可以接受则关闭BUG，不接受则记录，可在发版前开会进行讨论，并给予处理方案；
【已解决】针对解决方案为：已解决的BUG，测试人员回归问题，若问题已解决则关闭 BUG，若未解决则激活BUG（注意查看备注）；
【无法重现】针对解决方案为：无法重现的BUG，测试人员根据操作步骤进行重现BUG，若无法重现则关闭，若可以重现则激活（可联系研发人员进行当面重现）；
【延期处理】针对解决方案为：延期处理的BUG，查看备注内容，可以接受则关闭BUG（关闭BUG则记录问题，也可不关闭待下个版本解决后再关闭），不接受则与产品人员确认是否延期或发版前会议讨论处理方案；
【不予解决】针对解决方案为：不予解决的BUG，查看备注内容，可以接受则关闭BUG，不接受则与产品人员确认是否需要解决或发版前会议讨论处理方案。

8.4 BUG处理流程图

8.5 遗留BUG跟踪

【发版前遗留BUG】由于时间问题或其他原因，发版后可能会存在一些遗留BUG未解决，需要将这些BUG进行记录、分析，方便后期迭代进行问题修复；
【发版后遗留BUG】产品发布后的 bug 来源有：客户、开发、测试人员，该类 bug 在发现后需要提交给项目组，纳入bug管理，该类 bug的发现阶段标识为已发布，便于分析原因及下期优化。

8.6 BUG分析

项目结束后，需要对BUG进行分析整理，可以统计BUG的类型、严重程度、所属模块等信息。然后进行分析，得出BUG的出现频率、出现模块、出现类型等，以采取相应措施避免该类 bug再次出现，提高产品质量。测试人员每个项目测试结束以后，将 bug 分析结果写在《测试报告》中。