BUG 规范

BUG 规范

一、BUG编写规范

ØBUG的summary描述需简明扼要，例如：“上传文档：输入超长字符，系统出黄页！”。

Ø由于输入特殊字符而出现的BUG，BUG的Description或summary中应写明是哪些字符。

Ø相同的BUG出现在不同的界面或模块，应在summary中写明哪些界面或模块也出现此问题，不应书写多条BUG（若书写为多条BUG则把后面书写的标成已存在，验证后再关闭）。

Ø若不能定位BUG出现的原因，应写明所使用的帐号与当时的操作步骤。

Ø在第一次执行测试时尽量写出所有发现的问题及建议，包括记录当时的机器和环境（包括内存使用情况、使用的浏览器和输入法等），以及出错前的操作步骤和出错后的现象（截图）

Ø若BUG描述不能说明清楚，应给上相关的附件截图或数据；可以描述清楚的BUG，在有附件的情况下也应一并放入，并在BUG的Description中加上文字描述（如：附件１：导出EXCEL前，附件2 ：导出EXCEL后）。

Ø若在测试过程中，没能及时记住BUG的操作步骤，应先记录下该BUG，然后在记起时将BUG描述书写完整，并告知开发人员使之进行处理。

Ø在测试过程中，若遇到严重问题应该及时告知开发人员，并让其尽早进行处理。

Ø对于所发现的问题不太清楚是不是BUG，可与策划以及相关开发人员确认，或者询问测试组负责人或测试跟进人员。

Ø在选择BUG的Severity(严重级别)时，应注意根据BUG的严重程度来确定，理清建议与BUG的意义，（建议：可修复也可不修复，修复了会更好，不修复也可以）不应将建议写成BUG，或将BUG写成建议。——BUG严重级别定义详见附录

Ø如果在游戏中出现报错的情况，要把错误信息复制出来，然后描述是在哪里报的错误，出错的操作步骤