缺 陷 编 写 规 范 一 、目的 统 一 缺 陷 编 写 的 规 范 , 为 了 测 试 工 程 师 提 供 缺 陷 编 写 的 指 导 , 提 高 编 写 的 缺 陷 的 可 读 性 、无歧义性 、可 操作性 。为 开发工 程 师 更好的 复现缺 陷 , 理解问题发生现象, 提 高 效率, 最终提 高 公司整个产品的 质量。 二、范 围 适用于缺 陷 报告编 写 , 辅助工 具为 Jira 三、背景描述 目前 JIRA里提 交的 BUG很多表述含糊, 过于简练, 缺 少 URL、用户或密码信息造成程 序员没有办法明白这个 BUG的 含义, 也无法重现该问题, 很难分析问题产生的 原因, 延误了 BUG修改时间, 同时增加了 很多沟通成本, 为 了 解决这个问题, BUG报告必须按照规 范 来编 写 。 四、JIRA中提交 BUG的规 范 每个 bug状态表示的具体含义说明如下: 状态 描述 Open Bug已经确认, 等待被处理 In Progress Bug正在处理中 ResolvedBug已处理, 待确认 Closed 确认被修复的 Bug, 如果已修复, 置为 此状态 Reopen 确 认 被 修 复 的 Bug, 如 果 没 修 复 , 置 为 此 状 态 已 处 理 , 待 确 认 状 态 中 , 处 理 结 果又包含(fixed,won’t fix,duplicate,incomplete,cannot reproduce,Work as Design) 分别对应(修 改完成, 不需要修 改, 重复 提交的 bug, 描述不完整, 不能复 现, 按设计来实现的 不需要修 改各状 态 ); 不需要修 改和推迟修 改的 状 态 时请开发或相关人员加备注说明下原因,修 改完成的 bug需要开发人员写上问题产生原因. 优 先 级 别 的 定 义 和 举 例 说 明 5级 : 致 命 缺 陷 修 复 优 先 级 : 阻止相关开发人员的 进一步开发活动, 立即进行修 复 工作;阻止与此 密切相关功能的 进一步测试; 例 如 : 导致系统崩溃、死机、死循环、数据丢失、计算错误、安装错误; 播放黑屏、flash崩溃、程序崩溃、数据库崩溃、服务器不能访问或崩溃;需求中 的 功能未实现;产品 logo和其 他 影 响 品牌 形 象 的 界 面 错误;占 有 率 比 较 大 的 浏 览 器页 面 严 重错位 ;404、500错误&报 黄 页 (即指 向 未知 页 面 错误页 )等 ; 4级 : 严重功能缺 陷 修 复 ...