什么是 Bug？

在计算机技术中，计算机程序中的编码错误通常被称为 bug。这不仅包括明确编写的代码，还包括内置到计算机微处理器中的指令。识别和解决这些 bug 的过程称为调试。在用户遇到 bug 之前检测和解决 bug 至关重要。调试在代码生成后开始，并一直持续到代码与其他编程单元集成以形成操作系统和应用程序等软件产品。

Bug 通常在公开的 beta 测试期间或产品发布后发现。当这种情况发生时，客户需要从程序开发者那里获得修复，或者想办法避免使用有缺陷的代码。

程序可能遇到的问题的一种类型是 bug。即使没有 bug，程序仍然可能难以使用或未能达到重要目标。测试这种类型的问题更具挑战性。在精心设计的程序中，通过良好的控制过程创建的程序，每千行代码的 bug 更少。因此，在进行测试时应考虑可用性。

软件 Bug 的类型

各种 bug 会导致计算机故障。以下是一些最常见的计算机 bug 类型

• 算术型：算术型 bug，通常称为计算错误，是程序中的数学错误，导致程序无法正常工作。
• 接口型：当不兼容的系统连接到计算机时，会发生接口型 bug。软件或硬件可能是问题的根源。应用程序编程接口中可能会发现一个接口型 bug 的例子。
• 逻辑型：当脚本的逻辑导致程序提供不正确的信息或卡住而一无所获时，就会发生这些错误。无限循环是一种逻辑错误，当一系列指令不停运行时。
• 语法型：包含这些 bug 的代码是使用不正确的字符创建的。各种编程语言的语法各不相同，因此使用一种语言的语法可能会破坏另一种语言的 bug。
• 协作型：当程序员之间沟通不畅时，就会出现这种 bug。一个例子是产品及其文档中发现的差异。另一个例子是程序代码在注释中被误述。
• 从用户的角度组织 bug 是另一种简单的方法。这些 bug 类型包括以下几种
• 图形型：尽管用户可以完成选定的任务，但程序似乎存在 bug。这可能是应用程序响应式设计的问题。
• 功能型：功能型 bug 是指程序无法按预期运行。例如，当用户点击保存按钮时，信息未被保存。

根据用户处理 bug 的难易程度，还可以对 bug 进行分类

• 低影响 bug 对用户与系统的交互方式影响很小。
• 高影响 bug 会影响某些功能，但程序仍可运行。
• 严重 bug 会阻碍程序的正常运行。

另一种分类 bug 的方法是考虑它们的位置

• 限制在单个代码单元中的简单软件 bug 称为单元级别 bug。它们通常涉及单一的软件部分，并且是计算或逻辑错误的产物。通常，它们很容易修复。
• 由多个软件组件的交互引起的更复杂的 bug 称为系统级别 bug。
• 当用户以意想不到的方式与程序交互时，就会发生越界 bug。例如，当用户在表单字段中提供程序未处理的参数时，就会发生这种情况。软件可能被越界 bug 利用。例如，威胁行为者利用 Infra: Halt 漏洞通过域名系统缓存投毒来攻击运营技术。

如何避免 Bug？

根据 bug 的类型以及发现的位置和时间，可以使用各种方法来修复 bug。

开发过程

预防措施是处理编程问题的最有效方法。通过使用可靠的软件开发策略，例如敏捷和 DevOps 方法，可以完全避免 bug。质量测试是这些开发过程的组成部分。

测试驱动开发就是这样一种技术。为了提供一个标准来编写代码功能，应该在开发功能之前编写测试。

另一种推荐的方法是使用行为驱动开发，它鼓励程序员根据用户预期如何与其交互来创建应用程序并记录过程。

软件测试

可以通过测试来查找软件中的 bug。以下是软件测试的三种类别

在进入下一个测试阶段之前，功能测试包括检查程序的关键功能组件是否存在软件缺陷。此测试步骤验证每个组件是否正常工作。功能测试的另一个名称是冒烟测试。

探索性测试包括用于测试不太常见的软件路径或典型功能测试会遗漏的路径的技术。例如，覆盖率测试是探索性测试的一种，它确定应用程序在各种硬件、操作系统和浏览器上是否正常工作。

回归测试的目的是确定早期的代码修改是否导致了意外的问题。回归测试的类型如下

• 单元测试
• 集成测试
• 系统测试
• 验收测试

开发人员尽早、频繁地进行测试有助于防止 bug 传播给用户。除了软件测试外，与其他开发人员、高级开发人员或质量保证 (QA) 团队进行同行代码评审也很有帮助。

比较和对比

通过基准测试或基准测试为不同类型的工作负载建立软件性能基线。通过基准测试可以评估软件的稳定性、响应速度、速度和有效性。

在某些环境中，潜在的 bug 可能会成为严重的问题。基准测试有助于查找这些 bug。以下是一些基准测试类型的示例

通过负载基准测试，软件系统在特定负载下进行评估，该负载通常是给定应用程序预期的典型流量量。

峰值基准测试评估软件在工作负载突然激增下的功能。断点基准测试测试软件在崩溃之前能承受的最大压力。

如何修复 Bug？

软件 bug 在被发现时需要进行调试。调试包括以下三个阶段

1. 应隔离 bug。
2. 查明根本原因。
3. 解决问题。

对于构建代码的开发人员来说，追溯他们的步骤并筛选复杂而密集的代码行可能很困难。一种方法是通过 bug 赏金计划来众包调试项目。软件安全研究人员和道德黑客因识别问题并提交可复制或减轻漏洞的 bug 报告而获得报酬。

持续开发

试图减少软件 bug 的组织应平衡软件发布的回滚和推出。通过这样做，他们确保调试过程不会干扰常规软件发布时间表。在敏捷开发环境中运行的组织通常会执行此活动。

然而，一些 bug 最终还是会出现在最终版本中。作为调试过程的一部分，开发团队可以将发布视为收集反馈、快速失败和进行调整的机会。

软件 bug 可以由团队或团队的单个成员在每天设定的时间段内解决。通过这种方式，bug 数据收集和实际调试过程成为日常工作的一部分。团队可以使用有关调试过程的数据来预测特定补丁需要多长时间，并相应地规划其工作。

并非所有问题都可以一次性解决，并且需要时间来编译数据以生成准确的 bug 估算。程序员的技能和熟练程度各不相同。此外，在不同国家工作的程序员对 bug 修复的估算可能有所不同。团队可以随着时间的推移为在一个月内可以解决的 bug 数量建立基准估算。

调试没有完美或完成的。总有新的 bug 需要发现。对于每个软件版本，开发团队都应努力为利益相关者提供净积极的价值，并有效地修复 bug。

软件 Bug 的历史

工程领域催生了 bug 这个词。开创性编码员 Grace Hopper 被认为是创造了计算机世界的这个词。Hopper 是海军预备役的一名年轻中尉，她于 1944 年在哈佛大学的 Mark I 计算机上工作。后来，Hopper 讲述了一个技术人员从 Mark II 计算机的两个触点之间移除一个真正的 bug——一个飞蛾——的故事。这只飞蛾被海军展览了很多年。它现在由史密森尼学会保管。

尽管 bug 通常会导致恼人的计算机问题，但它们可能产生更具破坏性的影响。根据《连线》杂志 2005 年的一篇文章，列出了历史上最糟糕的十个软件 bug，这些缺陷导致了人员伤亡、太空任务损坏和大规模爆炸。例如，1982 年，由于一个据称由中央情报局安装并控制西伯利亚大铁路的系统，发生了历史上最大的非核爆炸。

据报道，一种名为“竞争条件”的辐射治疗设备存在 bug，导致 1985 年至 1987 年间输送了致命剂量的辐射，造成五人死亡，多人受伤。由于一个可能导致发动机熄火并亮起警告灯的 bug，丰田汽车在 2005 年不得不召回 160,000 辆普锐斯。

2016 年，发生了一起与特斯拉 Autopilot 系统故障相关的重大事故。该系统未能检测到一辆白色的拖挂卡车在明亮的蓝天背景下横穿高速公路，导致了一场悲剧性事故，造成人员死亡。