BUG提交模板

软件测试BUG提交规范_模板BUG提交模板和注意事项一、BUG提交模板1.现象描述<详细描述BUG现象>2.组网环境<组网图及简要说明：机箱、板卡（型号、序列号和槽位）、测试仪、连接线缆等描述> 注：简单组网环境或一般性BUG情况下，可只简要描述组网环境，无需组网图。

3.版本信息<被测设备所有组件版本信息>软件版本：硬件版本：芯片版本：CPLD版本：MCU版本：uboot版本：4.操作步骤<详细描述发现BUG的操作步骤>注：说明发现BUG对应用例名称编号或为非用例发现BUG。

5.期望结果<预期正确的结果>6.实际结果<实际不正确的结果>7.BUG严重性等级<初步判定BUG的严重性等级>8.开发确认情况<开发确认BUG情况描述及确认人>注：严重等级以上BUG必须要有开发人员确认9.附件<包括：组网图、BUG现象截图、操作产生的系统日志等>注：严重等级以上BUG必须带有附件，一般性BUG则附件可选。

10.备注二、BUG提交注意事项1．请测试人员提交新缺陷时，尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、（建议），并尽量截图；2. 当你的BUG报告以“not repro（不可重现）”打回给你时，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语，再检查是否有遗漏或清晰的步骤，再去找研发人员。

研发人员通常是在无法用BUG报告中的步骤重现BUG时才选择这个选项；3. 测试人员在精简空话的同时，应该再仔细检查报告是否会产生误解的地方。

测试人员应该尽量避免使用模糊的，会产生歧义的、主观的词语。

目标是使用能够表述事实、清楚的，不会产生争执的词语；4. 不要使用感叹号或其它表现个人感情色彩的词语或符号；5. 不要使用含糊的词语（例如，好像，似乎）或网络语言来描述发现的现象；三、需要注意的地方当你发现一个BUG时，请考虑如下问题：1. 同一软件中的相似功能是否有相同的问题？2.其他的浏览器是否有相同的问题？3. 其他的软硬件配置是否有相同的问题？4. 其他的区域是否有相同的问题？5.以前的版本是否有相同的问题？四、Bug的严重等级1.致命BUG，包括以下各种错误：1.由于程序所引起的死机,非法退出2.死循环3.导致数据库发生死锁4.因错误操作导致的程序中断5.严重的数值计算错误2.严重BUG，包括以下各种错误：1.功能不符2.数据流错误3.程序接口错误4.轻微的数值计算错误3.一般性BUG，包括以下各种错误：1.操作界面错误(详细文档)2.打印内容、格式错误3.简单的输入限制未放在前台进行控制4.删除操作未给出提示4.提示性BUG，包括以下各种错误：1.界面不规范2.辅助说明描述不清楚3.显示格式不规范4.长时间操作未给用户进度提示5.提示窗口文字未采用行业术语6.可输入区域和只读区域没有明显的区分标志7.系统处理未优化5.测试建议（非BUG）：界面重构、描述更改、流程改进。

资产管理系统bug缺陷报告
缺陷报告单是任何缺陷修改的一个起始，也就是我们测试人员在进行测试执行的时候，发现缺陷后，我们不要口头和开发人员交流，因为口头的交流不仅没有任何的约束力，而且有可能表达不清楚，所以我们要把缺陷落实在纸面上，也就是要测试人员填写缺陷报告单。

缺陷报告单包含：
1.模板名称：用户注册
2.版本号：v1.1
3.缺陷类型：功能错误
4.可重复性：是
5.测试平台：win xp Professional
6.简述：系统规定注册用户名长度为6-20字符，至少6个字符的用户名注册
7.操作步骤：一，进入xxx购物电商网首页，
二，单机“注册”按钮，进入用户注册协议页面，
三，单机“同意”按钮，进入用户注册信息页面，
四，按要求输入相关信息，
五，点击“提交”按钮，提示注册成功
8.实际结果：提示用户名错误，不能注册成功
9.预期结果：注册成功
10.测试人：xxx
11.严重级别：B
12.缺陷状态：New
13.浏览器：IE8.0
14.提交人：xxx
15.提交时间：2018-09-10
16.注释：建议修改
如图所示：。

1．建议的格式――――――――――――――――――――――――――――――――Summary××××××DescriptionActions1. ××××××2. ××××××3. ××××××Actual Result××××××Expected Result（可选）××××××2．注意点：――――――――――――――――――――――――――――――――1. 缺陷摘要（Summary）简单明了，便于理解长度一般不超过30个单词尽可能讲明：什么情况，导致了什么问题以便于他人定位Bug，杜绝不重复报相同的Bug2. 缺陷描述（Description）重现步骤（Action）详细描述重现该问题的关键步骤省略无关的操作，力求做到：所有重现步骤是充分的和必要的容易理解的常规步骤，可以一句话带过，比如“以管理员身份登录，进入后台用户管理页面”和环境有关的问题，给出特定的条件，比如某某操作系统，某某浏览器实际结果（Actual Result）描述实际出现的错误结果可借助截屏来表达不是总能重现的Bug，给出发生频率或规律预期结果（Expected Result）可选，Spec上没有做详细要求，用于测试人员表达自己的看法3. 截屏/附件（Attachment）针对文字难以表达的或UI方面的问题图片格式使用JPG格式；BMP图片太大，不建议使用在图片上用醒目的颜色，标出问题所在区域也可考虑配上简短的文字4. 其它对于多人同时测试同一模块的情况，报Bug前先检查是否已有类似的Bug (TD 提供了Find Similar Defects的功能)Bug严重程度(Severity)必须准确Bug优先级(Priority) 必须准确（具体请参考公司标准文档）填写Module字段，便于Dev Manager 分配给相应的开发人员项目中共性的问题，纳入Common Module多个相同的问题，如是一个Dev负责完成的，撰写一个缺陷报告就可以，但须列出问题所在的多个位置对于Reject的有争议的Bug，尽可能和Dev当面沟通Windows截图快捷键:截图类型截图快捷键说明全屏幕PrintScreen 键当前活动窗口ALT + PrintScreen 键按住Alt 键，然后按下PrintScreen 键局部窗口系统不支持可借助截屏软件，如HyperSnap。

提交bug的标准及书写规范Bug有效性1、交付过程中测试者需按照专家设定好的模块，对Bug进⾏归类提交；2、Bug的类型默认为UI问题、功能问题、崩溃问题，提交Bug时不能弄错；3、需求是否明确、前提条件是否满⾜、输⼊数据是否正确、操作步骤是否清楚、Bug是否唯⼀性；4、避免提交设计如此、操作错误、重复的、已知的Bug；5、尽量少花时间在边界值、页⾯显⽰问题上，多提业务逻辑功能、交互测试⽅⾯的问题；Bug标题Bug标题要求简明扼要的阐述问题本质，使查看⼈员能快速了解Bug内容。

需要写明在哪个页⾯执⾏什么操作出现什么现象。

特别提醒：1.标题中标点符号不能超过1个2.标题中不能含有测试流程步骤和模块信息测试设备：提交Bug要表明测试使⽤的设备、设备操作系统版本、测试环境、⽹络类型等等。

前提条件明确指出所提交的Bug是在怎么样的情况下出现的，当所发现Bug前提条件为空时，需要填【⽆】。

测试步骤要简明清晰分步骤描述如何复现Bug问题，步骤⽤序号编排。

要按照⾃⼰的操作的实际步骤写清楚每⼀步是怎么操作的，最后操作到哪个页⾯或者点击哪个按键。

如在特定情况下发⽣的问题，还需明确提供以下信息：1.准确写出连续点击次数，点击时长与上下滑动屏幕时长。

2.对于特定数据产⽣的问题，提供具体数据。

3.精准描述bug产⽣的路径后，再描述现象。

特别提醒：测试步骤中的点击要⽤->符号连接期望结果按照测试步骤应当得到的正确结果，按照产品需求的期望清晰准确的填写预期结果。

⽽且结果必须是肯定⽆疑义，可判定性的结果。

特别提醒：期望结果不要包含测试步骤，要是简单的⼀个结果实际结果按照测试步骤实际出现的错误结果，避免使⽤“不正常”，“有误”等模糊词汇，需要直接描述实际现象。

特别提醒：期望结果和实际结果要相互对应复现步骤描述及概率描述复现步骤中的页⾯切换为避免出现描述不清晰或者有歧义，需⽤“->”符号连接关于复现概率⼀定要在多次测试的基础之上填写，若必定复现则填写100%，若偶现，请执⾏多次后统计概率填写。

Bug分析报告模板1. 引言本文档是针对某个软件或系统中存在的Bug进行分析和解决的报告模板。

通过对Bug的详细描述、重现步骤、环境信息以及解决方案等内容的记录，旨在帮助开发人员更好地理解和修复Bug。

2. Bug描述2.1 Bug概述在这一部分，我们对所发现的Bug进行简明扼要的概述，以便开发人员能够快速了解问题的性质。

请注意，确保不要使用敏感的术语。

2.2 Bug详细描述在这一部分，我们对Bug进行更加详细的描述，包括观察到的不正常行为、期望的行为以及可能的原因。

请确保所述问题具体清晰，以便开发人员能够准确理解。

3. Bug重现3.1 重现步骤在这一部分，我们详细记录如何重现Bug，包括具体的操作步骤和环境条件。

请确保描述准确，以便开发人员能够按照步骤重现问题。

3.2 预期结果在这一部分，我们描述在正常情况下，应该得到的期望结果。

请确保描述明确，以便开发人员能够明白问题所在。

3.3 实际结果在这一部分，我们记录在重现Bug时所观察到的实际结果。

请确保描述准确，以便开发人员能够对比预期结果和实际结果。

4. 环境信息在这一部分，我们提供相关的环境信息，以帮助开发人员更好地定位问题。

4.1 操作系统请详细描述所使用的操作系统的类型、版本以及其他相关信息。

4.2 软件版本请提供相关软件的版本号、构建号以及任何相关的特定信息。

4.3 硬件信息请提供任何与Bug相关的硬件信息，如设备型号、配置等。

5. 附加信息在这一部分，我们提供任何其他可能与Bug相关的信息，如日志文件、错误消息等。

请确保提供准确、有用的信息以帮助开发人员进行分析和解决。

6. 解决方案在这一部分，我们提供解决Bug的方案和建议。

请确保解决方案清晰明了，以便开发人员能够快速理解并进行修复。

7. 总结在这一部分，我们对整个Bug分析报告进行总结，并再次强调Bug的重要性和紧急性。

请确保总结简洁明了，以便开发人员能够快速了解问题的严重程度。

缺陷编号摘要描述缺陷严重程度提交人
1在新增资产中不显示
新增加的存放地点，
只显示系统默认的存
放地点
浏览器：IE11
浏览器版本：11.0.29
1、超级管理员登录，添
加新的存放地点
2、资产管理员登录，进
入新增资产界面
3、在其中不显示新增的
存放地点，只显示系统默
认的存放地点
高张明
填表说明：
1、缺陷编号：从1开始，顺序递增
2、摘要指：说明缺陷的处理和缺陷的表现形式简单说明
3、描述：说明该缺陷是如何产生的，需要分步骤写明
4、缺陷严重程度
严重：导致系统无法使用
很高：出现系统级错误
高：功能性错误
中：界面错误
低：提示信息错误或其他文字错误
5、提交人：发现bug的测试工程师的名字
6、附件说明：将错误的界面内容截屏拷贝到bug报告中
附件说明。

Bug 提交规范如图BUG发现处理流程（WOStore）：1）提交BUG指派给：Active抄送：（此处目前不需要）2）BUG分配由郝伟琪负责根据模块不同的负责人，分配到不同开发人员。

3）BUG修复由分配的开发人员负责修复BUG。

并将状态更改为已经修复同时将指派给更改为BUG提交者。

4）BUG验证由BUG提交者验证BUG是否已经解决，如果已经解决则将BUG状态更改为已经解决和关闭。

说明：1.Build Version 填写格式其中版本号由3位版本序列号和BUILD日期构成，例如：V0.1.2(2010-07-29)查看版本号：黄色为软件版本号，可以在软件的“关于”中找到红色部分为此版本发布的日期2.机器配置格式此处填写所测手机的品牌+型号（例如：dopod S610）3.Bug严重级别(Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响程度。

由测试人员指定。

开发和测试统一成一个bug级别分类，取消bug优先级。

类型描述举例1级我们的软件产品错误导致了死机、产品失败（“崩溃”）、造成软件运行受阻无法运行。

与移动产品规范不符合。

1.死机，重启，飞信登陆失败2.web：页面无法打开2级产品中出现的一般性问题，主要是造成功能失效，或者会引起操作上重大误解的。

1.输入法引起用户的误操作2.Web：页面链接无法打开3级产品在设计和开发中由于考虑不周引起的问题，即可能会造成系统在使用中会出错的隐患或造成使用中会产生歧义的。

1.输入法对于有键盘的手机和无键盘的手机区别2.LG手机高亮之后字体颜色和背景颜色一样。

3.应该输入数字的地方能够输入英文或者字符。

4.web：页面排版问题4级错误是表面化或微小的（提示信息不太准确友好、错别字、罕见故障等），对功能几乎没有影响，产品及功能仍可使用；错别字4.Bugfree中一个Bug的处理过程新建一个Bug后，或者查询出符合条件的Bug们点击一个后，【右栏】显示该Bug详细信息。

Bug提交规范说明文档编号： Bug提交规范说明密级： [内部资料]部门：测试部版本编写人/修改人日期说明V1.0 王宝静2006-04-07 初稿V1.1 王宝静2006-07-28 更新V1.2 刘丽2007-01-08 修改文档适用于BUGZILLA修改BUG状态bug提交规范目录一引言 (2)1.1 编写的目的 (2)1.2 定义 (2)二Bug的组成因素 (2)2.1 产品名称和组件名称 (3)2.2 版本 (3)2.3 Bug类型（由研发部标识） (3)2.4 关键字 (3)2.5 Bug状态 (4)2.6 Bug优先级（由产品部标识） (4)2.7 Bug摘要 (4)2.8 Bug描述 (5)2.8.1 能重现的bug (5)2.8.2 不能重现的bug (5)2.9 附件 (6)三提交格式规范 (6)四引发问题追朔版本标准 (7)五附录 (8)1 引言1.1 编写的目的RedOffice产品的多元化发展，bug数量的日益增多，那么提交bug的规范要求自然就要孕育而生。

经与研发部门相关负责人沟通后，制定了以下提交bug的一系列规范，希望测试人员能够严格按照此规范提交问题。

1.2 定义我们一般把操作过程中发现不正确结果的问题称为bug。

2 Bug的组成因素为了便于bug的管理、修改、查看，每条bug必须包含以下因素：产品名称+组件名称+版本+产生时版本+类型+关键字+操作系统+级别+Bug 摘要+Bug描述+附件其中红色字因素书面的测试报告中不必包含，蓝色字因素提交到Bugzilla 中时不必包括，但书面报告中要求涵盖。

2.1 产品名称和组件名称产品名称：针对不同项目的不同立项；组件名称：针对不同项目所划分的不同测试方向；其中有关RedOffice的项目涉及到的组件名称，参见“svn://172.20.69.219/test/TTech/测试控制文档/测试规范”目录下的《RO40 Component.mht》。