Bug提交和Bug生命周期管理
作者：互联网
一、缺陷概述
✨缺陷（Defect）：是指存在于软件之中偏差，可被激活，以静态形式存在于软件内部，相当于Bug。
✨故障（Fault）：当缺陷被激活后，软件运⾏中出现的状态，可引起意外情况，若不加处理，可产⽣失效，是⼀个动态⾏为。（如系统崩溃、数据丢失、系统雪崩）
✨失效（Failure）：软件运⾏时产⽣的外部异常⾏为结果，表现与⽤户需求不⼀致，功能能⼒终⽌，⽤户⽆法完成所需要的应⽤。
✨Bug：电脑系统或者程序中存在的任何⼀种破坏正常运转能⼒的问题或者缺陷，都可以称之为“Bug”；有时也泛指因软件产品内部引起的软件产品最终运⾏时和预期结果的偏离。
✨缺陷报告单：指测试执⾏过程中，发现缺陷失效后，提出书⾯的报告，提供给开发⼈员作为定位缺陷的依据。
二、缺陷类型
✨建议：针对一个产品的，提出自己的建议，这个建议只能给产品经理，不能说是问题，产品经理可以接收，也可以不接收
✨优化：优化是提交给程序员和产品经理，不一定非要修改，如果衡量不修改，也可以拒绝修改，也可以遗留到后期修改，也可以由优化来产生新的需求
✨BUG/缺陷/Issus：指的就是产品的期望结果与实际结果不符合
✨故障：一般指的是生产环境中产品出现严重的问题，导致产品不可用或者是雪崩（当雪崩的时候，没有一片雪花是漂亮的）
三、缺陷状态
主要描述缺陷当前的状态。状态如下：
✨新建：测试⼈员新提交的bug、优化或者建议的状态。
✨进⾏中：开发⼈员确认是bug，在修复bug过程的状态。
✨已解决：开发⼈员已修复bug的状态。
✨已关闭：测试⼈员验证修复的bug，确定已解决问题的状态。
✨不解决：开发⼈员认为不是bug，拒绝解决问题的状态或者⽆法解决问题的状态
✨重开：测试⼈员验证修复的bug，发现没有完全修复好bug，重新打回开发⼈员的状态。
✨暂缓：开发⼈员认为该bug不急于修复，可以放置⼀段时间再修复的状态。
四、缺陷的生命周期
流程描述：
1、风险问题后提交问题给具体的开发人员
2、开发人员核对问题后，如果是问题，进行修改
3、开发把修改后的问题反馈给测试，测试这边验证，如果通过。就关闭问题
4、开发人员核对问题不是问题，反馈给测试，拒绝修改，测试这边核对不是问题，撤销该问题
5、开发把修改后的问题反馈给测试，测试这边验证还是没通过，再次反馈给测试
五、缺陷级别
✨致命：系统崩溃、数据丢失、数据毁坏、安全性被破坏。
✨严重：操作性错误、结果错误、功能遗漏。（一般指逻辑问题和影响流程功能问题）
✨⼀般：⼩问题、拼写错误、UI布局、罕⻅错误。（一般指页面交互 浏览器兼容性、错误提示信息不合理的问题）
✨建议：对产品的改进建议。
六、缺陷优先级
优先级表示修复缺陷的重要程度和紧迫程度。（可和缺陷级别一一对应起来）
✨紧急：影响进⼀步测试，需要⽴即修复。
✨⾼：必须在版本发布前修复。
✨中：必须要修复，不⼀定⻢上修复，可以讨论确定在某个时间节点修复好。
✨低：对产品影响⽐较少，不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复。
七、BUG的要素
1、前提条件
2、测试步骤
3、实际结果
4、期望结果
智联招聘网站缺陷描叙练习
前提条件： 1、首页可以访问
测试步骤： 1、在登录的手机号输入框里面输入了11111111111 2、输入后就自动获取验证码
实际结果： 1、输入不规范的手机号码依然能够获取验证码
期望结果： 1、输入不规范的手机号码，不能自动获取手机验证码
八、BUG注意事项
1、BUG步骤一定要具备可操作性（操作步骤要清晰，通俗易懂）
2、提交的BUG最好有错误的截图信息以及日志信息
页面交互/错误提示信息举例：
1、错误截图信息应用场景
1）如后台错误（一码通扫描二维码出不来，一直加载）：
①加载不出来的截图
②加载不出来这个时候后台的错误log（扫描时候的日志一直到加载不出来的日志信息）
2、日志信息应用场景
单纯的后台服务： 从后台获取错误日志信息（出问题那个时刻的日志上下文，如出问题是09:50:55，那么获取的日志是55（53-57）秒的下上文）
标签：生命周期,修复,测试,Bug,问题,提交,日志,缺陷,bug 来源： https://www.cnblogs.com/cch6842/p/16470862.html