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

禅道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 分析结果写在《测试报告》中。