BUG提交模板
软件测试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缺陷报告
资产管理系统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.注释：建议修改
如图所示：。
bug的格式模板
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清单模板
后续下拉 的 显 示 顺 序
列表填充 没 有 有 效 控
自定义排 制。
序的下拉
选择
1、点击系
统管理；2 点击“重
、点击数 置”按 编 辑 数 字 字
字字典；3 、找到一 个节点， 点击编辑 子节点， 输入若干
钮，字典 类型可以 清空，然 后可以重 选或者字 典类型不
资讯管理 /博物馆 沿革
资讯管理 /博物馆 沿革
资讯管理 /简介管 理
资讯管理 /简介管 理
资讯管理 /馆藏文 物
资讯管理 /馆藏文 物
资讯管理 /馆藏文 物
资讯管理 /馆藏文 物
资讯管理 /馆藏文 物
资讯管理 /馆藏文 物
资讯管理 /馆藏文 物
日期格式的输入统 一显示
高
无条件输入，点击 搜索的提示
中
扩展阅读表单时间 的正确显示
高
BWG_14 BWG_15 BWG_16 BWG_17 BWG_18 BWG_19
BWG_20
资讯管理 /扩展阅 读
资讯管理 /扩展阅 读
资讯管理 /扩展阅 读
资讯管理 /博物馆 沿革
资讯管理 /博物馆 沿革
资讯管理 /博物馆 沿革
发布日期对应时间 点正确同步显示
高
钮，没有响
选择年代 后，不可选 和不可输入 。
排序号的区 间输入选择 不正确。
讯管理， 点击馆藏 文物；2点 击“新增
正常有视 频的上传 功能
文物视频的 上传功能失 效。
”
这个和其
他同一级 馆 藏 文 物 对
目录资讯 管理的纵 向比较， 管理操作 使用一致
于整体资讯 管理的新增 、编辑、删 除功能使用 一致性体验 较差。
提交bug的标准及书写规范
提交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分析报告模板
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的重要性和紧急性。
请确保总结简洁明了，以便开发人员能够快速了解问题的严重程度。
Bug提交模版
缺陷编号摘要描述缺陷严重程度提交人
1在新增资产中不显示
新增加的存放地点，
只显示系统默认的存
放地点
浏览器：IE11
浏览器版本：11.0.29
1、超级管理员登录，添
加新的存放地点
2、资产管理员登录，进
入新增资产界面
3、在其中不显示新增的
存放地点，只显示系统默
认的存放地点
高张明
填表说明：
1、缺陷编号：从1开始，顺序递增
2、摘要指：说明缺陷的处理和缺陷的表现形式简单说明
3、描述：说明该缺陷是如何产生的，需要分步骤写明
4、缺陷严重程度
严重：导致系统无法使用
很高：出现系统级错误
高：功能性错误
中：界面错误
低：提示信息错误或其他文字错误
5、提交人：发现bug的测试工程师的名字
6、附件说明：将错误的界面内容截屏拷贝到bug报告中
附件说明。
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提交列表是否紧急需紧急修改请套所产生bugbug内容描述是否完成修1
测试BUG提交列
是否紧急 （需紧急修 改请套红） 紧急
所产生BUG
BUG内容描述
首页登录问题
首页登陆状态没有！
提示商品没有了
1.点击购买东西的时候 没提示商品没有了 但是提交订单的时候说没 有了！ 但是回到主页依旧能买！！！！（之前在订单里修改了下数 增加视频后，上层标题栏出现“复鼠标箭头一直手形
进入主页，鼠标始终一个手形 点击修改，没有把原有的缩略图路径和视频路径加载上去，修改不方 便；使用前台页面删除视频后，后台没有显示该视频已经被删除的标 志，未做判断。
视频编辑和删除有问题
试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》。
Bugfree提交BUG的书写规范_0907
Bug提交规范一、描述规范：执行哪几个操作步骤可以重现一个什么样的BUG(测试结果)，这个问题在需求或交付标准中是如何界定的（预期结果）！二、书写规范1. 每条错误报告只包括一个错误；2. 如果打开某个特殊的文档而产生的缺陷或错误，则必须附加该文档，从而可以迅速再现缺陷或错误。
3. 为了使缺陷或错误修正者进一步明确缺陷或错误的表现，可以附加个人的修改建议或注解。
4. 需与需求中要求的结果一致，若需求不明确需注明；5.对于无法重现之BUG需与测试负责人沟通确认是否提交6.对于难以重现的BUG需确认其出现几率，统计测试次数及BUG出现次数，记录测试环境及测试步骤，便于开发人员定位。
7.在BUG描述中不能出现不明确的字句，所有无法确认的结果都需要提交科学的测试数据，以数据体现其结果，以便定位问题。
三、明确责任人需明确BUG指派给谁，一般是直接指派给开发人员，当项目紧急仅需要部分重要bug时，可将所有bug指派给项目经理，有项目经理过滤优先级后再指派给具体的开发人员。
五、明确BUG 严重等级和优先级严重程度：①严重——引起系统崩溃，死机，卡死等情况的BUG②主要——影响系统功能操作，主要功能错误或未实现的BUG③次要——界面上或性能上的BUG④轻细——操作体验或建议性的BUG优先级：①紧急——需立即处理完成的BUG②尽量加快——需尽快处理完成的BUG③按时——正常等待按时处理的BUG④轻细——有时间再处理的BUG六、BUG修改者明确解决方案无效BUG：By Design——需求设计如此Duplicate——这个问题别人已发现，重复的BugNot Repro——无法复现的问题有效的BUG：Fixed——问题被修复External——外部原因（如浏览器、操作系统、其他第三方软件）造成的问题Postponed——发现的太晚，或问题在此版本不关注，可在下一个版本讨论是否解决Won’t Fix——是个问题，但不值得修复。
Bug提交标准规范
Bug提交标准规范JIRA管理软件提交的bug做到：言简意赅，语意明确bug报告内容：产品模块选择产品模块项目选择项目主题填写该缺陷名称，在提交bug时，bug主题要描述言简意赅，语意明确，让开发人员一眼看出哪里有问题。
优先级选择优先级所属项目选择所属项目影响版本当前指派选择指派给开发人员Bug标题填写该缺陷名称，在提交bug时，bug标题要描述言简意赅，语意明确，让开发人员一眼看出哪里有问题。
如：龙旅在线前台系统->修改个人资料，修改用户名姓名“XX”改为“张三”重现步骤步骤自动生成，可进行修改，内容需尽可能详细，使开发人员可以重现该bug。
如有前置条件请说明前置条件：如特定的操作方式，特殊的用户，特殊的浏览器等，能有利于bug复现的操作尽量进行提供。
如：前置条件：系统登录成功，使用登录账号：zhangcui 密码：asd123 浏览器：firefox操作步骤：1、点击“修改个人资料”2、修改姓名为“张三”3、点击“保存”预期结果：保存成功，姓名修改为“张三”实际结果：提示保存失败！数据库存储相关的bug（和设计的字段不符合，和设计的长度不符合等）需要以bug记录。
其他存储，如redis相关的需要以bug进行记录。
相关需求：有相关需求则选择相关需求，么有则不选择相关任务：有相关任务则选择相关任务，没有则不选择类型/严重程度：选择问题类型，根据bug定义规则判断问题严重程度（如：1：致命缺陷；2：严重缺陷；3：一般缺陷；4：轻微缺陷）系统/浏览器：选择当前测试所属系统及浏览器抄送给：可以选择要抄送的人员关键词：填写该缺陷需要注意的事项添加附件：（如：图片、word、excel、txt等文档）当有bug描述说明不清楚时，可附上截图加以说明（类型分为：1、不容易描述清晰的；2、有特殊性的如需要特殊的数据日子截图）注：bug致命和严重问题必须全部解决，一般问题不能超过3个，轻微问题小于5个方可达到上线（视情况而定）。
测试BUG记录表模板
测试BUG 记录表外呼前台1、错误描述（项目测试人填写）错误路径：客户资料截图：错误描述：1. 客户资料——添加客户资料——展开， QQ 信息一旦添加，就不能保存。
2. 客户资料——来电记录——编辑，咨询内容不能换行输入。
3. 客户资料——查询客户资料——编辑，客户资料也不能换行输入。
备注：修改反馈记录（格式：时间 + 修改情况）修改人：项目经理：错误描述（项目测试填写）截图：图三1. 通讯录——个人通讯录——添加， QQ 信息一旦添加，就不能保存， msn 格式没有验证。
如图一2. 通讯录——个人通讯录——编辑，如图二备注中换行输入内容，单击“保存”后，在列表中显示换行标记，如图三备注： 修改反馈记录（格式：时间 + 修改情况）错误路径： 通讯录2、图一错误描述：错误描述（项目测试人填写）4、错误路径：IM 即时通讯截图：错误描述： 1. 在消息文本框中输入换行的文本消息，则点击“发送”后，出现上图内容中含有换行符备注：修改反馈记录（格式：时间+ 修改情况）修改人：项目经理：错误描述（项目测试人填写）1 所示，列表内容中包含换行符5、错误路径：个人管理截图：错误描述： 1. 个人管理工作日报（每周小结）添加，换行输入，保存出现如上图2. 个人管理工作日报（每周小结）添加（添加过一次），输入内容单击保存后，最好关闭当前窗口，这样用户体验度高备注：修改反馈记录（格式：时间+修改情况）修改人：项目经理：外呼后台：错误描述（项目测试人填写）6、错误路径：截图：错误描述：1. 座席信息——座席工作组设置——添加，在弹出窗口中工作组描述文本框中不能换行输入。
如图一2. 座席信息——座席公告信息——添加。
第一次添加公告没有选择收取人，会提示选择收取人，如果勾选了收取人复选框后再勾选掉，也能添加成功。
如上图二。
（另外，没有对公告标题字数做限制，所以字数多了会出错，且公告内容不能换行输入。
）备注：修改反馈记录（格式：时间+ 修改情况）修改人：项目经理：错误描述（项目测试人填写）7、错误路径：企业信息座席信息图三 图四1. 企业信息——客户类型——添加，弹出窗口中“客户类型名称”字段没有做字符 限制，添加多了会出错， “客户类型描述”字段不能换行输入。
WEB测试提交BUG标准格式
提出问题格式
细节决定成败！望大家多多努力。
一．功能
1. 标题
详细描述
截图
测设人员：
测设时间：
出现频率：
建议：
2. 标题
详细描述
截图
测设人员：
测设时间：
出现频率：
建议：
二．界面
1. 标题
详细描述
截图
测设人员：
测设时间：
出现频率：
建议：
三．兼容性
1. 标题
详细描述
截图
测设人员：
测设时间：
出现频率：
建议：
注意细节：
1）每个问题与问题之间统一回车一次
2）图片统一规范（超出范围需调整，不要太大，小图片可整体放大）3）图片需居中对齐
4）问题数字需自动排列
5）问题需清晰、详细
6）文件名需统一，例：飞人机票频道测试结果[刘明帅2010-09-02].doc 7）此文档不足之处，提出意见在修改
例：
1.航程类型与搜索不符。
点国内联程后，在点国际单程会出现次问题！
测试人员：***
测时时间：09.02 15:44
2.机票查询页面，机票显示列表的显示其它舱位无下拉列表。
点击后没有反应，应该有所反应，提示！
测试人员：***
测时时间：09.02 16:00。
Bug报告提交规范
Bug报告提交规范⾸先声明，bug的测试规范应该在公司的正式⽂档建⽴。
本建议⾮正式⽂档，有些内容可能不正确，有些内容可能需要继续商榷，甚⾄有些内容同公司规范有冲突。
如果发现问题，直接忽略本⽂相应内容。
本帖本意仅就⼯作中的⼀些现象记录，可以通过简单规范让⼤家⼯作轻松，⾼效。
后续继续补充修改，也请⼤家补充修改。
其次，本帖也仅就填写bug报告的⾏为进⾏了⼀些梳理和建议，不能取代正式的bug测试流程或质量管理过程。
内容：填写bug报告，可能是专门的测试⼈员或者开发⼈员，甚⾄其他临时帮忙或者最终⽤户。
发现bug和解决bug是⼀件⾮常重要的⼯作。
⼤家的⽬的都是为了软件能够安全、稳定运⾏起来，提交bug的⼈同解决bug的⼈⽬标是⼀致的，⽽不是对⽴的，不是找⿇烦。
测试⼯作其实⾮常复杂和繁重，发现问题仅仅是第⼀步，更重要的是确定是bug，是不是可以重现，跟正确结果的差别在哪⾥。
最终提交的bug不要让修复者重复太多⼯作才能重现，也不要让修复者猜测或者试验⼒。
最快让修复者找到问题是关键。
如果修复者花费太长时间琢磨⼀个bug报告的重现，最好还是直接演⽰给他看，这是最有效的⽅式。
基于这些共识，我们希望达成⼀致的规范。
提交者规范建议：1.提交bug是针对真实存在的缺陷。
那些偶尔出现的bug，提交者尽量找到重现的真正原因。
如果可能，尽量在2个不同终端上可以确定重现。
如果没有2台终端，⾄少⽤2种浏览器或者2个虚拟机等⽅式模拟重现出来。
2.如果是浏览器兼容问题，确定重现步骤后，bug报告中尽量写清哪个类型浏览器，版本号，语⾔，以及设置⽅式。
3.描述清楚。
有些bug是需求没有满⾜，但是没有其他崩溃结果哦出现，尽量将“期待”的内容和“实际”的情形区别开，如，⼀个bug，⼀个按钮点击后的“需求”是打开窗⼝，实际运⾏结果是转到另外⼀个地址。
转移地址是错误的，就要告诉修复者。
⽽不是报告：这个点击按钮后转到了⼀个新地址。
修复者有时理解成需求是要转移到⼀个新地址，结果他看到的就是这个结果。
魔兽世界亚服申诉模板
魔兽世界亚服申诉模板
尊敬的魔兽世界亚服客服团队：
我是一名魔兽世界亚服的玩家，我在此向您提交一份申诉，希望您能够帮助我解决以下问题。
1. 我的账号信息：
- 账号名：[您的账号名]
- 服务器名：[您所在的服务器名]
- 角色名：[您的角色名]
2. 问题描述：
- 问题1：我在游戏中遇到了一个bug，导致我的角色无法正常进行某项任务/活动/交易等。
我已经尝试了多种方法，包括重新登录、重启游戏等，但问题仍然存在。
希望您能够帮助我解决这个问题，让我能够正常进行游戏。
- 问题2：我在游戏中遇到了一名恶意玩家，该玩家对我进行了辱骂、骚扰等行为，严重影响了我的游戏体验。
我希望您能够对该玩家进行相应的处罚，以维护游戏的公平和秩序。
- 问题3：我在游戏中遇到了一些技术问题，例如游戏卡顿、掉线等。
这些问题严重影响了我的游戏体验，希望您能够帮助我解决这些问题，让我能够顺利进行游戏。
3. 附加信息：
- 我已经尝试了以下解决方法：[列出您已经尝试过的解决方法]
- 我希望您能够尽快回复我的申诉，并解决我的问题。
如果需要我提供更多的信息或者配合您的工作，请随时告知。
我对魔兽世界亚服的服务一直非常满意，希望您能够继续提供优质的客户服务，解决我的问题。
谢谢您的帮助！
此致，
[您的游戏角色名]。