禅道bug提交管理规范

1、禅道Bug提交管理规范修订历史目录目录21. 目的32. 禅道系统Bug流程图43. Bug流程操作及其Bug相关信息解释53.1.测试人员发现bug53.2.测试人员创建Bug53.3.开发人员设定Bug优先级别并确认Bug73.4.开发人员解决Bug83.5.测试人员验证Bug91. 目的本文档定义了bug管理流程及其bug相关信息内容。本文档适用范围：l 本文档适用于新产品以及以后新产品的项目。原有项目的bug管理仍然用JIRA系统进行管理。l 本文档适用于新产品以及以后新产品的项目相关的测试人员和开发人员。2. 禅道系统Bug流程图3. Bug流程操作及其Bug相关信息解释3.1.测试

2、人员发现bug3.2.测试人员创建Bug测试人员登录禅道系统，创建Bug。Bug状态为激活（未确认）创建Bug页面截图：页面字段注释：所属产品：选择发现Bug的产品，必填项。所属模块：选择发现Bug的对应模块，必填项。所属项目：选择测试所属的项目。必填项。影响版本：选择发现bug的版本。必填项。当前指派：选择指派的开发人员。必填项。Bug标题：用简单明了的语句说明Bug内容，相当于BUG的中心语句。必填项。在标题上注明bug出现的频率（稳定出现/经常出现/很少出现/出现一次）重新步骤：重现步骤格式如下。必填项。环境：如果系统/浏览器信息不能够全部说明发现Bug的环境，需要在重现步骤里详细描述环

3、境信息，以便于开发定位和解决问题。步骤：写明出现Bug的操作步骤，要求简单，去掉与Bug无关的步骤。结果：写明操作的实际结果。期望：写明操作的期望结果。相关需求：选择与Bug相关的需求。如果Bug关联测试用例，系统会自动关联测试用例的需求。相关任务：选择与Bug相关的任务。这里的任务是在项目->任务中创建的任务。Bug类型如下：l 代码错误：功能性错误。l 界面优化l 设计缺陷l 配置相关l 安装部署l 安全相关l 性能问题l 标准规范l 测试脚本l 其他Bug严重程度如下：Bug严重度等级描述范例1 Critical所产生的问题导致系统崩溃，蓝屏，停顿；缺少主要功能或者主要功能毫无作用

4、，导致无法进行下一步测试。1系统蓝屏，崩溃2由于程序所引起的死机,非法退出3 死循环4 数据库发生死锁5 因错误操作导致的程序中断6与数据库连接错误 7 数据通讯错误2 High所产生的问题会导致系统部分功能不正常；所产生的问题严重但不影响下一步测试。1 功能不符2 程序接口错误 3 数据库的表、业务规则、缺省值未加完整性等约束条件4 主要功能错误3 Medium所产生的问题导致系统很小的功能问题；不会影响下一步测试；功能运作正常，可是有改进的空间。1 操作界面错误（包括数据窗口内列名定义、含义是否一致） 2 打印内容、格式错误 3 简单的输入限制未放在前台进行控制 4 删除操作未给出提示 5

5、 数据库表中有过多的空字段4 Low所产生的问题不会导致系统任何问题；所产生的问题不影响下一步测试；1 界面不规范 2 辅助说明描述不清楚 3 输入输出不规范 4 长时间操作未给用户提示 5 提示窗口文字未采用行业术语 6 可输入区域和只读区域没有明显的区系统/浏览器：选择出现问题的系统平台和使用的浏览器信息。必填项。抄送给：选择需要抄送的人员。关键词：填写关键词，便于搜索查找。附件：如需必要，附加可以说明bug的文件，截图，dump等信息。 注：如果Bug是关联测试用例创建的，系统会自动取测试用例的信息（标题，前置条件，步骤，期望结果，需求）作为Bug的信息。3.3.开发人员设定Bug优先级

6、别并确认Bug第一步：开发人员查看指派给自己的Bug列表，编辑bug并确定每个bug的优先级别。优先级别根据时间，紧急度，重要程度综合确定。优先级别由开发人员自己定义，开发负责人具有复查/重定义/监督的责任。页面字段注释：优先级别： 如下表。必填项。Bug严重度等级描述1 Urgent立即修复。2 High产品发布前必须修改完成。3 Medium时间允许，产品发布前应该修改。4 Low产品发布前可能修改。不影响发布。 第二步：确定Bug的优先级别后，开发工程师根据Bug的优先级别开始解决（复现/调试等），此时需要确认bug，表明Bug正在处理。通过已确认/未确认状态可以查询开发人员已开始处理/

7、未开始处理的Bug信息。Bug状态为激活（已确认）。3.4.开发人员解决Bug 开发人员解决bug后，执行解决操作。填写解决方案，指派给，备注信息。Bug状态为已解决。之后开发人员等待build的创建，如果build创建完毕，开发及时确认在此次创建build上解决的bug，并修改bug的解决版本。Build的创建参见迭代开发流程。针对延期处理的Bug，需要单独创建一个Build，名称例如为“下一版本”。如果开发解决了延期处理的Bug，需要修改Bug的解决方案，解决版本等信息。针对重复的Bug，开发需要在重复bug中写明重复bug的ID。新Build创建后，开发人员需要及时复查在新build上解

8、决的Bug，并修改Bug的解决版本信息。测试人员需要及时提醒开发人员完成此项工作。页面字段注释：解决方案：选择Bug的解决方案，具体方案如下表。必填项。名称英文对照设计如此Bydesign重复BugDuplicate外部原因External转为需求Tostory已解决Fixed无法重现Not Reproduce延期处理Postponed不予解决willnotfix解决版本：选择创建的build。Build来自与项目视图->Build中创建的Build。必填项。指派给：选择验证Bug的测试人员。默认为Bug的创建者。必填项。备注：开发人员填写bug的原因及解决办法。3.5.测试人员验证Bu

9、g测试人员验证状态为已解决并解决版本不为空的bug。l 验证结果一：如果验证bug在build上已经解决，测试人员关闭Bug并填写验证信息。Bug状态为已关闭。后续操作：如果Bug来自与case的执行，测试人员需要重新执行对应Case，确保Case最终状态是通过。如果Case的执行仍然发现bug，将进入新一轮的Bug流程。l 验证结果二：如果验证bug，没有通过，测试人员填写验证信息，并激活bug。Bug状态为激活（已确认）。页面字段注释：指派给：将正在激活的bug指派给对应开发人员。必填项。影响版本：选择复现Bug的build。必填项。备注：填写验证信息。附件：附加相关可以证明bug的附件，例如截图，错误文本，dump等。各解决方案，测试人员对应操作。名称对应操作设计如此如果同意，关闭Bug；如果不同意，写明原因，激活Bug。重复Bug确认重复，关闭Bug；如果不重复，写明原因，激活Bug。外部原因如果同意，关闭Bug，并考虑是在用户手册/FAQ记录问题；如果不同意，写明原因，激活Bug。转为需求如果同意，转为需求，关闭Bug，之后由需求负责人跟踪；如果不同意，写明原因，激活Bug已解决如果验证已解决，写明验证结果，关闭Bug，重新执行测试用例；如果验证没有解决，写明验证信息，激活Bug。无法重现测试人员需要帮助开发人员复现Bu