BUG的定义&生命周期
1、bug的定义
软件的Bug狭义概含是指软件程序的漏洞或缺陷， 广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节(增强性，建议性)、或与需求文档存在差异的功能实现等。
作为测试人员主要职责就是发现这些Bug,并提交给开发，让开发去修改。
2、bug的分类
常见的bug类型划分(禅道系统为例) :
代码（功能）错误：--最常见--优先级偏高 界面优化--- UI测试：优先级偏低 设计缺陷-- 优化建议：需求上就是不合理--优先级偏低--慎重一点（跟产品确定好）
PS：具体还是按照公司具体的规定来分类
3、bug的等级 (严重程度)
bug等级，这个划分有分三级或四级，也有分五级的。如果是等级越高(严重)，那么可能被修复的等级也会高一些， 然后有些公司还会根据你提的bug数量和bug等级来考察你的绩效。很多情况下，我们提交bug大致的等级差不多即可，没有严格区分。
如何来判断bug的等级(严重程度)， -般可以参照下面的判断条件。
(1)致命错误: --- blocker 1、常规操作引起的系统崩溃、死机、死循环、闪退 --P1 2、造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露 3、涉及金钱计算--公司巨大损失，业务 4、阻断性测试，所有测试工作进行不下去(冒烟测试) --登录 5、权限问题-爱奇艺资源会员? ?
(2）严重错误:一critical 1、重要功能不能实现: 2、错误的波及面广，影响到其它重要功能正常实现; --12306购票系统<--咨询 3、非常规操作导致的程序崩溃、死机、死循环、闪退 ---连续10次点击登录按钮 4、外观(界面)难以接受的缺陷; 5、密码明文显示: 前端处理bug后端-服务器(数据库验证) --安全 6、偶现的致命性bug
(3)一般错误: --major ==大多数bug是这个类型 不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷 1、次要功能不能正常实现: 2、操作界面错误(包括数据窗口内列名定义、含义不一致) ; 3、查询错误，数据错误显示; 4、简单的输入限制未放在前端进行控制; 5、删除操作未给出提示; --友好型 6、偶现的严重性bug
（4）细微错误: - minor 程序在，些显示上不美观，不符合用户习惯，或者是一些文字的错误 --用户体验 1、界面不规范: 2、辅助说明描述不清楚; 3、提示窗口文字未采用行业术语: 4、界面存在文字错误:
PS：工作中特别注意，像严重和致命级别的bug，最好事先跟开发沟通确认，因为这类bug有可能会影响他们的绩效，工作中人际关系也是很重要的一个方面哟。
4、bug的生命周期(管理流程)
bug的生命周期，就是一个bug被发现到这个bug被关闭的过程。这个过程有哪些步骤?
生命周期中一般缺陷状态:
发现--提交bug ->指派-> 已解决->回归验证->关闭。--一般情况
如果待验的bug在验证时没有解决好，我们需要重新打开(激活) -指派->已解决->回归验证，循环这个过程。中间其他状态:拒绝、延期等
我们来看一个bug的处理流程图(生命周期图)，让大家更深刻地理解周期中bug的状态及相应处理。
5、bug的跟踪管理流程
6、bug的跟踪管理-状态处理
1.已经指派的bug---已经指派给开发的，请大家注意自己bug的走向，随时关注并进行跟踪!如果一直未修复，提醒开发修改，以免开发忘记:如果已经修复等待测试环境更新后进行验证。催着改bug
2.已解决的bug---等待测试环境更新后进行验证，验证通过则关闭:验证不通过则重新打开指派给开发
3.重复bug--先去查看下是否跟开发指定的bug重复?如果确定是重复则关闭;如果不重复，说明原因，重新打开指派给开发，
4.不是缺陷--再次依据需求确认，是否是bug,如果依然觉得是缺陷跟开发沟通，列举出来觉得是bug的点，沟通未达一致找产品确认，确认是bug注明情况并再次指派给开发，产品确认不是bug,就不纠结，直接关闭bug,但是，会拿小本本把这个bug记录下来，等到测试任务结束后，再来研究研究。
5.无法重现----确认开发环境是否跟测试环境一致? 包括操作步骤、浏览器、环境、特定账号、输入数据等，如果多个版本验证之后，如开发所说重现不了，依据bug的严重程度跟产品、开发一起确认关闭;如果找到重现原因， 注明清楚并再次指派给开发
6.不予解决---找产品经理进行确认。确认不予解决进行关闭;确认需要解决请备注原因并打开指派给开发
7.设计如此---找产品经理进行确认。确认设计如此进行关闭;确认是问题，备注原因重新指派给开发
8.延期修改---请看下bug严重程度，是否影响当前版本发布?与产品经理进行确认。不予延期请根据情况进行激活与情况说明;确认延期则做好记录，后续版本进行关注一不关闭
7、bug的跟踪管理缺陷管理工具
常见的缺陷管理平台:
禅道(zentao) ：非常常见 bugilla, jira: 比较常见。搭建起来略困难 bugfree: Readmine easybug:免费开源,在线网站类型的 QC(QualityCenter). TD 公司内部自研平台：比如华为有DTS
PS:不管是开源还是商业的缺陷管理工具，它们本质都是一样的，用来管理bug的生命周期。掌握其中一款工具，其他的工具主要是界面不同，思想都是类似。
8、如何提交bug
发现bug后，接下来你提交到bug管理平台，提交一个bug包含哪些内容?
bug标题——标题要清晰简洁，写明bug描述;如果没有选择功能模块，最好在标题中标注功能模块。让查看bug的人员清楚知道你所表达的意思。版本号+bug的功能模块+bug的操作+bug的结果
bug类型和严重程度——便于后续测试结果分析，bug的统计
bug测试环境——什么环境（自动化环境、镜像环境、生产环境等），哪个版本等。
重现步骤——详细写下发现bug的测试过程。能指导开发重现这个bug。附上测试数据
实际结果——出现bug的结果，粘贴bug截图、日志截图难以截图的甚至可以附上录屏
预期结果——写清楚测试用例预期的结果
附件——日志文件，文件测试数据。图片、崩溃日志文件等(不是必须)
标签：生命周期,定义,--,指派,确认,bug,---,开发,Bug From： https://www.cnblogs.com/ajimide8760/p/16585852.html