禅道BUG编写及处理流程规范

概述

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

什么是bug?

软件缺陷：通常又被叫做Defect或者Bug。 产品需求文档中规定要做的事情，而软件没有实现。
产品需求文档中规定不要做的事情，而软件确实现了。 产品需求文档中中没有提到过的事情，而软件确实现了。
产品需求文档中没有提到但是必须要做的事情，软件确没有实现。
软件很难理解，很难使用，速度超慢，测试人员站在最终用户的角度看到的问题是平常的但不是正确的。

禅道创建一个bug必填内容

创建BUG需要填写以下关键信息：
1.所属产品（必填）
2.所属项目（必填）
3.所属模块（必填）
4.影响版本（必填）
5.当前指派（必填）
6.截止日期、BUG类型（必填）
7.操作系统、浏览器
8.BUG标题（必填）
9.严重程度（必填）
10.优先级（必填）
11.BUG内容（必填）
12.相关需求、相关任务、抄送人员、关键词、附件，未标红的选项可根据实际情况酌情填写。
1.所属产品
提出的BUG是属于哪个产品的。当有不止一个产品时，需填写，以方便研发确认是哪个产品的问题，也方便测试人员后期统计分析BUG，确认BUG是属于哪个产品的；
2.所属项目
提出的BUG是属于哪个项目的。当同一个产品不止一个项目时，需填写，以方便研发确认是哪个项目的问题，也方便测试人员后期统计分析BUG，确认BUG是属于哪个项目的；
3.所属模块
提出的BUG是属于哪个模块的。方便研发快速定位问题是哪个模块的，也方便测试人员后期统计分析BUG，确认BUG是哪个模块的，以定位哪些模块BUG率较高，后期加强测试；
4.影响版本
提出的BUG是属于哪个版本的。方便测试人员后期统计分析BUG以及确认BUG是在哪个版本解决的；
5.截止日期
期望问题能在什么时间内解决；
6.当前指派
提出的BUG指派给谁（一般指派给对应开发进行问题确认及解决，也可以指给研发经理或测试主管，经研发经理或测试主管确认后再进行问题指派）；
7.Bug的类型

禅道中BUG类型包含以下几种
代码错误：由于研发人员代码编写不合理或错误导致的问题，属于代码错误；
设计缺陷：由于产品人员或设计人员逻辑、功能、交互等方面设计的不合理导致的问题， 属于设计缺陷；
配置相关：由于环境配置不正确导致的问题，属于配置相关的缺陷；
安全相关：由于数据有效性检测不合理、重要数据在传输中没有加密、缺少身份认证机制 或认证不合理等安 全相关的问题，属于安全相关缺陷；
性能问题：与程序性能相关的问题，例如：并发量、吞吐量、响应时间等不达标问题，属 于性能问题；
界面优化：界面设计不合理、颜色不合适、显示位置不合适、文字说明或标题名称不合适 等界面显示问题， 属于界面优化问题；
其他：不属于以上类型的问题，例如兼容性问题，选择此类型。
8.BUG标题
BUG的标题为必填项，最好以精确简练的语句描述出问题所在模块及问题内容，方便研发经理、测试主管、研发人员、测试人员快速了解问题的大概内容，后期进行问题分派、问题解决以及问题回归时，也可快速区分不同的BUG；
Bug标题中需包含Bug的具体位置并以【】标注 举例：【模块-子模块-页面】XXXXXXXXXXXX
Bug标题尽量简明
• 　　做什么操作 + 出现什么结果，比如（点击提交按钮，出现卡顿现象）
• 　　字数一般不超过20个字
Bug标题中切勿出现错别字 错误示例： 奔溃（崩溃），电击（点击），登陆，（登录），重置（充值），现实（显示）
9.BUG内容

BUG内容一般必须包括：操作步骤、实际结果、期望结果。但也可根据实际情况，写出问题模块、测试数据、BUG重现的概率（一般为偶发或特殊次数之后才会出现的问题），或添加问题截图、需求附件等，可以更加直观的快速定位问题。
1.操作步骤:
要简明清晰分步骤描述如何复现Bug问题，步骤用序号编排。
要按照自己的操作的实际步骤写清楚每一步是怎么操作的，最后操作到哪个页面或者点击哪个按键。
如：
1.进入进货订单页面
2.点击取消订单按钮
2.实际结果
按照测试步骤实际出现的错误结果
3.预期结果
按照测试步骤应当得到的正确结果，按照产品需求的期望清晰准确的填写预期结果
4.截图和附件
UI类型：Bug需要上传截图，并且增加相应的红框标识；
功能类型：问题必须上传视频文件，上传格式MP4为主；
崩溃类型：bug则需要上传视频和接口日志
5.接口问题的bug
需要填写
1.出错的接口地址
2.传入接口的参数
3.接口的返回数据
4.接口的请求方式
如图：

10.优先级

禅道中BUG优先级分为四级：1、2、3、4，分别对应：紧急、高、中、低
1-非常紧急：
影响测试，需立即修复；
2-紧急：
希望能尽快修复，除非常紧急之外的，优先处理；
3-一般紧急：
在版本发布之前修改完；
4-低：
对产品的影响比较小，在时间不允许的情况下可以暂时不修改。
11.严重程度

禅道中BUG严重程度分为四级：1、2、3、4，分别对应：致命缺陷、严重缺陷、普通缺陷、轻微缺陷
1-致命缺陷：
阻碍开发和测试工作，致命性的缺陷。例如：系统无法登录、经常闪退或主流程应用模块无法启动、异常退出、用户数据受到破坏、系统崩溃，阻断性问题，造成系统不稳定；
2-严重缺陷：
系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响；
3-普通缺陷：
系统的次要功能没有完全实现，但不影响用户的正常使用，或由于兼容性问题，导致界面布局变形、图片无法显示等致使某个小功能无法使用；
4-轻微缺陷：
不影响功能的、有关易用性的、文字、操作可以提出一些建议的问题。
12.相关需求
若发现的BUG与需求相关，则可选择关联对应需求，方便研发人员了解问题的前因后果及具体需求内容，也方便测试人员后期查阅BUG/需求内容，回归测试时了解正确功能内容。
13.相关任务
若发现的BUG与任务相关，则可以选择关联任务，此任务一般为测试人员的任务，方便后期BUG统计、回归等。
14.抄送给
添加的bug可以抄送给研发经理和测试主管，让他们可以看到你提的bug对你提的bug进行关注和审核

BUG处理流程

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

BUG解决方案

禅道中BUG解决方案有：设计如此、重复BUG、外部原因、已解决、无法重现、延期处理、 不予解决。

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

BUG回归

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