软件缺陷（Software Defect，亦称 Bug）：指的是软件中存在的某种可以破坏软件正常运行能力的问题、错误或隐藏在软件功能中的缺陷。一切的程序、系统与文档中的问题，实际软件与需求说明文档中不一致的情况，软件无法满足用户需求的情况等，全部可以被视为软件缺陷。
标准定义：从软件的内部来看，软件缺陷指的是软件在开发或维护的过程中所存在的错误与其他各种问题。从软件的外部来看，软件缺陷指的是软件与其所需要实现的功能的失效与违背。
IEEE (1983) 729
一般情况下，满足以下情况之一，即可称为软件缺陷：
- 软件未实现产品说明文档中要求的功能。
- 软件出现了产品说明文档中明确指出了的 “不应当出现” 的错误。
- 软件实现了产品说明文档中未要求实现的功能。
- 软件未实现产品说明文档中未要求实现、但是实际上应当实现的功能。
- 软件难以使用、不易使用、运行缓慢或最终用户不满意。
软件缺陷并不全部被称为 Bug，也有其他的称呼方式：
- 缺陷（Defect）
- 故障（Fault）
- 问题（Problem）
- 错误（Error）
- 异常（Anomy）
- 差异（Variance）
- 失败（Failure）
- 矛盾（Inconsistency）
- 事故（Incident）
- 等
- 技术问题
- 算法错误
- 语法错误
- 计算与精度问题
- 参数传递问题
- 等
- 团队协作
- 误解
- 沟通不充分
- 等
- 软件自身
- 文档编写错误
- 用户在不恰当的场合使用
- 时间时区不一致
- 等
由于软件开发流程的初期经常会存在例如 “团队间沟通与协作困难” 的情况，因此接近 60% 的软件缺陷是在开发流程中的 “需求” 阶段出现的，也就是说大多数的缺陷都存在于软件产品说明书（需求规格说明文档）中。
软件开发流程中最早开展的 “需求” 阶段存在最多的缺陷，同时随着时间的推移，修复软件缺陷的成本将会呈指数级增长，因此，在软件开发工作的各个流程都开展审查与评审是非常有必要的。
综上所述，每个软件开发团队都应当意识到：
- 需求评审非常重要。
- 设计评审必不可少。
- 文档更新应当及时。
- 开发测试仔细思考。
软件缺陷的严重性用来表示缺陷所造成的危害的恶劣程度，一般分为以下几种（恶劣程度由高到低排列）：
- 致命缺陷（Fatal）：指的是可以直接造成软件崩溃、挂起、冻结或无响应，或者可以造成软件数据丢失或主要功能完全失效等致命问题的软件缺陷。
- 关键缺陷（Critical）：指的是可以造成软件的主要功能部分失效或者次要功能完全失效的软件缺陷。
- 主要缺陷（Major）：指的是几乎不影响软件正常使用，但是没有完全实现需求、未能达到预期效果的软件缺陷。
- 次要缺陷（Minor）：指的是完全不影响软件正常使用的细微的软件缺陷。
- 建议（Suggestion）：软件产品用户提出的友好建议。
软件缺陷的优先级用来表示修复缺陷时应当遵循的先后顺序。一般情况下，缺陷的优先级可以使用字母 A、B、C、D 或数字 1、2、3、4 进行划分，A (1) 表示最高级别，D (4) 表示最低级别。
- A - 1 - 最高优先级：停止进一步的测试与开发工作，立即修复此缺陷。
- B - 2 - 次高优先级：在软件正式发布前必须修复此缺陷。
- C - 3 - 中等优先级：如果时间允许的话，应当修复此缺陷。
- D - 4 - 最低优先级：可以修复此缺陷，也可以不修复。
注：大部分软件缺陷的严重性与优先级成正比，但不一定完全成正比。
软件缺陷状态主要分为以下几种：
| 软件缺陷状态 | 详解 |
|---|---|
| 激活 / 开启（Active / Open） | 新提交的软件缺陷，正在等待处理。 |
| 已修复（Fixed / Resolved） | 软件开发工程师已经检查并修复此缺陷，但尚未执行回归测试。 |
| 关闭（Closed / Inactive） | 软件测试工程师已经执行回归测试，确认缺陷不再存在。 |
| 重启（Reopen） | 软件测试工程师已经执行回归测试，发现缺陷仍然存在。 |
| 推迟（Deferred） | 这个软件缺陷将在下一个版本中修复。 |
| 保留（On Hold） | 由于某些技术原因，这个软件缺陷暂时无法修复。 |
| 无法重现（Cannot Duplicate） | 软件开发工程师无法重现这个缺陷，需要测试工程师提供重现步骤。 |
| 需要更多信息（Need More Infor） | 缺陷可以重现，但仍需要更多详细信息，例如日志文件等。 |
| 重复（Duplicate） | 这个软件缺陷已经被其他的测试工程师发现。 |
| 非缺陷（Not A Bug） | 这个问题并非是软件缺陷。 |
| 需要修改规格说明书（Spec Modified） | 根据软件规格说明书的相关要求，这个缺陷无法修复，除非先行修改规格说明书。 |
- 口头传达：测试工程师直接联系开发工程师口头说明软件缺陷 ⬇️
- 流水记录：测试工程师将软件缺陷记录至 Word 文档中，开发工程师可以随时查看 ⬇️
- 系统管理：软件项目团队使用专业工具完整的记录与跟踪缺陷的实时处理情况 🚩
- 记录软件缺陷
- 分类软件缺陷（便于分配资源）
- 跟踪软件缺陷的处理情况
只要软件仍然处于生命周期之内，测试工程师无论在任何情况下发现缺陷，都应当及时编写并提交缺陷报告。
- 确保问题可以重现：一个优秀的软件缺陷报告应当可以让其他技术工程师轻松、快速的重现问题。
- 对缺陷进行分析（使用最少的步骤重现问题）：便于开发工程师准确定位软件缺陷的成因。
- 包含重现问题的所有必要步骤。
- 方便阅读。
- 每个软件缺陷报告只记录一个问题。
- 理性编写报告，注意语气态度。
| 软件缺陷报告 | 示例 |
|---|---|
| 编号 | AA8fkj1 |
| 时间 | 2020 年 4 月 3 日 |
| 提交者 | Ling Gao (Microsoft Windows Insider) |
| Windows 版本号 | Windows 10_1909_18363.752 |
| 问题 | 在任务栏搜索框中输入待搜索文本后，无法搜索到任何 Web 结果。 |
| 处理情况 | 已修复 - Resolved |
| 开发工程师答复 | Thanks for reaching out about this - inline web results in Search should now be back up and running for all supported regions. —— Jennifer (Microsoft Engineer) |
请 点击此处 查看由我本人编写的一份软件缺陷调查报告。