Bug定义及生命周期（七）

BUG

定义

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

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

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

类型

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

常见类型：

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

优先级

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

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

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

bug生命周期（重点）

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

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

bug跟踪流程

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