提交bug的内容书写规范

1.标题：【项目名称——简短的bug说明】

描述bug的最主要关键词，如xx项目——数据库输入输出数据不一致

2.项目名称：【项目名称+项目版本号】

3.Bug所属项目/模块：Bug所属项目和模块，最好能较精确地定位至模块；

4.严重等级：【紧急，严重，一般，微小】

紧急Bug：造成系统或应用程序崩溃(Crash)、死机、系统悬挂，或者造成数据丢失、主要功能完全丧失等。

严重的Bug：功能或者特性没有实现，主要功能部分丧失，次要功能完全丧失，或者致命错误声明。

一般的Bug：不太严重，虽然不影响系统的基本使用，但没有很好地实现功能，没有达到预期效果。如：次要功能丧失，提示信息不太准确，或用户界面差，操作时间长等。

微小的Bug：对功能几乎没有影响，产品及属性仍可使用，如有个错别字、文字排列不整齐等。

5.优先级：【P1，P2，P3，P4】

P1：立即解决，导致系统几乎不能使用或测试不能继续，需要立即修复；

P2：高优先级，严重，影响测试，需要优先考虑；

P3：正常排队，需要正常排队等待修复；

P4：可以在开发人员有时间的时候再纠正；

6. Bug状态：【New，Open， Fixed， Rejected， Delay ，Closed， Reopen】

New: 新发现的bug，开发人员尚未确认；

Open：确实是bug，并认为需要修改，指派给相应的开发人员；

Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证；

Rejected：如果认为不是bug，则决绝修改；

Delay：暂时不修改或者暂时不能修改，则延后修改；

Closed：fixed状态的Bug经测试人员回归测试验证通过，则关闭Bug；

Reopen：fixed状态的Bug经验证仍然存在，则需要重新打开Bug，开发人员重新修改；

新梦想技术分享

7.测试环境：【硬件设备环境，软件设备以及配置环境，具体到使用的版本号，类型号】

测试人员要充分说明测试环境的情况，以便开发人员可以快速定位错误，防止出现因开发环境与测试环境不符，而无法重现bug的情况。

8.重现步骤：【详细、精炼的描述bug出现的操作过程，一步一步地描述】

提供如何重复当前Bug的准确描述，应该简明而完备、清楚而准确；录入之前要多做几次尝试，尽量把操作步骤缩减到必须要执行才能重现错误的几个步骤；

9.期望结果：【需求给出的输出结果，即正常结果】

按照设计规格说明书和用户需求，在上述步骤之后，所期望的结果，即正确结果；要描述清楚产品需求制定的正确结果是什么，避免开发人员因产品需求不明，而产生不必要的沟通开销；

10.实际结果：【实际测试输出的结果，即错误的结果】

客观反映事实。如：程序抛出异常信息如下…

11.出现频率：【必现，通常，有时，很少】描述bug出现的可能性1%~100%；

必现：总是出现这个Bug，产生频率为100%；

通常：按照测试用例，通常情况下回产生这个Bug，频率大概80%~90%；

有时：按照测试用例，有的时候会产生这个Bug，频率大概30%~50%；

很少：按照测试用例，很少产生这个Bug，频率大概是1%~5%；

12.问题隔离：【描述环境的版本，类型等的单一变化和组合状态下，是否出现】

13.必要的附件：【图片，Log文件】

对于某些只用文字描述还不足够清楚的Bug，使用图片，错误日志等必要的附加；对于软件崩溃等现象，需要捕捉到日志文件作为附件提供给开发人员