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

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

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

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

***系统测试（第一轮）
测试人员：****
测试时间：2013-03-23
Bug状态标识统一标准
请各开发人员在每个BUG后注明状态及修正人员名字，规定如下：
1.修正[Fixed]：开发人员已完成修正，等待测试人员验证；
2.拒绝[Declined]:拒绝修改缺陷；
3.延期[Deferred]: 不在当前版本修复的错误，下一版本修复；
4.重复[DUPLICATE]：提出的问题和当前已经存在的某个BUG重复；
5.关闭[Closed]：错误已被修复。

（如：某BUG是开发人员张三修正的，则在该BUG后如此填写： [修正]张三）
测试环境描述
测试地址：http://192.168.0.199/index.aspx
测试浏览器：IE6-8、FF
测试操作系统：WINXP
Bug
当前登录系统角色：管理员
用户名：admin 密码：111111
1、当删除列表中任一条数据后，刷新页面，报错，如下图所示：[修正]李四
2、管理员删除某一类别后，普通用户登录，在“供应商快速抽取”和“评委抽取”列表中，还能看到抽取的类型，刷新页面后才看不到！[延期]王麻子
当前登录系统角色：普通用户
用户名：111111 密码：111111
1、项目管理——添加项目
项目添加成功后没有提示！[关闭]李四
2、添加和编辑项目，当在“说明”文本区域输入一定数量文字后，保存报错[修正]李四。

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）的概述及书写规范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提交模板和注意事项一、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）：界面重构、描述更改、流程改进。

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的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数量、严重性等可以看出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等级：低发现阶段：测试阶段。