1.编号：

编号一般都是在后台配置自动生成，产品+版本+模块+编号或者直接使用阿拉伯数字自增。

2.标题：

就是我们常说的bug描述，简明扼要地说明即可，一般不带个人情感，只描述bug现象。

3.缺陷类型：

判断是需求还是缺陷还是建议级别，若为缺陷，是缺陷中的功能性、浏览器兼容性、界面还是性能。

4.所属模块：

该缺陷发现与哪个模块，若有相关联的模块或其他模块也调用了该功能，都写上。

5.前置条件：

该缺陷发生的条件。如已登录、未联网等

6.复现步骤：

具体的重现步骤，一定要写得简介明了，使研发人员可快速看明白，找到问题所在，适当地增加步骤截图更好。

7.预期结果和实际结果：

对比预期结果和实际结果，才知道问题症结的大概原因。

8.其他：

项目、产品：该缺陷属于哪个项目、产品；

发现版本：该缺陷在哪个版本发现，便于与后期的修复版本区别以及版本管理；

环境：便于确认是否与环境有关，如浏览器兼容性的问题；

状态：刚提交时一般都是未解决状态，待修复后才是fixed状态，回归确认无误后方可关闭；

优先级、重要程度：该缺陷所属的优先级、重要性；

创建人：谁发现的；

指派给：给谁处理。

未被发现的缺陷或问题的BUG都具有未知，缺陷，不易发现，三种要素。系统无法正常工作的BUG和以系统功能无关的BUG。

一般主要包含内容有

          Bug标题

            Bug描述

            Bug出现步骤

            附件（可以附上出现的缺陷截图更有说服力）

            Bug严重程度和优先级《一般严重等级分为;致命，严重，一般，建议四个等级和优先级分为高中低三级》

            指派给谁（一般指派给开发者或者不知道是某个开发者就指派给测试经理或项目经理）

bug的测试人员，提交的bug、bug标题、bug描述、开发人员、提交时间、结果分析

一般主要包含内容有

          Bug标题

            Bug描述

            Bug出现步骤

            附件（可以附上出现的缺陷截图更有说服力）

            Bug严重程度和优先级《一般严重等级分为;致命，严重，一般，建议四个等级和优先级分为高中低三级》

            指派给谁（一般指派给开发者或者不知道是某个开发者就指派给测试经理或项目经理）

提交的bug、bug标题、bug描述、开发人员、提交时间、结果分析