BUG的生命周期

BUG的定义：软件程序的漏洞或缺陷，还包括测试工程师或用户所发现和提出的软件可改进的细节，或需求文档存在差异的功能实现等。

常见的BUG类型（禅道系统为例，可自定义）
代码错误、设计缺陷、界面优化、（主要在前三个）性能问题、配置相关、安装部署、安全相关、标准规范、测试脚本、其他
其他划分：功能类、界面类、性能类、易用性类、兼容性类、其他
练习

1代码错误 严重 2.
3.兼容性 严重 4.性能问题 严重
5. 功能 严重 6.功能 严重
7.功能 致命 8 习惯性 细微
9设计 细微 10习惯性 细微

BUG的等级（严重程度）
1.致命错误
1）常规操作引起的系统奔溃、死机、死循环
2）造成数据泄露的安全性问题，比如恶意攻击造成的账户私密信息泄露
3）涉及金钱计算
2.严重错误
1）重要功能不能实现
2）错误的波及面广，影响到其它重要的功能正常实现（功能交互）
3）非常规操作导致的程序奔溃、死机、死循环
4）外观难以接受的缺陷（举例：直播平台的美女图片）
5）密码明文显示（界面+数据库）
3.一般错误
不影响产品的运行，不会成为故障的起因，但对产品外观和下道工序影响较大的缺陷
1）次要功能不能实现
2）操作界面错误（包括数据窗口内列名定义、含义不一致）
3）查询错误，数据错误显示
4）简单的输入限制潍坊到前端控制(格式限制)【比如手机号码，用户名格式】
5）删除操作未给予提示（二次确认窗口）
4.细微错误
程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误
1）界面不规范
2）辅助说明描述不清楚
3）提示窗口文字未采用行业术语
4）界面存在文字错误
改进意见：可以提高产品质量的建议，包括新需求和对需求的改进
BUG的生命周期
从发现——>到提交到缺陷管理平台——>指派开发——>已解决——>待验——>关闭

BUG的状态处理-测试
1.已经指派的bug——已指派开发，注意bug的走向，随时关注并进行跟踪！若一直未修复，提醒开发，以免忘记。若已修复等待测试环境更新后进行验证
2.已解决的bug——等待测试环境更新后重新验证，通过关闭。否，指派开发
3.重复的bug——是否与开发指定重复，重复关闭，否指派开发
4.不是缺陷——确认开发环境是否与测试环境一致，确定不是缺陷后关闭，否·····
5.无法重现——确认开发环境是否与测试环境一致，包括操作步骤、浏览器、特定账号等，若多个版本验证后，如开发所说无法重现，可依据bug严重程度跟产品、开发一起确认关闭，否·····
6.不予解决——找产品经理确认。确认不予关闭，否···
7.设计如此——找产品经理确认。确认设计如此关闭，否····
8.延期修改——查看bug严重程度，是否影响当前版本发布？与产品经理确认。不予延期根据情况进行激活与情况说明；确认延期，做好记录，后续版本进行关注
作业：印象深刻的bug
12306买票系统的验证码