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严重等级划分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等级：低发现阶段：测试阶段。

Bug描述和定义规范

Bug描述和定义规范目录1不同出现频率BUG的描述 ------------------------------------------------------------------------------------------ -2-1.1 总是出现 --------------------------------------------------------------------------------------------------------- - 2 -1.2 经常出现 --------------------------------------------------------------------------------------------------------- - 2 -1.3 偶尔出现 --------------------------------------------------------------------------------------------------------- - 2 -1.4 只出现一次 ------------------------------------------------------------------------------------------------------ - 2 -1.5 Bug的描述举例 ------------------------------------------------------------------------------------------------- - 2 -2B UG严重性定义 ------------------------------------------------------------------------------------------------------- -3-2.1 系统崩溃 --------------------------------------------------------------------------------------------------------- - 3 -2.2 严重错误 --------------------------------------------------------------------------------------------------------- - 3 -2.2.1 新功能部分错误 --------------------------------------------------------------------------------------------------------- - 3 -2.2.2 已有的功能部分 --------------------------------------------------------------------------------------------------------- - 3 -2.3 次要错误 --------------------------------------------------------------------------------------------------------- - 3 -2.3.1 新功能部分 --------------------------------------------------------------------------------------------------------------- - 3 -2.3.2 已有功能部分 ------------------------------------------------------------------------------------------------------------ - 3 -2.4 不合理或者别扭 ------------------------------------------------------------------------------------------------ - 4 -3B UG优先级定义 ------------------------------------------------------------------------------------------------------- -4-3.1 特急 --------------------------------------------------------------------------------------------------------------- - 4 -3.2 加急 --------------------------------------------------------------------------------------------------------------- - 4 -3.3 高优先级 --------------------------------------------------------------------------------------------------------- - 4 -3.4 中优先级 --------------------------------------------------------------------------------------------------------- - 4 -3.5 低优先级 --------------------------------------------------------------------------------------------------------- - 4 -1不同出现频率b u g的描述1.1 总是出现这类bug所要做到的就是如何把bug描述清楚：1．察看当前和bug相关的条件并列出2．按照bug出现的步骤重复做3次以上以此来寻找最短的路径，尽量把不必要的过程过滤，当然不确定的步骤一定不能过滤3．描述的时候尽量做到每个步骤最多2个动作4．尽量用主动的英语句型，在遇到许多动作可以产生这个bug的时候，可以适当用被动句型，把最好重现bug的那个步骤写出来其他可放在括号中5．Bug现象的说明一定要描述详细，不要放在步骤中6．发现bug之后的操作最好也做几个步骤(如果可以接着做的话)，这样更容易发现周围的bug，同时对开发人员解bug也是有帮助7．尽量把bug的周围情况描述的详细些，不需要总是等到开发人员问了我们再去做8、对于不易理解的问题，最好使用截图或者视频的方法进行1.2 经常出现这类bug和总是出现一样，重点就是把步骤描述全面详细且不冗杂。

bug描述

Bug描述需注意的1、bug单提交问题经常出现描述随意，问题描述与实际偏差过大，操作步骤不能重现的问题，测试组其他成员和开发同样无法重现问题，应该附加截图的没有附加。

2、bug单类型应该为建议的提交为缺陷和问题描述用词不准确。

3、对测试方向，测试侧重点，bug当重要性心理没有概念，光柱bug单数量而非质量。

4、对需求了解不够，导致不能测试系统重要分支和提交与需求不一致的bug单，影响工作效率5、测试方法不专业似的多次提交不是缺陷的bug单，简单问题仍需要开发指示测试方法。

6、测试工作不都细致和全面，问题存在的模块，可能引发问题操作仅描述一个，剩下的问题由开发区寻找7、开发老大（开发老大）17：33：14开发A的意见提的很重要，请测试组同事进行安排下，就如何提高测试工作效率展开讨论分析解决，烦请测试老大安排跟进下8、测试A（测试A）17：34：219、1、对于重现步骤中需要注意的细节的问题，测试会不惜笔墨详细描述，这是为了让开发能一次性最大概率地重现问题，最终目的是为了节约开发时间。

至于bug详细描述的【问题提议】这部分内容，是测试对当前bug的一个分析，同样一个目的也是为了帮助开发更好地更快去分析bug引发的渊源，去更准确地定位bug的根源。

若开发不需要测试分析，也可以避开不看该部分内容，完全不影响开发去理解去分析bug，请明晰。

对于需要截图的bug，测试从未吝啬ctrl+shift+x10、2、对于是缺陷，或是建议，缺陷有分功能缺陷与业务逻辑缺陷，并非非功能缺陷就不是缺陷，请明晰。

对于某些问题是缺陷还是建议，没有一个明确的界定，更加开发与测试的思考问题的方式不同，理解也不同，因此同样，勿以开发的思维来强加于测试的思维。

11、3、提交不是缺陷的bug单，是曾经发生过，有些的确是测试对于一些细节不够严谨，有些属于其他系统数据变更或者重现概率较低的问题，没有开发说的那么严重。

12、4、请列明没有测试到的系统重要分支的问题，之所以提交与需求不一致的bug单，是因为测试在测试过程中发现用户在提出需求时可能没有考虑到的一些细节问题，这些都属于13、测试A（测试A）17：34：21测试过程中不可避免的，也是测试的一个不可或缺的部分，发现该类问题并提出来，是测试的职责。

关于bug 的规范

关于Bug 的规范作者：刘芳芳一．开bug 前:1.确保是有效的bug, 与相关的人员沟通过，尽量减少by design 的bug.2.确保这个bug 没被file 过，与模块负责人沟通，并在bug 库里通过关键词搜索，尽量减少duplicated(重复的)的bug.3.如果是crash（崩溃）的bug, 尽量将dump 及相关log 保存下来，作为附件加到bug里，如果有UI上的问题，尽量截图并将重要部分圈出来，并作为附件。

4.尽量减少复现步骤，有利于开发定位问题。

并试着按步骤复现，如不能，说明下复现的概率。

二．好的bug:1.Bug 标题要精简，明确，不夸大，能与别的bug 区分2.设置合理的优先级（从用户或者商业层面，需要处理的速度），及严重级（从技术层面），有利于开发合理分配资源去解决bug.3.Bug 如果知道是谁负责的模块，直接assign 给相应的模块开发人员，如果不知道的，直接给相应的负责人，比如PC 的给shihuaxiang, IOS 的给蒋敏, 安卓的给杨帅。

4.Bug 的步骤如前所述，尽量精简，有预置条件的记得写上。

5.其他信息，如发现的版本号，一定要写在’Additional information’ 里，这是依据。

如果开发解为resolved as not repro, 一定必须是依据当时填的版本，而不是现在的最新版，否则应该是resolved as fixed.6.新Bug 一定要分配给相应的开发模块人，或者产品bug 就给相应的产品，如果不确定的就给相应的负责人，如PC 的给shihuaxiang, IOS 的给蒋敏，Android 给杨帅。

三．对bug 的处理:为了简化bug的处理，bug 的状态’status’咱们只用这几种：assigned, resolved, closed.1.如果需要测试人员确认相关的bug 信息，如发现的版本号，复现步骤，请加上相应的comments, 再给相应的bug 提交人，状态仍为‘assigned’, 无需改变。

Defect Report书写规范
版本信息
版本号编辑内容
V1
制作《Defect Report 书写规范》PPT
编辑时间 2013.5.31
简述
• 提交规范性bug报告的重要性 • Bug书写规范 • Bug附件 • 实训 • Bug填写表
简述
• 提交规范性bug报告的重要性 • Bug书写规范 • Bug附件 • 实训 • Bug填写表
提交规范性bug报告的重要性
书写不规范、难于理解的bug报告耗费时间，影响工作效率书写好的bug报告可以让所有人理解问题所在、客户影响率以及风险度书写好的bug报告可以辅助缺陷的修改 Bug报告是测试部门对其它部门输出的最重要的交付物
规范性bug报告特质
• 一致性：跟标准性模版一致 • 清晰：不会包含模糊、令人困惑的信息 • 简洁：描述用词简明 • 正确性：不会出现错误的描述语句 • 完整性：不会缺失必备的bug描述 • 易读性：阅读起来容易理解 • 有辅助性的：包含辅助理解、分析问题的信息 • 聚焦性：指明问题的本质测试工程师的使命：书写清晰简明的bug报告
得到很好书写的：
1. 以上问题10次中发生1次； 2. 这个问题发生率很低，但是一旦发生，会阻拦用户使用，客户很容易察觉到。这个问题存在退机的风险； 3. 请查看附件1，附件1中的文档显示发生错误的信息； 4. 这个问题在win7上面发生，在XP上面也发生； 5. 发生这个问题时，我正在上传文档到系统。当时使用的文档，我上传上来了，请看附件2； 6. 当发生这个问题的时候，查看首页的功能依然是好的； 7. 我尝试了以下方法去重现这个问题以及重现情况如下：
特性描述：描述bug的重要特征错误恢复：描述从错误情形恢复的方法变通方案：描述避免此bug发生的方法客户影响：描述此bug对终端用户的影响度

BUG书写

BUG分类标准
BUG类别详细定义：类别详细定义：类别详细定义 ★ (S类)：与需求功能不相符 1.实际功能与策划书功能定义不相符 2.策划书未定义，但开发所做功能与常规习惯不相符 3.从使用者角度出发，对功能建议性意见 ★ A类：死机、重启、丢资料（系统稳定性）分类： 1.AH:100%必然(或概率在50%以上可复现)的死机或重启问题 2.AM:30%-50%范围内非必然死机或重启问题 3.AL:低于10%的非必然死机或重启问题
BUG书写规范
10.书写bug路径：在描述一个较长的路径时候，使用些符号可使路径更加清晰明了
例如：T卡资源->Navione 文件夹下默认无Route 文件夹，导致“功能”->行程->管理->“导入”/“导出”功能无效。建议默认添加Route文件夹
（-》、\、— 这些符号）
BUG书写规范总结
BUG分类标准分类标准
1.执行某操作后，手机用户资料丢失，但重启系统后可以恢复正常显示，假丢失； 2.执行某操作后，功能中的用户数据显示乱码，重启后可以恢复； 3.执行某操作后，功能中的用户数据显示乱码，且不可以恢复； 4. 4.执行某操作后，系统菜单、系统标题、系统提示信息等显示乱码； 5.发送短消息失败率较高； 6.不能充电； 7.充电显示不正确；（1）充电不提示/充电进度错误；（2）满电或者低电压后电压值错误；（3）充电时间过长或者过短；（4）插、拔充电器状态显示不正确；
BUG分类标准分类标准
1.屏幕冻结死机； 2.手机自动重启 3.执行操作后，手机用户资料自动丢失，重启系统后也无法恢复； 4.某种条件下，不能正常进入手机； 5.单路通话过程中掉线、不能接听电话、一接就掉线、不能挂断电话或挂断电话时间过长、不能进行正常通话； 6.执行操作后出现黑屏，按开机键不能开机，需掉电重新启动； 7.通话过程中有明显的电流声，严重影响用户正常使用；

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规范说明文档

即“马上解决”，问题已经阻塞了流程，无法开展后续的测试工作。
即“急需解决”，问题的修复很紧要，关系到系统的主要功能模块能否正常。
High
高优先级
即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
Medium
中等优先级
即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。
数据计算逻辑错误；
涉及金额相关，功能一般的错误也被判断为严重级别。
一般
对非主要功能造成影响、或者有较为快速方便的规避方式、有较小的错误理解等
需求中有要求的格式错误；
界面实现不符合需求中的要求，如数据展示错误；
响应时间较慢，数据页面加载慢，操作卡顿，不符合性能需求预期；
界面校验错误或者提示信息与异常处理不符合；
4
安全问题
包括系统安全，网络安全，数据安全，应用安全等方面的问题
5
UI问题：
UI设计
前端交互
前端页面显示
前端逻辑
人机交互特性；
确认用户输入，功能有效性，页面排版等方面的Bug；
文字错误，语法错误，提示的错误信息；
不适当的数据验证等Bug.
6
兼容性问题
程序无法满足主要的操作系统；
程序无法满足主要的手机型号等
是
Bug严重等级定义，默认值为“一般”
4
优先级
是
Bug优先级定义
5
Bug类型
是
Bug类别定义
6
报告人
是
报告该bug的人员，默认会获取当前登录用户
7
Bug所属模块
是
选择bug的归属模块，根据需要可以选择一级或者多级（需要新增可以联系@庞博添加）