【软件测试】软件缺陷（Bug）的详细描述

目录

一、软件缺陷（Bug）

1.1 缺陷的判定标准

1.2 缺陷的生命周期

1.3 软件缺陷的描述

1.3.1 提交缺陷的要素

1.3.2 Bug 的级别

1.4 如何发现更多的 Bug？

1.5 缺陷的有效管理

1.5.1 缺陷的编写

1.5.2 缺陷管理工具

1.5.2.1 缺陷管理

1.5.2.2 用例管理

---

一、软件缺陷（Bug）

1.1 缺陷的判定标准

Bug的概念：当且仅当规格说明是存在的并且正确，当程序没有实现其最终用户合理预期的功能要求就是软件错误。

判断标准以最终用户为准（站在用户的角度看是否实现用户的需求）

案例如下：

1. 软件未实现需求规格说明书中明确要求的功能-->少功能

2. 软件出现了需求规格说明书中指明不应该出现的错误-->功能错误

3. 软件实现的功能超出需求规格说明书指明的范围-->多功能

4. 软件未实现需求规格说明书中虽未明确指明但应该实现的要求-->隐性功能错误

5. 软件难以理解，不易使用，运行缓慢，用户体验不好-->不易使用

缺陷产生的原因：

1. 需求阶段：需求描述不易理解，有歧义、错误等

2. 设计阶段：设计文档存在错误或者缺陷

3. 编码阶段：代码出现错误

4. 运行阶段：软硬件系统本身故障导致软件缺陷

1.2 缺陷的生命周期

注意事项：

1. delay的 bug 不是说不修复，只是当前版本不修复，但是未来一定要修复。

2. 如果出现了delay 和 Rejected 这种Bug，QA质量保证 一定要将这些 Bug 告知给相关人员以及项目相关 Leader

3. 发送测试报告的时候也要指出 delay 和 rejected 这种 bug

4. 缺陷状态变更流程每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用。

1.3 软件缺陷的描述

1. 缺陷的标题：描述缺陷的核心问题（操作数据描述+预期+实际）

2. 发现问题的版本：开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。

3. 问题出现的环境：环境分为硬件环境和软件环境，详细的环境描述有利于故障的定位。

   1. 软件环境：