缺陷提单 规范

一. 目的

1. 方便开发人员更好的理解bug问题与期望
2. 方便相关人员重现bug
3. 测试人员更加清晰的描述问题
4. 统一bug单的编写习惯，提升工作效率

二. BUG 提单规则

1. 标题 编写规则如下

  【客户侧/后台】【模块-子模块】【必现/偶现】问题描述
   例如：【客户侧】【已发送-复制】保存到草稿箱报系统错误
   说明：

【模块-子模块】模块有多层级用 - 来表示层级关系
【必现/偶现】当问题为 偶现 的时候才写该项，没有该项默认为 必现 问题
问题描述：尽量简洁，一语中的，如遇复现步骤较多的可在内容中补充步骤

2. 内容

  1. 客户侧问题需要写上复现 账号、密码，后台管理的不用，如果有用其它自己的账号也要写
  2. 对于复现步骤较多的问题 需要将复现步骤写清楚
  3. 相关SQL的问题，需要将SQL写入
  4. 对于偶现的bug，需要将偶现的几率写出来，比如测试几次，出现几次，测试几天，出现几次类似的
  5. 对于服务端的bug需要将 CURL 写上 ，CURL如下图复制		
 
 6. 问题截图可以采用上述文字加箭头的形式呈现出来
 7. 对于有附件的数据，比如导入excel或者图片 需要将文件上传在附件
 备注：内容的排序按上述列的呈述即可，有的bug一眼就看出来的，可以省略步骤

3. 严重程度

 **1级**. 导致平台无法使用问题，比如整个平台崩溃，导致无法使用，测试阻塞
 **2级**. 某个功能未实现或导致一个特性不能运行，且没有替代方案，功能特性设计不符合需求，影响业务，没有一个补救方法
 **3级**. 错误导致一个特性不能运行但有一个替代方案，功能特性设计不符合需求，但是不影响业务，有相应的补救方法
 **4级**.错误是表面细化或微小的，比如提示信息，界面布局等，对功能几乎没有影响，用户使用频率小，几乎触发几率小

4. 优先级

  1.紧急：应该立即解决的
  2.必须：必须修改，发版前必须修正
  3.应该：必须修改，不一定马上修改，但需确定某个版本发布前修正
  4.可选：如果时间允许可以修改，不允许放后续迭代修正

5. 指定开发人员

  1. 每个迭代对应任务都有细化到人，因此bug指给对应的任务开发者
  2. 对于发现非本次迭代的bug，如果知道之前谁负责的，直接指给对应开发，不知道的服务端统一指给负责人，前端统一指给负责人

6. 其它

  1. 兼容性问题需要将浏览器对应选择，如果没有浏览器对应版本，可再内容中补充
  2. 如果优先级高的，需要在服务端测试群里 @对应开发，让尽快处理
  3. 对于迭代上线，1，2级别的必须全部解决，残留的3级bug数量不能超过*个才可上线