Bug定义及生命周期（七）

BUG

定义

软件的bug，软件程序的漏洞或缺陷 -- 常见，首先发现

软件可改进的细节，或与需求文档存在差异的功能实现等

测试工程师：发现bug，定位bug，提交bug，回归bug

类型

确定bug类型，对开发解决bug意义不大，确定bug类型是为了方便后期测试报告，bug分析进行的

常见类型：

代码错误 -- 占比最大
界面优化 -- UI
设计缺陷 -- 需求不合理，改进，建议性bug

优先级

bug数量和bug等级来考察绩效

但是，很多情况下，提交bug大致等级差不多即可，会影响研发绩效

判断bug等级，常见判断条件

致命错误 --- P1
- 常规操作引起的系统崩溃，死机，死循环，闪退 -- 阻塞，冒烟测试都不通过
- 造成数据泄露安全性问题，比如恶意攻击造成的账户私密信息泄露 -- 安全漏洞
- 涉及巨额的金钱计算和金钱损失 -- 巨额损失，银行，信贷，P2P，电商 -- 看用户基数
- 阻断性测试，所有测试工作进行不下去
- 权限问题 -- 用户越权，vip内容泄露
严重错误 --- P2
- 重要功能是否实现
- 次要功能错误的波及面广，影响到其他重要功能正常实现
- 非常规操作导致的程序崩溃，死机，死循环，闪退 --- 网络异常情况导致，连续点击4-5次才能出现的问题
- 外观界面难以接受的缺陷 --- UI
- 密码明文显示 --- 抓包工具来看
- 偶现的致命性bug
一般错误 --- P3
不影响产品的运行，不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
- 次要功能是否正常实现
- 操作界面错误，包括数据窗口内列名定义，含义不一致
- 查询错误，数据错误显示
- 简单的输入限制未放在前端进行控制
- 删除操作未给出提示
- 偶现的严重性bug
细微错误 --- P4
程序在一些显示上不美观，不符合用户习惯，或者用一些文字的错误
- 界面不规范
- 辅助说明描述不清楚
- 提示窗口文字未采用行业术语
- 界面存在文字错误
改进建议 --- P5
- 提高产品质量的建议，包括新需求和对需求的改进 --- 同类产品，竞品产品

bug生命周期（重点）

bug的生命周期，就是一个bug被发现到bug被关闭的过程

一般缺陷状态：发现 => 新建（提BUG） => 指派 => 已解决 => 待验 => 关闭

bug跟踪流程

发现bug，不要着急提交，记录(截图)，防止偶发性bug，
确认BUG（排除外界因素），确定步骤是否必现？
提交BUG，必现/偶现 -- 提交到哪里？提交给谁？怎么提交？
指派BUG，根据开发计划（人员分配）-- 提交开发本人，提交开发负责人 -- 分配
注意：一定要跟进BUG，P1级别BUG半天就得催
研发确认BUG ，从测试提交的bug的描述中判断，是不是BUG？
重复BUG，其他人提交过BUG，重复开
注意：一定要求开发提供重复BUGＩＤ，是，关闭，说明原因；不是，重新激活，指派开发
.不是BUG，无效BUG，先确认是否为外部因素导致（误操作，网络，环境），然后找产品，确定产品需求
无法重现：
- 偶现BUG，要记录，在标题上标记偶现，后续版本持续的复现，尝试找到稳定的复现的步骤，提供截图，日志linux
- 测试提出一个BUG，开发在开发环境无法复现，让开发来测试环境来看是否复现，修改测试环境BUG，开发修改的代码同步到开发环境
- 测试环境无法复现，持续跟踪大概5个版本，一直持续关注，临近发布版本，依旧无法复现，关闭，备注，遗留BUG
不予解决，测试开发需求理解不一致，找产品确认
延期BUG：本次发布项目不修复，留到下一个版本解决
- 建议性BUG，新功能，动作大
- 修复风险大，可能会引入新的bug，会导致项目延期发布
- 衡量bug对用户的影响，不修复，对用户影响不大，下次发布之前修改；不修复，对用户影响面很广，重激活，说明，产品
回归验证BUG，bug步骤重新测试一遍，这个bug所涉及的功能点，均要测试 -- 开发改动的代码所涉及的点均要回归验证