软件测试BUG提交规范_模板
Bug提交与管理规范
Bug提交与管理规范 编写人：姚妮娜 2010.8.20
概述
• • • • • • • Bug的生命周期 测试流程中的角色与职责 判断Bug的规则 Bug的分类、状态、级别 Bug的报告、跟踪、关闭 测试人员验证/关闭问题描述 开发人员解决问题描述
Bug的生命周期
1、测试人员提交bug 2、开发人员提交bug 3、bug的owner可以由提交者指定项目经理或开发者 4、bug状态设为NEW
Bug的修改优先级
修改优先级通常可分为五个级别： P1：尽快（或立刻）修正； P2：每个里程碑（或测试周期）结束前必须修正； P3：如果时间允许就修正； P4：低优先级。 P5：在将来的某个版本修正也可以 处理的工作日 • Blocker、critical：响应时间1天，处理1天 • Major、normal：响应时间1天，处理3天 • Minor、trivial：响应时间1天，处理7天 • Enhancement:时间未定
测试人员验证/关闭Bug
测试人员验证/关闭Bug说明：
• 当Bug由open变为fixed，应进行回归测试，如果回归测试后该问题被解决， 则closed该Bug，并在注释中填写如下信息： 验证版本：xxx 验证次数：xxx 验证通过：是 验证日期：xxx 验证人员：xxx 如果回归测试验证不通过，则Reopened该Bug，并在注释中仍填写注释信 息： 验证版本：xxx 验证次数：xxx 验证通过：否 验证日期：xxx 验证人员：xxx
•
研发人员解决Bug
研发人员应该及时对分配给自己的bug在Bugzilla中添加注释信息，以便以后的信息收集和更好的保存作 成果。 针对不同情况，须按以下模块填写注释
• 1.已经改正的Bug Bug产生原因 Bug解决方案 Bug修改后的版本号 解决人员：*** 2.不能解决的Bug： Bug原因分析 无法解决原因（技术问题，条件问题……） 解决人员：*** 3.Bug重复： 注明与之重复的Bug ID 如根本原因相同，现象不同，给出简要分析说明 解决人员：***
软件测试缺陷报告模板
软件测试缺陷报告模板1. 引言软件测试缺陷报告是软件测试过程中的重要文档之一，用于记录和跟踪在软件开发过程中发现的缺陷信息。
本报告旨在提供一个模板，以便测试团队能够按照统一的格式和标准来编写缺陷报告，从而方便开发人员进行问题解决和跟踪。
2. 缺陷报告信息在编写缺陷报告之前，需要收集以下基本信息：•缺陷编号：每个缺陷需要一个唯一的编号，以便于跟踪和引用。
•缺陷标题：简明扼要地描述缺陷的问题。
•缺陷严重程度：根据影响范围和严重性进行评估，如轻微、一般、严重等。
•缺陷优先级：根据缺陷的重要性和紧急程度进行评估，如高、中、低等。
•缺陷状态：缺陷的当前状态，如新建、已分配、已修复、已验证等。
•缺陷报告人：填写报告人的姓名或者工号，以便后续联系和沟通。
3. 缺陷描述在这一部分，需要详细描述缺陷的问题。
描述时应包括以下内容：•环境说明：描述缺陷出现的软硬件环境，如操作系统、浏览器、设备等。
•复现步骤：提供详细的操作步骤，以便开发人员能够重现缺陷。
•预期结果：描述在执行步骤的过程中希望看到的正确结果。
•实际结果：描述实际出现的问题或错误信息。
4. 缺陷重现为了帮助开发人员更好地理解和定位缺陷，测试人员可以尝试多次重现缺陷，并记录重现步骤和结果。
当开发人员需要进行问题排查和修复时，这些信息将非常有用。
5. 缺陷截图/日志如果缺陷涉及到界面显示或者错误信息的输出，测试人员可以通过截图或者记录相关日志来进一步说明问题。
在报告中插入截图或者简要描述日志内容，但不要涉及敏感信息。
6. 缺陷影响范围在这一部分，可以描述缺陷对软件系统的影响范围和程度。
例如，缺陷是否会影响核心功能，是否会导致系统崩溃或数据丢失等。
7. 缺陷修复建议根据对缺陷的分析和理解，测试人员可以提供一些修复建议，以便开发人员进行问题解决。
建议应该具体、明确，尽量提供解决问题的思路或者方法。
8. 缺陷验证在缺陷修复后，测试人员需要重新验证缺陷是否得到解决。
软件测试bug报告模板
BUG管理
问题优先级
分五个等级，即A~E，A的优先级别最高，之后逐级递减。
Bug严重程度
Bug状态
新建状态（NEW ）
Bug创建后的初始状态。
已分配状态（open）
经过确认有效的问题后分配给开发人员的状态。
拒绝状态（Rejected）
验证不是有效的问题
解决状态（Fixed）
开发人员处理此问题后的状态
结束状态（closed）
经测试部门对修改后的软件问题进行验证并确认修改正确后的状态。
重新打开状态（REOPENED）
对开发部门修改后软件问题，经过验证，如果仍然存在，则将其状态改为“重新打开”状态。
对于“关闭/延迟修改”状态的软件问题，如果时机成熟，需要重新开发，则将
其状态改为“重新打开”状态。
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提交规范
测试组bug提交规范.doc测试组Bug提交规范一、引言本文档旨在规范测试组在软件测试过程中发现Bug的提交流程，确保Bug的记录、跟踪和管理过程标准化、系统化，以提高问题解决的效率和质量。
二、Bug定义Bug是指软件产品中存在的缺陷，它导致软件不能按照预期的功能、性能、可靠性、安全性等要求正常工作。
三、Bug提交流程发现Bug：测试人员在测试过程中发现Bug。
记录Bug：在发现Bug后，立即记录Bug的详细信息。
验证Bug：对Bug进行复现，确保Bug的可复现性。
提交Bug：通过Bug跟踪系统提交Bug。
分配Bug：Bug跟踪系统将Bug分配给相应的开发人员。
修复Bug：开发人员修复Bug。
验证修复：测试人员验证Bug修复后的结果。
关闭Bug：确认Bug修复无误后，关闭Bug。
四、Bug提交要求标题：Bug标题应简洁明了，能够准确描述Bug现象。
描述：详细描述Bug的触发条件、现象、预期结果和实际结果。
重现步骤：列出重现Bug的具体步骤。
附件：提供相关的截图、日志文件或其他辅助材料。
严重性：根据Bug对产品的影响程度，划分Bug的严重性等级。
优先级：根据Bug的严重性和修复的紧迫性，确定Bug的优先级。
版本：指明发现Bug的产品版本。
模块：指明Bug所在的产品模块。
测试环境：描述测试时的硬件、软件和网络环境。
五、Bug跟踪系统选择系统：选择适合团队使用的Bug跟踪系统。
账号管理：为测试人员和开发人员分配账号。
权限设置：根据角色设置不同的权限。
数据备份：定期备份Bug数据。
系统维护：定期检查和维护Bug跟踪系统。
六、Bug管理Bug状态：定义Bug的不同状态，如新建、已分配、修复中、已验证、已关闭等。
Bug跟踪：跟踪Bug的修复进度和状态变化。
Bug统计：定期统计Bug的数量、类型、严重性等信息。
Bug报告：生成Bug报告，向管理层和团队成员报告Bug情况。
七、Bug沟通与协作沟通机制：建立Bug沟通机制，确保信息的及时传递。
测试组bug提交规范
测试组Bug提交规范文档编号：{文档编号}当前版本号：0.10最初发布日期：2013-05-22最新修订日期：2013-05-22公司名称：深圳市海亚科技发展有限公司地址：深圳市龙岗区宝龙工业城诚信路8号亚深创新科技产业园办公楼9楼邮编：5180001.1 文档目的....................................................................... 错误！未定义书签。
1.2 文档范围....................................................................... 错误！未定义书签。
1.3 读者对象....................................................................... 错误！未定义书签。
1.4 参考资料....................................................................... 错误！未定义书签。
1.5 术语表........................................................................... 错误！未定义书签。
第2章Bug提交 ........................................................................ 错误！未定义书签。
2.1 Bug模块划分以及版本号选择.................................... 错误！未定义书签。
2.2 Bug严重程度及优先级................................................ 错误！未定义书签。
2.3 操作系统....................................................................... 错误！未定义书签。
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提交列表
测试结果 修改建议 是否完 成修改 否
确实存在
提交订单的时候说没 在订单里修改了下数
确实存在
否
选”按钮
确实存在
去掉“复选按钮”
否
形
确实存在
修改指针样式 修改视频的时候，应该将该视频的原有信息都加载 上去。前台个人中心删除视频后，应当给后台管理 提示视频删除的标志
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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补充说明信息，如：测试分析意见、其它设备有类似情况等>
二、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）：
界面重构、描述更改、流程改进。