BUG_描述规范.docx

系统文档BUG描述规范一、 目的与适用范围1.1 目的报告软件测试错误的目的是为了保证修复错误的人员可以明确报告的错误，从而有利于分析错误产生的原因，定位错误，然后修正之。因此，报告软件测试错误的基本要求是准确、简洁、完整、规范。1.2 适用范围本规范适用于测试过程中对BUG描述的规范与约束。二、 BUG描述规范1. 描述：简洁、准确，完整，揭示错误实质，记录缺陷或错误出现的位置描述要准确反映错误的本质内容，简短明了。为了便于寻找指定的测试错误，描述中要包含错误发生时的用户界面（UI）。例如记录对话框的标题、菜单、按钮等控件的名称。 2. 明确指明错误类型：布局、翻译、功能等 ；根据错误的现象，总结判断错误的类型。例如，布局错误、翻译错误、功能错误、双字节错误，这是最常见的缺陷或错误类型，其他形式的缺陷或错误也从属于其中某种形式。 3. 短行之间使用自动数字序号，使用相同的字体、字号、行间距； 短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。 4. UI要加引号，可以单引号，推荐使用双引号； UI加引号，可以容易区分UI与普通文本，便于分辨、定位缺陷或错误。 5. 每一个步骤尽量只记录一个操作；保证简洁、条理井然，容易重复操作步骤。 6. 确认步骤完整，准确，简短； 保证快速准确的重复错误，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。 7. 根据缺陷或错误类型，选择图象捕捉的方式； 为了直观的观察缺陷或错误现象，通常需要附加缺陷或错误出现的界面，以位图的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或错误本质，可以捕捉缺陷或错误产生时的全屏幕，活动窗口和局部区域。 8. 附加必要的特殊文档、个人建议和注解； 如果打开某个特殊的文档而产生的缺陷或错误，则必须附加该文档，从而可以迅速再现缺陷或错误。有时，为了使缺陷或错误修正者进一步明确缺陷或错误的表现，可以附加个人的修改建议或注解。 9. 检查拼写和语法错误； 在提交每条缺陷或错误之前，检查拼写和语法，确保内容正确，正确的描述错误。 10. 尽量使用业界惯用的表达术语和表达方法； 使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。 11. 通用UI要统一、准确； 错误报告的UI要与测试的软件UI保持一致，便于查找定位。 12. 尽量使用短语和短句，避免复杂句型句式； 软件错误管理数据库的目的是便于定位错误，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。 13. 每条错误报告只包括一个错误； 每条错误报告只包括一个错误，可以使错误修正者迅速定位一个错误，集中精力每次只修正一个错误。校验者每次只校验一个错误是否已经正确修正。三、BUG的类型划分1、功能类A.重复的功能B.多余的功能C.功能实现与设计要求不相符D.功能使用性、方便性、易用性不够2、界面类A.界面不美观B.控件排列、格式不统一C.焦点控制不合理或不全面3、数据处理类A.数据有效性检测不合理B.数据来源不正确C.数据处理过程不正确D.数据处理结果不正确4、流程类A.流程控制不符和要求B.流程实现不完整5、提示信息类A.提示信息重复或出现时机不合理B.提示信息格式不符和要求C.提示框返回后焦点停留位置不合理6、建议类A.功能性建议B.操作建议C.检校建议D.说明建议7、性能类A.并发量B.数据量C.压缩率D.响应时间8、常识类A.违背正常习俗习惯的，比如日期/节日等9、特殊类A.不符合OEM版本或DEMO版本特殊要求的四、BUG状态已提交：测试员发现BUG后提交到BUG管理系统中的状态。（初始状态）已修改：在修改了BUG后提交到BUG管理系统中的状态。不修改：程序员或根据需求分析、概要设计、详细设计说明书等上的要求经过考虑后决定对BUG不进行修改。其BUG的状态为不修改，需要说明理由。延迟：根据目前项目进程或计划等情况，暂时延期的状态待讨论：需要进行讨论后才能决定是否需要修改的BUG的状态。已验证：已经解决的并经过测试员复测的BUG的状态。关闭：完全解决了，只供以后备查的状态重新打开：重新出现在新的版本中，重新打开以前关闭的bug状态(当然在bug工具中，可以自己定制适合项目的状态项目，比如废除，拒绝等)1、严重：死机，数据丢失，主要功能完全丧失，系统悬挂等错误。修改优先级为最高，该级别需要程序员立即修改。2、较高：主要功能丧失，导致严重的问题，或致命的错误声明。修改优先级为高，该级别需要程序员尽快修改。3、一般：次要功能丧失，不太严重，如提