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描述技巧
1、在脑海中有明确的对象
2、花一定的时间来验证清楚（注意统筹时间安排，保证任务按时完成）
3、写完缺陷报告后要重新读一遍
4、让其他人读你的缺陷报告
5、不要加入评论性的语句
6、充分利用已有的标准模板
二、Bug关键字描述
主题：
•用一个简短的句子描述问题，不要写成一大段
•以进入问题模块路径开头，方便项目经理分派任务，以及开发人员定位问题
•描述问题时要详细、简练、抓住要点，直接切入正题，不要罗嗦
•不要夸大或缩小问题的严重程度
步骤：
•用数字编号，一步步的描述重现问题的所有操作步骤
•提供明确的再现问题的步骤，避免问题被以“不能重现”关掉
•设置区域需要详细描述，如：各设置项值为默认、**值更改为“”，其他设置项值为默认；
•尽量用动词作为开头，描述每个步骤。

如：打开、点击、设置、选择、插入、双击等
•不要在一个步骤中描述不相关的多个操作。

如果是相关的一系列操作，可以使用“－>”来连接描述。

•按照你写的步骤去执行，看问题能否重现
•不要在步骤中使用含糊不清的缩写词描述
实际结果：
•实际只描述一个问题
•同样的操作步骤产生多种现象，要在一个缺陷报告中加以描述•不同的操作步骤产生不同的问题，分别报bug
•如果有截图，请列出所附的图片信息
预期结果：
•不要加入实际结果的描述信息
•描述要清晰，不要使用含糊不清的缩写词描述
•如果有截图，请列出所附的图片信息
附加信息：
•避免写成大段落，要写得简单、易读
•问题的特征
•出现问题后的解决方法
•对终端客户的影响情况
•如果有必要，列出产生问题的配置环境。

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你有没有为了‎要更多的信息‎而被返回bu‎g report‎的经历呢？有没有碰到过‎你发现的一个‎非常严重的错‎误被推迟到下‎一个版本才去‎修复的情况呢‎？你提交的每一‎个bug report‎都是和项目组‎就正在测试中的软件质量‎问题的一种书‎面沟通方式。

通常，你用于沟通程‎序错误的能力‎－不是体现在错‎误本身的内在‎严重程度－而是体现在确‎定这个错误是‎否需要修复。

如果这是一个‎可怕的想法，你可能会想，“等等！我讨厌写作，我并不擅长写‎作。

怎么样才能够‎通过编写bu‎g report‎来决定错误的‎命运呢？”它要吸引大家‎相信错误是为‎他们说话的－任何一个头脑‎正常的人都应‎该主动地查看‎一个特定的错‎误是足够可怕‎的以致要被修‎复。

不幸的是，事实并不是这‎样。

但是好消息是‎：有效的和软件‎开发人员、项目组沟通的‎能力不是由你‎在高校英语课‎程中的表现所‎决定的。

这不是关于用‎有趣的词语编‎写流畅散文，也不是关于优‎秀语法和拼写‎的方法。

它是有关仅用‎能够表达你观‎点的词语明白‎地表述错误的‎方法。

太多地话将会‎使你的观点陷‎入茫然无措中‎。

太少地话又会‎使他人用自己‎的假设去填补‎隔阂－通常是对软件‎有害的部分。

如果你不是很‎确信是什么样‎的错误，那么不管你的‎b ug report‎写得怎么好，也没有人知道‎那是什么样的‎错误。

这篇文章主要‎讨论你现在能‎够开始着手提‎高人们倾听你‎发现的错误的‎机会的4个方‎法。

了解你的听众‎毋庸置疑，任何写作课都‎会告诉你必须‎了解你是为谁‎编写bug report‎。

每份bug report‎至少有两个听‎众：必须要修复错‎误的人和决定‎错误命运的人‎或团体。

有时一个人会‎同时负责这两‎份工作，但是仍然是两‎个不同的听众‎，只是一起发生‎在同一个人身‎上罢了。

你的第一个听‎众－那个必须修复‎错误的人需要‎清楚，明确的步骤以‎重现错误。

软件缺陷(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描述语言规范

BUG描述规范一、目的清晰简单描述好缺陷，编写有效的缺陷实例，帮助开发人员有效的进行缺陷定位，重现错误，从而去有效的定位错误，修改错误。

二、目标◆减少开发人员的二次缺陷率◆提高开发人员修改缺陷的速度◆提高测试质量部门的信用度◆增加开发与测试的协作◆有效提高产品的质量三、范围本文档适合于系统产品部门所有的人员四、缺陷的要素◆描写格式：填写缺陷的时候，若为软件的模块名称、页面元素和按钮、关键步骤、附件则应由对应的“ [ ] “进行描写，描述中出现的缺陷错误需用引号+粗体+红颜色进行标记；◆描写步骤：缺陷描述的时候要分层次，首先是描述缺陷发生的位置和条件，其次描述缺陷发现的步骤，再描述缺陷发生的结果，给出缺陷修改建议，最后必须[附上结果的附件或快照]；◆描述方法：填写缺陷的时候，尽量采用书面语，不能采用口语、歧义性语言，激动的语言（毁谤性）；缺陷的状态改变，需注释对应的用户名、时间、原因，才能改变状态；◆附件和快照标准格式：附件根据需要对缺陷的过程和结果进行[标注]和[文字说明]，说明过程需用[红色箭头]对缺陷过程进行[描述]和[说明]；◆缺陷主题描述：简单清晰的描述在什么样的位置，什么样的条件下，发生什么样的结果，不能完全复制详细描述中的语言；◆缺陷描述标准格式：五、缺陷描述的案例1.jpg2.jpg六、测试属性定义测试优先级高：在所有的测试项中排在首位、最核心也是最能影响整体的被测对象或功能中：主要的涉及到细节化的被测对象或功能低：不影响系统运行和整体架构的被测对象或功能◆BUG严重级高：引起系统崩溃或无法正常运行和安装中：需求说明书中要求的功能未实现或不符，或流程数据错误低：显示差错、风格差异或建议◆BUG优先级高：非常紧急且无法继续测试，必须马上修复中：不影响主要流程但在发布版本前必须修复低：时间允许的情况下修复，也可在下一个版本再修复.。

Bug描述标准规范

测试BUG描述标准规范对于软件测试来说，发现、提交、跟踪验证bug是软件测试中最基本的工作。

然而测试中发现bug后bug描述的清楚与否，可以很好的帮助开发人员快速定位、解决问题，而且还可以提高测试人员基本测试技能。

因此，建立标准的bug描述规范是十分重要、也是十分必要的。

首先清晰的bug描述可以帮助开发人员快速定位、解决问题。

软件测试部门中员工的水平各有不一，对于bug的认知、描述侧重面也会存在不同。

因此，如同一个问题，由不同测试人员描述bug，就有可能会存在描述不一致的问题。

这就会造成让开发人员理解不清晰，从而延误解决问题的周期，造成项目的delay问题，无法使我司产品按时上市。

其次标准的bug描述可以提供测试人员的基本测试技能。

如我们测试部有新入职员工，他可以先从bug库中查找bug了解我司产品的整个开发、研制中产生的问题。

而标准清晰的bug描述可方便快速的使其尽早、尽快的融入我测试部门。

另外，对于bug的追踪验证时，由于是不同测试人员进行验证，所以规范的bug描述，可以提高测试人员验证问题的效率。

而且对于测试人员来说，每个人的测试思路、方式不同，所以标准的bug描述对于测试部门内部员工的技术沟通也有很好的帮助。

标准的bug描述应有以下三方面组成：1. Bug发现位置：应说明操作进行的位置，通常是系统中的某一模块。

另外是具体的出错位置，可能是某一字段、某一页面；2. Bug的操作步骤：详细的、有次序的、每一步的操作步骤，包括输入的数据3. Bug的表象：具体的错误描述，包括界面显示、错误信息；即bug的具体描述，以及期望结果等；因此，对于我们测试时发现bug描述，应尽量做到以下几点：1.Bug的描述要声明前提条件：例如bug产生的时间、地点等因素，是产生BUG的静态条件；2.Bug的描述步骤要按条理、清晰、简单明了：分清1/2/3等条目；3.Bug的描述中追加bug产生过程中的截图、trace等帮助信息；4.尽可能使用“客户系统”自行分辨BUG为终端问题还是平台问题。

软件测试-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的书写规范

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是开发和测试质量的重要指标，从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描述标准Bug描述在软件开发过程中起着重要的作用，它是开发人员和测试人员之间进行沟通的桥梁，能够帮助开发团队更快地定位和修复软件中存在的问题。

然而，由于缺乏规范的Bug描述标准，经常会出现描述不准确、信息不完整或混乱不清的情况，这对于软件开发过程的顺利进行造成了困扰。

因此，制定一套规范的Bug描述标准变得非常必要。

一、Bug描述标准的重要性Bug描述标准是指在报告Bug时，需包含的必要信息和格式要求。

它能够提供清晰的描述和准确的信息，有助于帮助开发人员在最短的时间内定位和解决问题。

同时，使用标准格式的Bug描述能够增强沟通和协作，减少误解和沟通成本，提高开发效率。

二、规范的Bug描述标准示例下面是一个符合规范的Bug描述标准的示例：1. Bug标题：简明扼要地描述Bug的问题内容，用于快速定位和分类。

2. Bug描述：详细描述Bug的现象、出现的条件和重现步骤。

3. Bug复现步骤：详细描述复现Bug的步骤，包括输入参数、操作流程等。

4. 期望结果：明确描述Bug应该达到的预期结果。

5. 实际结果：描述实际发生的结果与预期结果的差异。

6. 环境信息：提供软件的版本号、操作系统、设备信息等相关环境信息。

7. 日志或截图：如果可能，附上相关的日志文件或截图，有助于问题定位。

8. 优先级和严重程度：根据Bug的影响程度和紧急程度进行评估，并标记相应的优先级和严重程度。

三、制定规范的Bug描述标准的好处制定规范的Bug描述标准有以下好处：1. 提高开发效率：准确的Bug描述能够帮助开发人员快速定位和解决问题，提高开发效率。

2. 降低沟通成本：规范的Bug描述标准能够减少开发人员和测试人员之间的沟通成本，减少信息传递中的误解和不必要的沟通。

3. 提高Bug修复质量：通过规范的Bug描述，开发人员能够更加明确地了解问题的具体细节，有助于提高Bug修复的质量。

4. 促进团队合作：通过制定共同遵守的Bug描述标准，能够促进团队协作和信息共享，增强团队的凝聚力和合作效率。

Bug报告的排版和格式规范

Bug报告的排版和格式规范为了确保Bug报告能够准确、清晰地传达问题，并且方便开发人员进行处理和修复，Bug报告的排版和格式规范非常重要。

以下是一些Bug报告的排版和格式规范的建议。

一、Bug报告的标题每个Bug报告应该有一个简洁明了的标题，用于描述Bug的概要情况。

标题应该准确地反映出Bug的关键信息，包括出现Bug的功能模块、具体的问题描述，以及可能的影响范围。

例如，一个好的Bug报告标题可以是：“用户注册失败：提交按钮无效”。

二、Bug报告的描述在Bug报告的正文部分，需要提供详细的描述来帮助开发人员理解问题。

以下是一些可以包含在Bug报告描述中的信息：1. 复现步骤：详细描述如何复现Bug，包括所涉及的操作、特定的设置、输入数据等。

2. 期望结果：描述你期望在执行复现步骤时看到的结果。

3. 实际结果：描述实际出现的问题或错误。

4. 环境信息：提供运行Bug的系统环境信息，例如操作系统、浏览器版本、设备型号等。

5. 附加信息：如有必要，可以提供其他相关的信息，例如日志文件、截图或录屏等。

三、Bug报告的分类和优先级为了使Bug报告更加清晰和易于管理，对Bug进行分类和设定优先级非常重要。

可以采用以下方式进行分类和设定优先级：1. 分类：将Bug报告按照功能模块、错误类型或其他相关的分类标准进行归类，以便开发人员更好地理解和解决问题。

2. 优先级：根据Bug的影响范围、严重程度和紧迫性等因素，为Bug设定合适的优先级，例如高、中、低等级别。

四、Bug报告的样式和排版Bug报告的样式和排版也能够提升其可读性和整洁度。

以下是一些建议：1. 使用清晰、简洁的语言表达问题，避免使用隐晦或含糊的词汇。

2. 使用编号或列表来展示复现步骤、环境信息或其他相关信息，以提高可读性。

3. 使用粗体、斜体、下划线等方式来强调关键信息，使其更加突出。

4. 使用合适的字体大小和行距，以确保整篇Bug报告的可读性。

五、其他注意事项除了上述提到的排版和格式规范，还有一些其他的注意事项：1. 避免使用不必要的技术术语，尽可能使用通俗易懂的语言来描述问题。

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.通话过程中有明显的电流声，严重影响用户正常使用；

bug标题描述方法

bug标题描述方法（原创实用版4篇）《bug标题描述方法》篇1编写bug 标题时，应该尽可能清晰、简洁和准确地描述bug 的本质。

以下是一些编写bug 标题的建议:1. 描述具体的问题：在标题中描述bug 所涉及的具体问题，例如:“在某些情况下，登录按钮无法正常工作”。

2. 使用简明扼要的语言：使用简短、易懂的语言来描述bug，避免使用复杂的技术术语或行话。

3. 指出受影响的版本：在标题中指出bug 所涉及的软件版本或操作系统版本，例如:“在Windows 10 版本1903 中，文件浏览器无法打开文件”。

4. 强调重要性：如果bug 导致的影响非常严重，应该在标题中强调这一点，例如:“紧急：网站无法访问”。

5. 避免使用情绪化的语言：在标题中避免使用情绪化的语言，例如“烦人的bug”或“严重的问题”。

6. 确保标题唯一：确保bug 标题是唯一的，避免使用相同的标题描述不同的bug。

《bug标题描述方法》篇2编写bug 标题时，应该尽可能简洁、明确地描述bug 的本质。

以下是一些编写bug 标题的建议:1. 突出重点：在标题中用关键词或短语突出描述bug 的核心问题，让开发人员快速了解bug 的本质。

2. 简洁明了：标题应该尽可能简短，不超过10 个字符，以确保在邮件列表或缺陷跟踪系统中能够清晰可见。

3. 避免使用模糊的词汇：使用含糊不清的词汇，如“无法工作”、“崩溃”、“奇怪的行为”等，可能会导致开发人员无法理解问题的本质，从而无法快速修复bug。

4. 描述具体步骤：在标题中描述触发bug 的具体步骤，帮助开发人员更快地定位和修复问题。

5. 提供相关信息：如果可能，在标题中提供与bug 相关的信息，例如操作系统、浏览器版本、应用程序版本等。

6. 使用标准术语：使用通用的缺陷跟踪术语，如“reproducible”、“fails to”、“hangs”等，以便开发人员更快地理解问题。

7. 避免使用情绪化的语言：避免使用情绪化的语言或咒骂，这可能会引起不必要的争议或误解，而不是帮助解决问题。

bug描述规范_20150806

软件测试缺陷报告规范（测试部）缺陷报告是测试人员的主要工作产品之一，好的缺陷报告会增加开发人员对测试人员的信任度，差的缺陷报告会影响开发人员的效率。

缺陷报告的读者主要有两种，即开发人员和项目管理者。

开发人员关注的是Bug的详细描述，即Bug 的重现步骤；项目管理者主要关注Bug 的概述和严重程度，关注整个系统中各种严重级别Bug 的分布比例。

良好的缺陷报告描述有利于相关部门间的合作，减少一些不必要的沟通时间，提高工作效率。

软件的缺陷（Bug）指的是软件中（包括程序和文档）不符合客户需求的问题。

这个定义是我们判断一个软件问题是否是bug 的唯一标准。

缺陷描述一般包括缺陷概述（Summary）和详细描述（Description），具体要求如下：●缺陷概述（Summary）:输入问题缺陷的概要，即Bug 的主旨，需采用简洁、准确、完整的语言抓住重点去描述，最好用陈述句。

●详细描述（Description）：描述问题的详细过程，用语要简洁、准确、完整，“简洁”即没有多余的步骤；“准确”即步骤正确；“完整”即没有缺漏。

保证使用最少且必要的步骤快速准确的重现错误。

其中操作步骤和实际结果是详细描述必要部分，其他各项可依据实际情况进行调整，具体格式如下所示。

1 预设条件；2 操作步骤【必要】；3 实际结果【必要】；4 预期结果；5 备注内容；6 插入必要的附件，如截图等等。

举例：（Summary）PlayHub升级所有应用，无法暂停所有升级应用（Description）操作步骤：1.右拉抽屉->Update->Update->All一栏后的Update2.再次点击All一栏后的Update实际结果：无法暂停所有升级应用期望:可以暂停所有升级应用●描述过程中尽量使用业界惯用的表达术语和表达方法。

使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。

●一个Bug 提交一个报告。

有的测试人员喜欢在一个缺陷报告里提交多个Bug，这种习惯不提倡，这种方式即不便于分配Bug，也不便于回归验证Bug。

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测试应注意的问题

1.清晰地描述Bug：描述Bug时要用简短的陈述句并能准确指出问题所在。

描述中可能需要提供一些步骤来重现这个Bug，同时这个简短Bug描述必须能够准确地表达出问题的本质所在。

例如，假如针对一个来自服务器的错误，Bug描述要对当完成什么操作时，这个服务器错误就会发生做详尽的说明。

2.不要放过你判断：。

你主要的目标应该是让你的Bug报告令人信服，以支持你发现的Bug，唯一的目的是让Bug 最终关毕。

在Bug报告中试着使用外交的表达方式，而不要使用官方的表述来赞成这个Bug，这样你的报告反而会令人不愉快。

最好的方法是使用建议的方式。

愉快的方式总能被采用。

3．重现的步骤：如何利用对条件设置的解释以重现并获得Bug的精确点，这必须要在Bug报告中讲述清楚。

例如，对于一个绘图软件，测试人员在找Bug之前，需要和开发人员就他已经做了什么进行交流。

细节必须详细说明，像按什么顺序，点击了哪个按钮。

对于按照提示输入命令而运行的程序，在测试Bug之前，应该详细地说明输入命令的详细信息。

4.使用简洁的语言：人们不喜欢读包含复杂的专业术语和绕口的大段的段落。

一个好的Bug报告要包含短的但是表达清晰的语子。

它应该只包含与Bug有关的论述。

不必要把Bug 报告做的过于复杂和写太多事实而篇幅过于长。

避免解说过多对重现Bug没有任何帮助的细节。

大家都普遍知道的事，就不必写在Bug报告中了。

5.引用相关的例子：大部分情况下，要重现一个特殊的Bug，必须输入一些特殊的数据。

但是不要做模糊的表述，像提供一个联系表中无效的人名并保存，应该说在名字域中输入像035bbb@$%这样无效的输入并点击保存。

为了使Bug能快速得到处理，测试人员必须努力提供所有相关的、关键的信息来帮助开发人员。

6.提供参考信息：以防一个特殊的Bug与说明文档或其他的关于工程的文档相冲突，Bug报告必须得供充分的关于这种特殊情况的参考信息或与文档中相冲突条款的数目。