禅道bug提交管理规范概要1.doc

禅道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 目的 本文档定义了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严重程度如下： Bug严重度等级 描述 范例 1 – Critical 所产生的问题导致系统崩溃，蓝屏，停顿； 缺少主要功能或者主要功能毫无作用，导致无法进行下一步测试。 1．系统蓝屏，崩溃 2．由于程序所引起的死机,非法退出 3． 死循环 4． 数据库发生死锁 5． 因错误操作导致的程序中断 6．与数据库连接错误 7． 数据通讯错误 2 – High 所产生的问题会导致系统部分功能不正常； 所产生的问题严重但不影响下一步测试。 1． 功能不符 2． 程序接口错误 3． 数据库的表、业务规则、缺省值未加完整性等约束条件 4． 主要功能错误 3 – Medium 所产生的问题导致系统很小的功能问题； 不会影响下一步测试； 功能运作正常，可是有改进的空间– Low 所产生的问题不会导致系统任何问题； 所产生的问题不影响下一步测试； 1． 界面不规范 2． 辅助说明描述不清楚 3． 输入输出不规范 4． 长时间操作未给用户提示 5． 提示窗口文字未采用行业术语 6． 可输入区域和只读区域没有明显的区 系统/浏览器：选择出现问题的系统平台和使用的浏览器信息。必填项。 抄送给：选择需要抄送的人员。 关键词：填写关键词，便于搜索查找。 附件：如需必要，附加可以说明bug的文件，截图，dump等信息。 注：如果Bug是关联测试用例创建的，系统会自动取测试用例的信息（标题，前置条件，步骤，期望结果，需求）作为Bug的信息。 3.3.开发人员设定Bug优先级别并确认Bug 第一步：开发人员查看指派给自己的Bug列表，编辑bug并确定每个bug的优先级别。优先级别根据时间，紧急度，重要程度综合确定。优先级别由开发人员自己定义，开发负责人具有复查/重定义/监督的责任。 页面字段注释： 优先级别： 如下表。必填项。 Bug严重度等级 描述 1 – Urgent 立即修复。 2 – High 产品发布前必须修改完成– Medium 时间允许，产品发布前应该修改。 4 – Low 产品发布前可能修改。 不影响发布。 第二步：确定Bug的优先级别后，开发工程师根据Bug的优先级别开始解决（复现/调试等），此时需要确认bug，表明Bug正在处理。通过已确认/未确认状态可以查询开发人员已开始处理/未开始处理的Bug信息。Bug状态为激活（已确认）。 3.4.开发人员解决Bug 开发人员解决bug后，执行『解决』操作。填写解决方案，指派给，备注信息。Bug状态为已解决。之后开发人员等待build的创建，如果build