禅道基本使用之提交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的时候，可以直接指派给某一个人员去处理。如果不清楚的话，可以保留为空。
• 附件可以添加图片，word、excel、txt等文件

1、禅道中bug类型包含以下几种

1.1、代码错误：

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

1.2、设计缺陷：

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

1.3、配置相关：

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

1.4、安全相关：

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

1.5、性能问题：

与程序性能相关的问题，例如：并发量、吞吐量、响应时间等不达标问题，属 于性能问题；

1.6、界面优化：

界面设计不合理、颜色不合适、显示位置不合适、文字说明或标题名称不合适 等界面显示问题， 属于界面优化问题；

1.7、其他：

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

2、禅道中bug优先级

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

3、禅道中bug严重程度

bug严重程度分为四级：1、2、3、4，分别对应：致命缺陷、严重缺陷、普通（一般）缺陷、轻微缺陷
1-致命缺陷：
阻碍开发和测试工作，致命性的缺陷。例如：系统无法登录、经常闪退或主流程应用模块无法启动、异常退出、用户数据受到破坏、系统崩溃，阻断性问题，造成系统不稳定；

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

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

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

三、处理bug

当一个bug指派给某一位研发人员之后，他可以来确认解决这个bug。在对bug进行处理之前，需要先找到需自己处理的bug。禅道提供了各种各样的检索方式，比如“指派给我”，可以列出所有需要我处理的bug。

• 确认bug：确认该bug确实存在后，可以将其指派给某人，并指定bug类型、优先级、备注、抄送等。
• 解决bug：当bug修复解决后，点击解决，指定解决方案、日期、版本，并可将其再指派给测试人员。
• 关闭bug：当研发人员解决了bug之后，bug会重新指派到bug的创建者头上。这时候测试人员可以来验证这个bug是否已经修复。如果验证通过，则可以关闭该bug。（bug列表页和详情页中都有“关闭”按钮。）
• 编辑bug：对bug进行编辑操作。
• 复制bug：复制创建当前bug，在此基础上再做改动，避免重新创建的麻烦。

1、BUG解决方案

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

2、bug回归测试

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