BUG书写规范 - 360文档中心

提交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严重等级划分1.1 1 级（致命错误）致命错误通常是指功能不能满足系统要求，基本功能未完全实现，可能导致本模块以及其他相关模块异常、崩溃、无法执行等引起系统不能继续运行的错误。

从用户角度来说，由于产品功能或者性能造成 80%以上用户无法使用的问题。

常见范围：（1）主路径功能不可用或主路径必现 crash；（2）用户数据保存丢失或数据库保存调用错误或破坏；（3）数据库加密信息明文显示；（4）测试或使用某一功能时，导致程序异常退出、卡顿或其他功能无法使用；（5）功能实现设计和需求严重不符；（6）接口测试中主要功能接口不通；（7）系统页面无法访问出现404、闪退或服务器返回500 以上错误等；（8）常规操作引起的系统崩溃、卡顿、死循环、非法退出、数据丢失；（9）涉及金钱，严重的数值计算错误；（10）数据通讯错误，比如返回字段和需求不一致等；（11）数据库发生死锁；（12）系统关键性能不达标等；（13）严重的安全性问题；（14）主要功能丧失，导致严重的问题，或致命的错误声明；1.2 2 级（严重错误）严重错误是指影响系统操作或基本功能的实现，非主路径功能失效或部分失效，数据不能保存，系统所提供的功能或服务受到明显影响。

从用户角度来说，用户可以使用，但性能非常不稳定，经常出现服务中断等情况。

常用范围：（1）业务流程错误或功能实现不完整，比如删除时没有考虑数据关联；（2）非主路径功能失效或部分失效，或者是非主路径必现crash；（3）程序接口返回数据出错或引起周边其他接口出错；（4）功能实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用，对数据库的操作不能正确实现等；（5）非常规操作导致的系统崩溃、卡顿、死循环、非法退出、数据丢失 (非常规操作：复杂的多种操作组合或异常操作）；（6）在产品声明支持的不同平台下，出现重要功能的兼容性问题；（7）单项操作功能可以执行，但在此功能中的某些小功能无法被执行；1.3 3 级（一般错误）一般错误是指功能没有完全实现但不影响使用，功能菜单存在缺陷但不影响系统的稳定性，或者功能使用困难，可通过变通手段来实现。

软件缺陷(bug)的概述及书写规范

软件缺陷（bug）的概述及书写规范1、软件缺陷（bug）的定义IEEE（1983）729软件缺陷一个标准的定义：从产品内部看：软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。

从产品外部看：软件缺陷是系统所需要实现的某种功能的失效或违背。

2、软件缺陷（bug）满足的5个规则至少满足以下5个规则之一，才称为发生一个软件缺陷：–软件未实现产品说明书要求的功能–软件出现了产品说明书指明不应该出现的错误–软件实现了产品说明书未提到的功能–软件未实现产品说明书虽未明确提及但应该实现的目标–软件难以理解，不易使用，运行缓慢或者----最终用户会认为不好3、软件缺陷（bug）生命周期测试人员开发人员测试人员测试人员bug bug为回归测试Y4、软件缺陷（bug）状态Unfixed测试人员新建一个bug，将bug的状态定义为unfixed，开发人员看到的最新的bug状态都是unfixed。

To be fixed开发经理将新建的bug指派给自己或者其他开发人员，将bug的状态置为to be fixed。

Pending由于该bug实现比较难，或者无法修改，开发人员会将bug状态置为pending。

To be verified开发人员已修复bug，将该bug指派给其他开发人员，进行内部测试，此时bug状态为to be verified。

Verified开发人员进行内部测试确认该bug已修复，然后将该bug指派给测试经理，bug状态置为verified。

Integrated测试经理将已修复bug指派给bug提交者，做回归测试，此时将bug状态置为integrated。

Fixed测试人员进行回归测试，确认bug已修复，将bug状态置为fixed。

Close该bug不是bug，或者描述有误，开发经理关闭该bug，此时bug状态为close。

5、软件缺陷（bug）的优先级High（高优先级）–严重花屏–内存泄露–用户数据丢失或破坏–系统崩溃/死机/冻结–模块无法启动或异常退出–严重的数值计算错误–功能设计与需求严重不符–其他导致无法测试的错误Mid（中优先级）–功能问题–系统刷新错误–语音或数据通讯错误–轻微的数值计算错误–界面操作错误–边界条件下错误–系统运行缓慢、等待时间过长–图片按钮显示错误Low（低优先级）–界面格式不规范–操作时未给用户提示–可输入区域和只读区域没有明显的区分标志–个别不影响产品理解的错别字–文字排列不整齐等一些小问题–建议性问题6、软件缺陷报告（Bug）的书写规范Bug描述的目的是尽最大可能帮助开发人员解决bug，所以bug描述要尽可能丰富但切中要害，使开发人员能迅速定位bug产生的原因。

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 规范一、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）的概述及书写规范1、软件缺陷（bug）的定义IEEE（1983）729软件缺陷一个标准的定义：从产品内部看：软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。

从产品外部看：软件缺陷是系统所需要实现的某种功能的失效或违背。

2、软件缺陷（bug）满足的5个规则至少满足以下5个规则之一，才称为发生一个软件缺陷：–软件未实现产品说明书要求的功能–软件出现了产品说明书指明不应该出现的错误–软件实现了产品说明书未提到的功能–软件未实现产品说明书虽未明确提及但应该实现的目标–软件难以理解，不易使用，运行缓慢或者----最终用户会认为不好3、软件缺陷（bug）生命周期测试人员开发人员测试人员测试人员bug bug为回归测试Y4、软件缺陷（bug）状态Unfixed测试人员新建一个bug，将bug的状态定义为unfixed，开发人员看到的最新的bug状态都是unfixed。

To be fixed开发经理将新建的bug指派给自己或者其他开发人员，将bug的状态置为to be fixed。

Pending由于该bug实现比较难，或者无法修改，开发人员会将bug状态置为pending。

To be verified开发人员已修复bug，将该bug指派给其他开发人员，进行内部测试，此时bug状态为to be verified。

Verified开发人员进行内部测试确认该bug已修复，然后将该bug指派给测试经理，bug状态置为verified。

Integrated测试经理将已修复bug指派给bug提交者，做回归测试，此时将bug状态置为integrated。

Fixed测试人员进行回归测试，确认bug已修复，将bug状态置为fixed。

Close该bug不是bug，或者描述有误，开发经理关闭该bug，此时bug状态为close。

5、软件缺陷（bug）的优先级High（高优先级）–严重花屏–内存泄露–用户数据丢失或破坏–系统崩溃/死机/冻结–模块无法启动或异常退出–严重的数值计算错误–功能设计与需求严重不符–其他导致无法测试的错误Mid（中优先级）–功能问题–系统刷新错误–语音或数据通讯错误–轻微的数值计算错误–界面操作错误–边界条件下错误–系统运行缓慢、等待时间过长–图片按钮显示错误Low（低优先级）–界面格式不规范–操作时未给用户提示–可输入区域和只读区域没有明显的区分标志–个别不影响产品理解的错别字–文字排列不整齐等一些小问题–建议性问题6、软件缺陷报告（Bug）的书写规范Bug描述的目的是尽最大可能帮助开发人员解决bug，所以bug描述要尽可能丰富但切中要害，使开发人员能迅速定位bug产生的原因。

Bug的书写规范

Linux操作系统基础 Bug的书写规范
2011年12月
成雪峰 2011-1-18 彭利红
Bug的定义
• 什么是软件缺陷？ • 软件缺陷，常常又被叫做Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
标准书写格式尽量用一句话描述问题格式为：“TB_ build版本日期【功能模块】 bug简要说明” 如：[Bug标题]TB_ 20110929【数据模型配置】当缩小页面时，页面的框架结构变形；如：[步骤] 1.缩小数据分发的页面； 2.查看页面的框架结构；
描述
步骤结果期望附加信息
*若无附加信息，可不写
点评: 这里是用表物理名查询，即英文名，不是中文名
•
外部原因(280)
BUG #280::【基本配置】-【指标分组】，由于某些组元代码相同（几点组元代码等于父组元代码），导致删除失败；
• • • • • • • • • • • •
[步骤] 1.点击【基本配置】-【指标分组】； 2.点击某个分组名称； 3.选择一个组元名称，右键选择“删除节点”； 4.弹出框点击【确定】按钮； . [结果] 无法删除，提示“删除失败” . [期望] 删除成功 .
Bug的书写规范
• 1.Bug描述的目的是尽最大可能帮助开发人员解决bug。 • 2.Bug描述要尽可能丰富但切中要害，使开发人员能够很迅速地定位这个bug的原因。 • 3.尽量采用标准的格式描述Bug，充分利用已有的标准模板，使开发人员易于阅读和理解。 • 4.在测试任务执行过程中报bug要注意统筹时间安排。 • 5.不要加入评论性的语句。 • 6.附图是一种非常好的bug表现形式，可以很形象而且简洁地表现这个bug。

提交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书写规范初稿一、背景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等级：低发现阶段：测试阶段。