目录
[1. BUG 的定义](#1. BUG 的定义)
[2. 如何创建 BUG](#2. 如何创建 BUG)
[3. BUG 等级](#3. BUG 等级)
[4. BUG 生命周期](#4. BUG 生命周期)
1. BUG 的定义
- 当且仅当产品规格书存在且正确时，程序的实现和规格书的要求不匹配时，那就是软件错误。
- 当产品规格说明书没有提到的功能时，以用户的为准，当程序没有实现用户合理预期要求时，那就是软件错误。
2. 如何创建 BUG
创建 BUG 的要素：
- 问题出现的版本
- 问题出现的环境
- 出现的步骤
- 预期结果
- 实际结果
- ........
例：
3. BUG 等级
BUG 存在不同的严重级别：
- Blocker（崩溃）：
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单 功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。- Critical （严重）：
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用 冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序 接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测
试）。- Major （一般）：
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等 ( 该问题实际测试中存在最 多）- Minor （次要）：
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格 式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置 不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测 试后期出现较少，应及时处理）不同的严重级别，惩罚机制不同
不同的严重级别，与开发者的能力(开发质量)挂钩
4. BUG 生命周期
- New：新发现的 BUG ，未经评审决定是否派发给开发人员进行修改
- Open：确认为 BUG，并且认为需要进行修改，指派给相应的开发人员
- Fixed：开发人员进行修改的时候表示为正在修改状态，有待测试人员的回归测试验证
- Rejected：开发人员如认为不是 BUG，则拒绝修改
- Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改
- Closed：修改状态的 BUG 经测试人员的回归测试验证通过，则关闭 BUG
- Reopen：如果经验证后 BUG 仍然存在，则需要重新打开 BUG，开发人员重新修改
高频面试题：
与开发产生争执时，该怎么办：
- 多反思自身，是不是 BUG 创建的时候描述不清 （带有自我批评思维）
- 开发人员对 BUG 级别不认可，BUG 级别的下定要有理有据，测试人员要明确企业 BUG 定级规范，拿着规范和开发人员沟通，为什么要这样定级
- 合理友好的进行沟通，站在用户的角度：如果开发人员为用户，能够接受这样的 BUG吗?
- 不仅能够提出问题，最好也能够提出解决方案（供开发参考，切忌喧宾夺主）
- 如果确实有 BUG，友好沟通已经不能够解决问题，那么召开 BUG 审：
BUG评审：需要相关代表来参加：产品代表、开发代表、测试等...
1）如何解决 BUG
2）如何预防 BUG 再发生