软件测试-BUG规范.doc

BUG 规范 一、BUG编写规范 BUG的summary描述需简明扼要，例如：“上传文档：输入超长字符，系统出黄页！” （应尽量少出现不肯定的词语，如：是否）。 由于输入特殊字符而出现的BUG，BUG的Description或summary中应写明是哪些字符。 相同的BUG出现在不同的页面，应在summary中写明哪些页面也出现此问题，不应书写多条BUG（若书写为多条BUG则在前面打上记号如“--”，方便删除）。 若不能定位BUG出现的原因，应写明操作时所使用的帐号与操作步骤。 在第一次执行测试时尽量写出所有发现问题及建议。 若BUG描述不能说明清晰应夹带附件（有附件也应夹带附件），并在BUG的Description中加上文字描述（如：附件１：导出EXCEL前，附件2?：导出EXCEL后）。 若在测试过程中，不能及时记住BUG的操作步骤，应在记起时将BUG书写完整，并致电告知开发人员使之进行处理。 在测试过程中，若遇到严重问题应该致电告知开发人员使之尽早进行处理。 对于所发现的问题不太清楚是不是BUG，可打电话与开发人员确认，或者询问测试组负责人或测试跟进人员。 在选择BUG的Severity(严重级别)时，应注意根据BUG的严重程度来确定，理清建议与BUG的意义，（建议：可修复也可不修复，修复了会更好，不修复也可以）不应将建议写成BUG，或将BUG写成建议。——BUG严重级别定义详见附录 二、验证BUG 在验证BUG时，RD Comments应注明验证时的实际输出结果，方便日后跟踪及统计。 在验证BUG时，应查看History，查明BUG修改的时间，避免将刚Fixed的BUG重新Reopen。 在验证BUG时，若原有的BUG未修复，则应该Reopen；若原有的BUG所描述的现象已不存在，则Closed；若由于对原有BUG的修改而引发新的BUG，则应该Open记为新的BUG，不应将原有的BUG再Reopen。 在验证BUG时，除验证状态为Fixed的BUG外，应同时验证其它状态（如Next、Rejected、Open等）的BUG。 在验证BUG时，若发现Reopen点错的情况，应将点错Reopen的Deffect Id记录下来，并通知测试跟进人员。 附：BUG的严重级别（Serverity） 0-Suggestion（建议） 1 文本框输入html标识符而导致系统跳转到错误提示友好页面，严重级别选择Suggestion。 2 文本框输入一长串无意义的字母或数字后，导致界面变形，严重级别选择Suggestion。 3 界面描述或提示表达不清晰，但意义基本正确，严重级别选择Suggestion。 1-Low（缺陷） 1 文本框正常输入一段或多段中文或英文字符后，导致界面变形，严重级别选择Low。 2 不影响系统正常功能实现的问题。 3 界面及操作问题：界面不规范（如：图片变形或不符合要求的规格）、页面辅助说明或提示窗口文字表述错误或不当（用户无法理解）、功能操作不方便或无故特殊化、输入输出不规范、长时间操作未给用户提示、可输入区域和只读区域没有明显的区分标志、简单的输入限制未放在前台进行控制。 4 字符检测问题：必填项检测错误、字符长度检测错误、特殊字符串检测错误。 2-Medium（一般错误） 1 主要功能运作不完全。 2 不影响下一步测试的问题。 3 导致系统次要数据错误或损坏。 4 次要功能未能正常实现，如无法上传文件。 3-High（错误） 1 主要功能未能正常实现。 2 产生的问题导致系统主要功能不正常或者中断，无法继续测试。 如：程序错误、程序接口错误、业务规则错误、数据库表缺省值未加完整性约束条件等。 3 导致系统处理结果或主要数据错误或损坏。 4-Very High （严重错误） 严重错误，并且破坏数据。 5-Urgent （紧急错误） 系统崩溃。如：由于程序所引起的死机，非法退出、死循环、数据库发生死锁、因错误操作导致的程序中断、功能错误、与数据库连接错误、数据通讯错误。 6-Risk （风险） 根据系统既定的数据或程序处理方式（若可进行完善则不应列入风险），结合用户使用情况，提出系统特殊情况下使用时可能出现的问题。 BUG规范V1.0 第 1 页 共 4 页