提交bug的内容书写规范：
1. 标题：【项目名称——简短的bug说明】
描述bug的最主要关键词，如xx项目——数据库输入输出数据不一致
2. 项目名称：【项目名称+项目版本号】
3. Bug所属项目/模块：Bug所属项目和模块，最好能较精确地定位至模块；
4. 严重等级：【紧急，严重，一般，微小】
l 紧急Bug：造成系统或应用程序崩溃(Crash)、死机、系统悬挂，或者造成数据丢失、主要功能完全丧失等。
l 严重的Bug：功能或者特性没有实现，主要功能部分丧失，次要功能完全丧失，或者致命错误声明。
l 一般的Bug：不太严重，虽然不影响系统的基本使用，但没有很好地实现功能，没有达到预期效果。如：次要功能丧失，提示信息不太准确，或用户界面差，操作时间长等。
l 微小的Bug：对功能几乎没有影响，产品及属性仍可使用，如有个错别字、文字排列不整齐等。
5. 优先级：【P1，P2，P3，P4】
P1：立即解决，导致系统几乎不能使用或测试不能继续，需要立即修复；
P2：高优先级，严重，影响测试，需要优先考虑；
P3：正常排队，需要正常排队等待修复；
P4：可以在开发人员有时间的时候再纠正；
6. Bug状态：【New，Open， Fixed， Rejected， Delay ，Closed， Reopen】
l New: 新发现的bug，开发人员尚未确认；
l Open：确实是bug，并认为需要修改，指派给相应的开发人员；
l Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证；
l Rejected：如果认为不是bug，则决绝修改；
l Delay：暂时不修改或者暂时不能修改，则延后修改；
l Closed：fixed状态的Bug经测试人员回归测试验证通过，则关闭Bug；
l 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，使用图片，错误日志等必要的附加；对于软件崩溃等现象，需要捕捉到日志文件作为附件提供给开发人员。