软件测试之BUG篇（定义，创建，等级，生命周期）

目录

1. BUG 的定义

2. 如何创建 BUG

3. 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，开发人员重新修改

高频面试题：

与开发产生争执时，该怎么办：

1. 多反思自身，是不是 BUG 创建的时候描述不清 （带有自我批评思维）
2. 开发人员对 BUG 级别不认可，BUG 级别的下定要有理有据，测试人员要明确企业 BUG 定级规范，拿着规范和开发人员沟通，为什么要这样定级
3. 合理友好的进行沟通，站在用户的角度：如果开发人员为用户，能够接受这样的 BUG吗?
4. 不仅能够提出问题，最好也能够提出解决方案（供开发参考，切忌喧宾夺主）
5. 如果确实有 BUG，友好沟通已经不能够解决问题，那么召开 BUG 审：                         

BUG评审：需要相关代表来参加：产品代表、开发代表、测试等...                                

1）如何解决 BUG                                                                                                            

2）如何预防 BUG 再发生