禅道Bug提交管理规
修订历史
目录
目录 (2)
1. 目的 (3)
2. 禅道系统Bug流程图 (4)
3. Bug流程操作及其Bug相关信息解释 (5)
3.1.测试人员发现bug (5)
3.2.测试人员创建Bug (5)
3.3.开发人员设定Bug优先级别并确认Bug (7)
3.4.开发人员解决Bug (8)
3.5.测试人员验证Bug (9)
1.目的
本文档定义了bug管理流程及其bug相关信息容。

本文档适用围：
●本文档适用于新产品以及以后新产品的项目。

原有项目的bug管理仍然用JIRA系
统进行管理。

●本文档适用于新产品以及以后新产品的项目相关的测试人员和开发人员。

2. 禅道系统Bug流程图
3. Bug流程操作及其Bug相关信息解释
3.1.测试人员发现bug
3.2.测试人员创建Bug
测试人员登录禅道系统，创建Bug。

Bug状态为激活（未确认）
创建Bug页面截图：
页面字段注释：
所属产品：选择发现Bug的产品，必填项。

所属模块：选择发现Bug的对应模块，必填项。

所属项目：选择测试所属的项目。

必填项。

影响版本：选择发现bug的版本。

必填项。

当前指派：选择指派的开发人员。

必填项。

Bug标题：用简单明了的语句说明Bug容，相当于BUG的中心语句。

必填项。

在标题上注明bug出现的频率（稳定出现/经常出现/很少出现/出现一次）重新步骤：重现步骤格式如下。

必填项。

[环境]：如果系统/浏览器信息不能够全部说明发现Bug的环境，需要在
重现步骤里详细描述环境信息，以便于开发定位和解决问题。

[步骤]：写明出现Bug的操作步骤，要求简单，去掉与Bug无关的步骤。

[结果]：写明操作的实际结果。

[期望]：写明操作的期望结果。

相关需求：选择与Bug相关的需求。

如果Bug关联测试用例，系统会自动关联测试用例的需求。

相关任务：选择与Bug相关的任务。

这里的任务是在『项目』->『任务』中创建的任务。

Bug类型如下：
●代码错误：功能性错误。

●界面优化
●设计缺陷
●配置相关
●安装部署
●安全相关
●性能问题
●标准规
●测试脚本
●其他
系统/浏览器：选择出现问题的系统平台和使用的浏览器信息。

必填项。

抄送给：选择需要抄送的人员。

关键词：填写关键词，便于搜索查找。

附件：如需必要，附加可以说明bug的文件，截图，dump等信息。

注：如果Bug是关联测试用例创建的，系统会自动取测试用例的信息（标题，前置条件，步骤，期望结果，需求）作为Bug的信息。

3.3.开发人员设定Bug优先级别并确认Bug
第一步：开发人员查看指派给自己的Bug列表，编辑bug并确定每个bug的优先级别。

优先级别根据时间，紧急度，重要程度综合确定。

优先级别由开发人员自己定义，开发负责人具有复查/重定义/监督的责任。

页面字段注释：
优先级别：如下表。

必填项。

Bug严重度等级描述
1 – Urgent 立即修复。

2 – High 产品发布前必须修改完成。

3 – Medium 时间允许，产品发布前应该修改。

4 – Low 产品发布前可能修改。

不影响发布。

第二步：确定Bug的优先级别后，开发工程师根据Bug的优先级别开始解决（复现/调试等），此时需要确认bug，表明Bug正在处理。

通过已确认/未确认状态可以查询开发人
员已开始处理/未开始处理的Bug信息。

Bug状态为激活（已确认）。

3.4.开发人员解决Bug
开发人员解决bug后，执行『解决』操作。

填写解决方案，指派给，备注信息。

Bug状态为已解决。

之后开发人员等待build的创建，如果build创建完毕，开发及时确认在此次创建build上解决的bug，并修改bug的解决版本。

Build的创建参见迭代开发流程。

针对延期处理的Bug，需要单独创建一个Build，名称例如为“下一版本”。

如果开发解决了延期处理的Bug，需要修改Bug的解决方案，解决版本等信息。

针对重复的Bug，开发需要在重复bug中写明重复bug的ID。

新Build创建后，开发人员需要及时复查在新build上解决的Bug，并修改Bug的解决版本信息。

测试人员需要及时提醒开发人员完成此项工作。

页面字段注释：
名称英文对照
设计如此Bydesign
重复Bug Duplicate
外部原因External
转为需求Tostory
已解决Fixed
无法重现Not Reproduce
延期处理Postponed
不予解决willnotfix
解决版本：选择创建的build。

Build来自与『项目视图』->『Build』中创建的Build。

必填项。

指派给：选择验证Bug的测试人员。

默认为Bug的创建者。

必填项。

备注：开发人员填写bug的原因及解决办法。

3.5.测试人员验证Bug
测试人员验证状态为已解决并解决版本不为空的bug。

验证结果一：如果验证bug在build上已经解决，测试人员『关闭』Bug并填写验证信息。

Bug状态为已关闭。

后续操作：如果Bug来自与case的执行，测试人员需要重新执行对应Case，确保
Case最终状态是通过。

如果Case的执行仍然发现bug，将进入新一轮的Bug流程。

验证结果二：如果验证bug，没有通过，测试人员填写验证信息，并『激活』bug。

Bug状态为激活（已确认）。

页面字段注释：
指派给：将正在激活的bug指派给对应开发人员。

必填项。

影响版本：选择复现Bug的build。

必填项。

备注：填写验证信息。

附件：附加相关可以证明bug的附件，例如截图，错误文本，dump等。

各解决方案，测试人员对应操作。

名称对应操作
设计如此如果同意，关闭Bug；如果不同意，写明原因，激活Bug。

重复Bug 确认重复，关闭Bug；如果不重复，写明原因，激活Bug。

外部原因如果同意，关闭Bug，并考虑是在用户手册/FAQ记录问题；如果不同意，写明原因，激活Bug。

转为需求如果同意，转为需求，关闭Bug，之后由需求负责人跟踪；如果不同意，写明原因，激活Bug 已解决如果验证已解决，写明验证结果，关闭Bug，重新执行测试用例；如果验证没有解决，写明验证信息，激活Bug。

无法重现测试人员需要帮助开发人员复现Bug。

如果复现，保留测试环境，提供给开发人员进行调试；
如果不复现，保留Bug，并在以后的3-4个版本上验证，如果仍然不出现，写明验证的版本
和结果，关闭Bug。

. .
.页脚。