BUG单填写规范.docVIP

BUG单填写规范 文档名 版本号 完成日期 作者/修改人 校对 评审 BUG单填写规范 V1.0 2012-11-05 王雪 鞠晓勤 报告软件测试错误的目的是为了保证修复错误的人员可以重复报告的错误，从而有利于分析错误产生的原因，定位错误，然后修正之。因此，报告软件测试错误的基本要求是准确、简洁、完整、规范。 以下概括了报告测试错误的规范要求，简洁、准确，完整，揭示错误实质，记录缺陷或错误出现的位置准确反映错误的本质内容，简短明了。点击导航上的“登录”在邮箱地址框输入注册邮箱—给缺陷的提出人员、后续跟踪、拒绝—给缺陷的解决者、已关闭、已修正和重新打开，可下拉选择。新建缺陷时，缺陷状态的默认值为新建，被分配到bug的人员（一般为开发或者产品）如果认为此bug不是bug，可以将缺陷状态改为返回—给缺陷的提出人员。对于一些偶发性的bug，开发人员无法复现或者测试人员暂时无法确认bug是否已修复的bug，可将缺陷状态改为后续跟踪。开发人员接受这个bug后，则将缺陷状态改为打开，修复完成后，将缺陷状态改为已修正，并将bug指回给bug提出的人员（一般为测试人员），bug提出人员确认bug修复后，将bug状态改为已关闭，如果经过确定后没有修复，则将缺陷状态改为拒绝—给缺陷的解决者（如果测试人员对被返回的bug有异议，也可以使用此缺陷状态）。如果已经关闭的bug需要重新打开，则可将缺陷状态置为重新打开。 4、 实际修复时间，bug从新建到已修正的总时间，以小时为单位，QC会自行计算，也可以自己手动填写。 5、 Root_Cause，产生bug的原因，由bug的解决者填写，一般来说1、2级的bug必须要填写，其他等级的bug最好也能填写。 6、 解决人员，解决bug的人员。 7、 测试日期，提交bug的日期，默认为当天。 8、 抄送，除了被分配bug的人外，可能还需要其他人员来关注这个bug，这时可选择/填写bug需要抄送的人员。 9、检测于版本，提交bug时项目所处的版本。 10、优先级，bug处理的优先级，共有3个等级，高、中和低。 11、系统，选择bug出现的操作系统，win7，xp，mac等。 12、解决方案，解决方案有6项，分别是无法复现、已修复、重复缺陷、不解决、设计如此和推迟解决。主要是开发或者产品在处理bug的时候需要选择此项，且不同角色拥有不同的选择解决方案的权限，开发人员和测试人员只有选择无法复现、已修复、重复缺陷的权限，产品人员拥有选择所有解决方案的权限。 13、修复于版本，bug修复的时候项目所处的版本，主要是开发人员填写。 14、关闭于版本，bug关闭的时候项目所处的版本，主要是测试人员填写。 15、添加附件，可上传图片、文档等，可以帮助他人更为直观的理解bug所要表达的意思，也是给出了一个bug确实存在的证据（尤其是一些偶发性的，或者开发无法复现的bug）。 注意事项： 1. 描述，简洁、准确，完整，揭示错误实质，记录缺陷或错误出现的位置描述要准确反映错误的本质内容，简短明了。为了便于在软件错误管理数据库中寻找制定的测试错误，包含错误发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。 　　2. 明确指明错误类型：布局、翻译、功能、双字节根据错误的现象，总结判断错误的类型。例如，即布局错误、翻译错误、功能错误、双字节错误，这是最常见的缺陷或错误类型，其他形式的缺陷或错误也从属于其中某种形式。 　　3. 短行之间使用自动数字序号，使用相同的字体、字号、行间距 　　短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。 　　5. 每一个步骤尽量只记录一个操作 　　保证简洁、条理井然，容易重复操作步骤。 　　6. 确认步骤完整，准确，简短 　　保证快速准确的重复错误，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。 　　7. 根据缺陷或错误类型，选择图象捕捉的方式 　　为了直观的观察缺陷或错误现象，通常需要附加缺陷或错误出现的界面，以位图的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反 映缺陷或错误本质，可以捕捉缺陷或错误产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或错误位置，通常要求附加中英文对照图。 　　8. 附加必要的特殊文档和个人建议和注解 　　如果打开某个特殊的文档而产生的缺陷或错误，则必须附加该文档，从而可以迅速再现缺陷或错误。有时，为了使缺陷或错误修正者进一步明确缺陷或错误的表现，可以附加个人的修改建议或注解。 　　9. 检查拼写和语法错误 　　在提交每条缺陷或错误之前，检查拼写和语法，确保内容正确，正确的描述错误。 　　10. 尽量使用业界惯用