缺陷状态：致命的软件缺陷(Blocker):造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、未考虑异常操作，功能错误等；
严重错误的软件缺陷：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则等；
一般错误的软件缺陷：次要功能没有完全实现但不影
bug的概念和分类
大家好，我是十一。
前面篇我们都在讲测试用例设计的案例、设计方法、工具。本篇呢我们来聊聊bug，程序里的小虫子。
所谓“（Bug）”，是指程序中隐藏的错误或者缺陷。
早在 软件测试的工作周期 一文附录中我们就已经对bug来源做了解释，感兴趣的点击链接回顾。
一条Bug记录最基本应包含：
※bug编号：bug的唯一id，以方便尽快找到此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修改的先后顺序（“缺陷的轻重缓急”）。
具体划分方法各个公司不尽相同，但是通用原则大体一样：
※ 严重性 ：表示软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度。
※ 优先级 ：表示修复缺陷的重要程度和紧迫程度。
下面我们给出严重性和优先级的常用划分方法，需要注意的是，我们这个只是示例，每个公司划分方法也都不尽相同，多多少少有些改变，大家作为参考即可。
严重性：
a.系统崩溃、数据丢失、数据毁坏、安全性被破坏、核心功能未实现（比如QQ 没有做聊天功能）、主体功能实现与需求不符（比如QQ聊天功能只能发消息不能收消息）
b.操作性错误、结果错误、功能模块的某个点未实现（比如QQ没有做消息提醒）,兼容性错误
c.小问题、拼写错误，UI布局不美观、特定情况下的罕见bug
d.一些易用性的建议（也可以归为3）
优先级：
a.立即修复，阻止了进一步测试
b.在产品发布之前必须修复
c.如果时间允许应该修复
d.可能会修复，不影响发布。
再次重申，上述清单只是范例，具体的缺陷划分规则还要依据实际项目、应用场景来制定。比如：通常我们认为毁坏用户数据的缺陷比简单的拼写错误缺陷严重。但是如果数据毁坏仅在用户几乎用不到的罕见特例中出现，而拼写错误导致所有用户安装软件产生问题呢？此时数据毁坏与拼写错误的优先级和严重性就不言而喻了，必然是拼写错误的严重性和优先级高于数据毁坏的。
严重性和优先级对于审查缺陷报告并决定哪些软件缺陷应该修复，以何种顺序修复的人员极为重要。如果一个程序员受命修复10个缺陷，他就应该先从严重性为1 、优先级为1这样的缺陷着手，而不是优先修复简单的，有简到难。
同样，两个项目经理--一个管理广告门户网站/游戏软件，一个管理医院检测仪/性能检测类软件，对待同样的问题就会做出两种选择，比如同样都是页面美观问题，在前者那优先级可能就是2，在后者那可能就是3或者4了。
好了，今天到此结束。如有任何问题请留言及时与我沟通，我会尽快回复大家！谢谢大家~我们下次再见！
bug分类及等级判定条件
Bug等级:
A、致命，B、严重，C、一般，D、轻微
Bug等级划分判定：
致命：
1、影响使用流程（例如：1、报404 ，2、系统主流程进行不下去，系统崩溃，3、闪退）
2、用户数据丢失
3、功能设计与需求严重不符
4、死机
严重：
1、功能未实现
2、影响用户进行下一步操作（无法登录）
3、点击按钮长时间没有反应
4、页面跳转错误
5、需求要求的功能没有全部实现
6、数据错误
7、接口返回错误
8、响应时间长
9、安全性
一般：
1、不影响使主功能的使用
2、与产品要求的功能不一致
3、界面错误
4、提示信息错误（提交成功、网络连接错误，暂无数据）
5、边界值错误
6、跳转设置不好，光标、菜单栏定位错误
7、兼容性问题
8、消息推送不成功
9、长时间未操作无提示
轻微：
1、错别字
2、界面内容显示不全
3、与设计稿颜色不一致
4、易用性
5、操作时没有提示（登录、注册）
6、排版不整齐
总结：
判断bug时也会按照bug优先级来衡量 （例如错别字在轻微等级内，但需要优先修改）
严重性和优先级并不总是一一对应，有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。
PS：以上划分从csdn、51测试、慕课、以及各大测试技术讨论群总结所得，还不够全面只是适合目前的工作所用.........
BUG是什么意思
现在人们将在电脑系统或程序中，隐藏着的一些未被发现的缺陷或问题统称为bug（漏洞）。
由于现代社会的发展，bug另有一种引申意义，用来形容某事物厉害的超乎想象，BUG可以使电脑系统崩溃、容易被施诈者攻击，现有修复漏洞的工具。
扩展资料游戏中的BUG,简单来说就是游戏程序的漏洞，游戏程序中的缺陷。游戏中有BUG是很正常的，尤其是在网络游戏中。即使所有的网络游戏都是经过封测、内测和公测这三个大的步骤，但由于游戏文件和游戏中的任务以及地图的不断更新和增加，难免会在游戏制作方面出现错误和偏差。
1.良性BUG
良性BUG即不会产生严重后果，甚至为玩家带来了利益的BUG。通常很多良性BUG被玩家们利用，方便游戏或副本，不过此举带有一定的作弊性，因此利用这种BUG来游戏是不值得提倡的。例如有些FPS游戏中可以卡入一些副本，从而使得不被击杀。例如在腾讯游戏穿越火线CF中就有很多BUG，其实是玩家无意发现后，后经多方实验确认的一些漏洞，已有部分提交腾讯公司做了修补。
2.恶性BUG
恶性BUG即游戏中致命的，会对游戏过程及体验造成严重影响的BUG。例如正常操作中，由于执行文件冲突或错误不兼容而导致的系统自动退出或者服务器断开等等。《封神榜叁》在开放性内测时，曾出现与服务器断开的情况，在工作人员的及时修补下，很快重新运作。
如何细分bug等级
一、bug等级细分
如何写一个好的 BUG？
1、P0：主功能、主流程无法使用；block其他主要功能测试（用例的执行）。
从当前系统分析：
常规操作引起的系统崩溃、死机、死循环、数据丢失、连接错误
从当前项目需求分析：
当前需求未实现或有严重逻辑性的错误、重要功能无法使用、导致设计方案重新推翻或需要大改的bug
2、P1：严重影响功能体验；某些分支条件下功能无法实现，流程性问题
从当前系统分析：
非常规操作引起的系统崩溃、死机、死循环、数据丢失、连接错误
从当前项目需求分析：
错误的波及面广，影响到其他重要功能正常实现的bug
外观难以接受的bug
P2：其他影响最终上线的 bug，如：样式、文案、不影响用户功能的交互体验
P3：时间来不及基本是不修的，对用户使用没有什么影响或无感知的
二、bug跟踪流程
bug的处理流程，标准是责任制，当前分配给A，A就要处理相应的状态变更，流转至B，B要履行相同的责任
1、P0：登记jira并填写详细的重现步骤，马上跟相应的开发沟通，并在业务沟通群里告知相应的Feature Owner、Team Leader、PM，及时定出解决方案，评估影响，当日解决并回归完成
2、P1：登记jira并填写详细的重现步骤，通知相应的开发，24小时内解决并回归完成，超过规定时间，需根据实际情况，相应调整该bug的等级，通知相应的Feature Owner、Team Leader、PM，及时定出解决方案，评估影响，当日解决并回归完成
3、P2：登记jira并填写详细的重现步骤，通知相应的开发，48小时内解决并回归完成，超过规定时间，需通知相应的Feature Owner、Team Leader、PM，及时定出解决方案，评估影响，当日解决并回归完成
三、bug处理人
1、非必现bug
统计出现率，未超过20%，48小时内找出原因，处理人为QA
统计出现率，超过20%，24小时内找出原因，处理人为RD
2、必现bug
根据PRD，需求不明确，且进入开发流程，处理人为PM
根据PRD，需求明确，且进入开发流程，处理人为RD
根据PRD，需求明确，且进入开发流程，测试理解错误，处理人为QA
处理过程：assigned角色，Bug Category变更，Belong to变更
相关推荐：
