文章目录
- 一、前言-用例评审
- 二、BUG定义+类型+等级
-
- [2.1 什么 BUG？](#2.1 什么 BUG？)
- [2.2 BUG 类型](#2.2 BUG 类型)
- [2.3 BUG的等级](#2.3 BUG的等级)
- [2.4 BUG的类型及等级判断](#2.4 BUG的类型及等级判断)
- [2.5 BUG的生命周期及流程](#2.5 BUG的生命周期及流程)
一、前言-用例评审
二、BUG定义+类型+等级
2.1 什么 BUG？
缺陷 (错误)/ 漏洞 / 改进与建议 / 不符合需求
2.2 BUG 类型
什么是 BUG 的类型：bug 是属于哪方面不符合需求导致的
bug 常见的类型有哪些
- 代码（功能）错误：因为实现的功能跟需求不一致导致的这类的 bug，这类 bug 是最多的
- 界面优化：界面不好看，或者不符合用户使用习惯的这类 BUG
- 设计缺陷：与开发、产品需求文档不一致的
2.3 BUG的等级
- 1、致命的（blocker）
常规操作引起的系统崩溃、死机、死循环、闪退
造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露
涉及金钱计算
阻断性测试，所有测试工作进行不下去（冒烟测试） - 2、严重错误（critical）
重要功能不能实现；
错误的波及面广，影响到其它重要功能正常实现；
非常规操作导致的程序崩溃、死机、死循环、闪退
外观 (界面) 难以接受的缺陷；
密码明文显示；(界面 + 数据库)
偶现的致命性 bug - 3、一般错误：不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
次要功能不能正常实现；
操作界面错误（包括数据窗口内列名定义、含义不一致）；
查询错误，数据错误显示；
简单的输入限制未放在前端进行控制；
删除操作未给出提示；
偶现的严重性 bug - 4、细微错误：程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误
界面不规范；
辅助说明描述不清楚；
提示窗口文字未采用行业术语；
界面存在文字错误； - 5、 改进建议：可以提高产品质量的建议，包括新需求和对需求的改进。
2.4 BUG的类型及等级判断
1，2，3，4对应BUG的等级，其中1-5部分是代码功能bug，6-8界面错误，9是代码功能错误。
2.5 BUG的生命周期及流程
BUG生命周期是一个追溯、修复和验证的过程，经历了从发现到修复再到验证的多个阶段。以下是Bug的典型生命周期：
-
提交（Submit）：
生命的起点通常是Bug的发现。这可以由开发人员、测试人员、最终用户或其他相关方发现。Bug会被提交到缺陷跟踪系统中，其中包含详细的Bug描述、重现步骤、环境信息等。
-
分配（Assign）：
提交后，Bug会被分配给相应的开发人员或团队。这个过程通常由项目管理人员或缺陷跟踪系统自动完成。
-
修复（Fix）：
开发人员根据Bug报告中提供的信息，定位并修复Bug。修复完成后，开发人员通常会将其关联到相应的Bug报告中，并提交代码变更。
-
验证（Verify）：
测试团队或相关人员接收到Bug修复的通知后，会进行验证。他们会重新运行之前的测试用例，以确保Bug已被成功修复。如果验证通过，Bug将被标记为已解决。
-
关闭（Close）：
验证通过后，Bug会被关闭。此时，Bug报告的生命周期就告一段落。一些团队还会要求提交者或验证者提供额外的反馈，以确保Bug的修复对整个系统没有负面影响。
