缺 陷 编 写 规 范 一 、目的 统 一 缺 陷 编 写 的 规 范 ， 为 了 测 试 工 程 师 提 供 缺 陷 编 写 的 指 导 ， 提 高 编 写 的 缺 陷 的 可 读 性 、无歧义性 、可 操作性 。为 开发工 程 师 更好的 复现缺 陷 ， 理解问题发生现象， 提 高 效率， 最终提 高 公司整个产品的 质量。 二、范 围 适用于缺 陷 报告编 写 ， 辅助工 具为 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级 ： 严重功能缺 陷 修 复 ...
