软件测试BUG提交规范_模板

合集下载

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提交列表
测试结果修改建议是否完成修改否
确实存在
提交订单的时候说没在订单里修改了下数
确实存在
否
选”按钮
确实存在
去掉“复选按钮”
否
形
确实存在
修改指针样式修改视频的时候，应该将该视频的原有信息都加载上去。前台个人中心删除视频后，应当给后台管理提示视频删除的标志

Bug提交规范

BUG流程及提交模板◆BUG流程常规流程1.发现一个缺陷，将其提交至Bugzilla。

此时Bug状态为confirmed（确定）。

如图：2.产品或开发人员修改Bug，修改后将Bug置为resolved fixed（已修改）状态。

如图：3.由测试人员严重该Bug，验证通过后改为verified fixed（验证通过）状态。

非常规流程以下四中情况请修改Bug人员特别注意，如图1.若提交的Bug不能算是Bug（即提交者提交错误），则将Bug置为Resolvedinvalid（不是Bug）状态。

并在下方添加备注说明不是Bug的原因。

2.若提交的Bug确实存在，但由于技术、时间有限在很长一段时间内不予修改或永久不修改，则将该Bug置为Resolved wontfix（不修改）状态。

并在下方添加备注说明不修改的原因。

3.若提交的Bug与另外一个Bug重复，则置为Duplicate（重复）状态，并将类似Bug的编号填写其中。

4.若提交的Bug在目前的版本或本地测试环境下无法重现，则置为Worksforme（无法重现）状态。

注：请确保已经和提交者或决策人经过沟通后，再将Bug置为非常规状态。

◆BUG提交原则1.清晰准确——解释到位，能够让其他人理解这个Bug是什么意思2.相同的Bug不能重复提交3.再微小的Bug也需要提交——因为小Bug有可能隐藏大隐患◆提交前准备1.将Bug在最新的版本上重现一遍，看是否已经被修改2.在Bugzilla中搜索一下，看这个Bug是否已经提交◆BUG模板Bug模板【项目阶段】【版本号】+标题：Bug的简要描述。

一定要能从标题就看出Bug的大概意思【测试网址】：测试用的服务器网址【详细描述】：Bug的详细描述，包括此Bug的重现步骤、具体现象、及可能有的影响。

如果有必要请添加图片。

【期望结果】：此Bug修复后期望的结果是什么。

请务必在明确期望结果的情况下再提交Bug。

【备注】：有另外需要说明的请在此处记录。

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，⼀个按钮点击后的“需求”是打开窗⼝，实际运⾏结果是转到另外⼀个地址。

转移地址是错误的，就要告诉修复者。

⽽不是报告：这个点击按钮后转到了⼀个新地址。

修复者有时理解成需求是要转移到⼀个新地址，结果他看到的就是这个结果。

BUG单填写规范

BUG单填写规范报告软件测试错误的目的是为了保证修复错误的人员可以重复报告的错误，从而有利于分析错误产生的原因，定位错误，然后修正之。

因此，报告软件测试错误的基本要求是准确、简洁、完整、规范。

以下概括了报告测试错误的规范要求，主要根据QC上的内容项填写。

必填项：1、Bug标题，简洁、准确，完整，揭示错误实质，记录缺陷或错误出现的位置，准确反映错误的本质内容，简短明了。

2、分配给，将bug分配给bug责任人，如新建的bug分配给开发或者产品，修复后的bug分配给bug的提出人员。

3、严重程度，选择bug的严重程度。

1级为致命型，2级为严重行，3级为一般型，4级为建议型，5级为可议型。

4、浏览器，选择发现bug的浏览器，测试人员在发现可能是因为浏览器兼容性而引起的bug时，应当在每个有需求的浏览器下都进行验证。

5、缺陷描述/步骤，对bug进行详细的描述并且填写Bug重现的步骤，出现的结果和期望的结果。

Bug单需要填写详细的复现步骤，方便开发人员重现Bug。

如：（步骤）1. 打开云计算首页 2.点击导航上的“登录”3.在弹出的邮箱地址框输入注册邮箱：*****************，4.按下键盘“Enter”键。

结果：操作没有反应。

期望：邮箱提交成功，给出“新密码已发送到邮箱”提示。

选填项：1、测试者，提交bug的人员，默认值是当前登录QC的账号。

2、模块，发现bug的模块。

3、缺陷状态，缺陷共有8个状态，分别是新建、打开、返回—给缺陷的提出人员、后续跟踪、拒绝—给缺陷的解决者、已关闭、已修正和重新打开，可下拉选择。

新建缺陷时，缺陷状态的默认值为新建，被分配到bug的人员（一般为开发或者产品）如果认为此bug 不是bug，可以将缺陷状态改为返回—给缺陷的提出人员。

对于一些偶发性的bug，开发人员无法复现或者测试人员暂时无法确认bug是否已修复的bug，可将缺陷状态改为后续跟踪。

开发人员接受这个bug后，则将缺陷状态改为打开，修复完成后，将缺陷状态改为已修正，并将bug指回给bug提出的人员（一般为测试人员），bug提出人员确认bug修复后，将bug 状态改为已关闭，如果经过确定后没有修复，则将缺陷状态改为拒绝—给缺陷的解决者（如果测试人员对被返回的bug有异议，也可以使用此缺陷状态）。

Bug报告编写模板

优先级别
高、较高、一般、低
问题来源
测试、工程故障、升级、其他
问题类型
功能问题、版本问题、遗留问题、新需求、低级错误、改进建议、移植修改、割接问题、配置错误、编译问题、性能问题、设计问题、兼容问题、新功能增强、偶发性出错
Bug描述
这是Bug最重要的一部分, 对Bug描述清晰准确, 不仅有助于开发人员迅速定位解决问题, 还对以后的维护工作有很大的帮助。一些比较简单的Bug, 可以使用一两句话把问题准确描述, 而对于一些比较严重或负责的Bug或者是新的需求, 则应该详细说明。
Bug关闭描述（bug关闭之后由测试人员填写）
开发回复Bug之后, 测试负责人验证该Bug, 如果问题得到解决则关闭（否则回复给开发负责人, 让其继续追踪）。关闭一个Bug时, 对于简单的问题, 可以“问题解决”或“OK”这样的语句回复；而对于一些比较复杂的问题或需求, 应该对Bug描述的内容进行一个总结。
附件
对于一些特殊的问题或者不能用语言很好地描述的问题, 可以增加界面图形说明或参考资料或详细日志等附件
Bug解决描述（bug解决之后由开发人员填写）
开发人员修改问题之后, 将Bug回复给对应的测试负责人。对于简单的问题, 在回复的时候只是简单地用“已解决”或“fixed”这样的语句；而对于复杂或重要的问题, 在回复的时候应该详细说明测试的解决方法。
Bug报告编写模板
BUGID
Bug的唯一标志,由bug管理系统自动生成
Bug标题
简明扼要地对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的书写规范提交bug的内容书写规范：1. 标题：【项⽬名称——简短的bug说明】描述bug的最主要关键词，如xx项⽬——数据库输⼊输出数据不⼀致2. 项⽬名称：【项⽬名称+项⽬版本号】3. Bug所属项⽬/模块：Bug所属项⽬和模块，最好能较精确地定位⾄模块；4. 严重等级：【紧急，严重，⼀般，微⼩】l 紧急Bug：造成系统或应⽤程序崩溃(Crash)、死机、系统悬挂，或者造成数据丢失、主要功能完全丧失等。

l 严重的Bug：功能或者特性没有实现，主要功能部分丧失，次要功能完全丧失，或者致命错误声明。

l ⼀般的Bug：不太严重，虽然不影响系统的基本使⽤，但没有很好地实现功能，没有达到预期效果。

如：次要功能丧失，提⽰信息不太准确，或⽤户界⾯差，操作时间长等。

l 微⼩的Bug：对功能⼏乎没有影响，产品及属性仍可使⽤，如有个错别字、⽂字排列不整齐等。

5. 优先级：【P1，P2，P3，P4】P1：⽴即解决，导致系统⼏乎不能使⽤或测试不能继续，需要⽴即修复；P2：⾼优先级，严重，影响测试，需要优先考虑；P3：正常排队，需要正常排队等待修复；P4：可以在开发⼈员有时间的时候再纠正；6. Bug状态：【New，Open， Fixed， Rejected， Delay ，Closed， Reopen】l New: 新发现的bug，开发⼈员尚未确认；l Open：确实是bug，并认为需要修改，指派给相应的开发⼈员；l Fixed：开发⼈员进⾏修改后标识成修改状态，有待测试⼈员的回归测试验证；l Rejected：如果认为不是bug，则决绝修改；l Delay：暂时不修改或者暂时不能修改，则延后修改；l Closed：fixed状态的Bug经测试⼈员回归测试验证通过，则关闭Bug；l Reopen：fixed状态的Bug经验证仍然存在，则需要重新打开Bug，开发⼈员重新修改；7. 测试环境：【硬件设备环境，软件设备以及配置环境，具体到使⽤的版本号，类型号】测试⼈员要充分说明测试环境的情况，以便开发⼈员可以快速定位错误，防⽌出现因开发环境与测试环境不符，⽽⽆法重现bug的情况。

Bug的书写规范

*若无附加信息，员定位问题的相关信
可不写
息
如：[步骤] 1.缩小数据分发的页面； 2.查看页面的框架结构；
如：[结果]页面程序中没有添加样式表，因此在页面缩小时，框架结构变形；
如：[期望]在页面缩小时，相应的框架结构不变或者页面提供滑动条，请参看附件；
如：[附加信息 1.【数据模型配置】/【产品订购维护】/ 【产品信息更新】都发生此缺陷； 2.【数据模型定义】中不发生此缺陷；
点评: 这里是用表物理名查询，即英文名，不是中文名
• 外部原因(280)
BUG #280::【基本配置】-【指标分组】，由于某些组元代码相同（几点组元代码等于父组元代码），导致删除失败；
• [步骤] • 1.点击【基本配置】-【指标分组】； • 2.点击某个分组名称； • 3.选择一个组元名称，右键选择“删除节点”； • 4.弹出框点击【确定】按钮； •. • [结果] • 无法删除，提示“删除失败” •. • [期望] • 删除成功 •.
缺陷报告应避免：1.设计如此 173 2.重复Bug 3.外部原因 280 4.无法重现 163 5.不予解决 19
• 不予解决(19)
BUG #19::【配置作业规则】：配置作业任务中按照"对应表或字段"查询功能未实现
• [步骤] • 1.打开"质检系统"；
2.点击"系统主菜单"下的"作业管理"； 3.选择作业"Job"的【配置作业规则】按钮； 4.在"第一责任人"中输入"testUser"； 5.在"规则名称"中输入"sj"； 6.在"对应表或字段"中输入"中诚信指数代码对照表"； 7.按Tab键 8.点击【Enter】键； •. • [结果] • 查询结果为空 •. • [期望] • 查询出第一责任人为"testUser"、规则名称包含"sj"、规则对应表是"中诚信指数代码对照表"的规则信息 •.

软件测试-BUG规范

BUG 规范一、BUG编写规范➢BUG的summary描述需简明扼要，例如：“上传文档：输入超长字符，系统出黄页！”（应尽量少出现不肯定的词语，如：是否）。

➢由于输入特殊字符而出现的BUG，BUG的Description或summary中应写明是哪些字符。

➢相同的BUG出现在不同的页面，应在summary中写明哪些页面也出现此问题，不应书写多条BUG（若书写为多条BUG则在前面打上记号如“--”，方便删除）。

➢若不能定位BUG出现的原因，应写明操作时所使用的帐号与操作步骤。

➢在第一次执行测试时尽量写出所有发现问题及建议。

➢若BUG描述不能说明清晰应夹带附件（有附件也应夹带附件），并在BUG的Description中加上文字描述（如：附件１：导出EXCEL前，附件2：导出EXCEL后）。

➢若在测试过程中，不能及时记住BUG的操作步骤，应在记起时将BUG书写完整，并致电告知开发人员使之进行处理。

➢在测试过程中，若遇到严重问题应该致电告知开发人员使之尽早进行处理。

➢对于所发现的问题不太清楚是不是BUG，可打电话与开发人员确认，或者询问测试组负责人或测试跟进人员。

➢在选择BUG的Severity(严重级别)时，应注意根据BUG的严重程度来确定，理清建议与BUG的意义，（建议：可修复也可不修复，修复了会更好，不修复也可以）不应将建议写成BUG，或将BUG写成建议。

——BUG严重级别定义详见附录二、验证BUG➢在验证BUG时，R&D Comments应注明验证时的实际输出结果，方便日后跟踪及统计。

➢在验证BUG时，应查看History，查明BUG修改的时间，避免将刚Fixed的BUG 重新Reopen。

➢在验证BUG时，若原有的BUG未修复，则应该Reopen；若原有的BUG所描述的现象已不存在，则Closed；若由于对原有BUG的修改而引发新的BUG，则应该Open记为新的BUG，不应将原有的BUG再Reopen。

Bug书写规范初稿

Bug书写规范初稿一、背景bug是开发和测试质量的重要指标，从bug数量、严重性等可以看出RD 的开发质量，从发现问题的阶段可以看出QA的测试意识和测试质量，从问题分类、问题来源等可以看出产品开发、测试质量的一些固有模式，帮助RD和QA 提升开发和测试质量。

二、bug规范Bug记录包含内容和tag两部分。

2.1 内容模板Bug标题描述——bug标题的直观简短的描述登录信息——如果需要登录才能复现的bug，提供登录的账号和密码，不需要可缺省bug复现步骤——对于操作步长超过3的，且RD难以理解怎么复现的问题，提供复现问题的步骤。

Bug复现的环境——测试环境/正式环境Bug复现的设备——PC端（浏览器的名字和版本）/移动端（提供设备型号和品牌）预期结果——描述需求预期的结果，必要时辅以截图说明实际结果——描述RD实现后的实际结果，需要截图辅助说明2.2 tagtag部分包括以下几项（必填）：优先级（高）——需要RD修复的紧急程度，是问题严重性和对测试block程度的综合考虑优先级（中）——不影响产品主要功能，但影响部分用户体验优先级（低）——产品UI、文案等问题问题发现阶段——自测阶段/提出阶段/正式交付问题引入阶段——历史遗留/新功能导致/修复bug引起发现版本——发现问题的版本，统一为x.x.x修复版本——修复问题的版本，统一为x.x.x解决结果描述bug的修复情况，可选项如下：比如：问题指派：对应的开发人员Bug标题：bug名称+bug标题言简意赅，让开发人员一眼看出问题出现在哪儿如：营销平台：修改个人资料，修改用户姓名“XX”改为“XX”失败步骤：需前置条件需要把前置条件描述清楚如：需要登录平台，账号：xxx；密码：xxxx浏览器名称：chrome操作步骤：1.点击修改个人资料2.修改姓名为“xx”3.点击保存按钮预期结果：保存成功，姓名修改成“xx”实际结果：提示保存失败！或者没有提示（最终是姓名没有修改成功）Bug等级：低发现阶段：测试阶段。

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个方可达到上线（视情况而定）。