缺陷和错误之间有什么区别？

• 错误是编码错误的结果

• 缺陷是对要求的偏离

即：缺陷不一定表示代码中存在错误，它可能是尚未实现但在软件要求中定义的功能。

在有关软件测试的Wikipedia页面上：

并非所有软件缺陷都是由编码错误引起的。昂贵缺陷的一种常见来源是由需求缺口（例如，无法识别的需求）引起的，从而导致程序设计者遗漏了错误。[14] 需求缺口的常见来源是非功能需求，例如可测试性，可伸缩性，可维护性，可用性，性能和安全性。

从《实用软件测试》（推荐）一书中引用伊琳·伯恩斯坦的话，该书摘自“ IEEE软件工程标准集合”（1994年）和“ IEEE软件工程术语标准术语表”（标准610.12，1990年）中的定义：

错误

错误是软件开发人员的错误，误解或误解

在开发人员类别中，我们包括软件工程师，程序员，分析师和测试人员。例如，开发人员可能会误解设计符号，或者程序员可能会错误地键入变量名称。

故障（缺陷）

由于错误而导致的故障（缺陷）被引入到软件中。这是软件中的异常，可能导致其行为不正确，而不是符合其规格。

错误或缺陷有时也称为“错误”。使用后一个术语可以简化错误对软件质量的影响。术语“缺陷”的使用还与软件工件（例如需求和设计文档）相关联。这些工件中出现的缺陷也是由错误引起的，通常在检查过程中被发现。

失败的

故障是指软件系统或组件无法在指定的性能要求内执行其所需功能。

在执行软件组件或系统期间，测试人员，开发人员或用户会观察到它未产生预期的结果。在某些情况下，特定类型的不良行为表示存在某种类型的故障。可以说，不良行为的类型是故障的征兆。经验丰富的开发人员/测试人员将具有存储在内存中的故障/症状/故障案例（第3章中所述的故障模型）的知识库。错误的行为可能包括为输出变量产生错误的值，设备部分的错误响应或屏幕上的错误图像。在开发过程中，测试人员通常会观察到故障，而开发人员则可以定位并修复故障。

您可以在此处阅读Google图书中的整章内容。

有一些与软件错误相关的术语。我选修的课程摘录：

• 错误：人为操作或疏忽会导致故障。

• 故障：故障是导致故障的软件缺陷（错误的步骤，过程或数据定义）。

• 错误：与故障相同。

• 失败：软件无法在指定的性能要求内执行其必需的功能。

据此，缺陷和错误之间没有区别。但是，有些人认为错误是在发布软件之前发现的错误，而缺陷是客户发现的错误。

我忍不住发布了著名的“发现错误的第一个实际案例”。

噢亲爱的。

追溯到过去-计算机故障是由各种原因造成的-包括老鼠咀嚼接线和真正的错误（生物）进入工作状态。

术语BUG一直停留在一个术语上，表示某些东西无法按预期工作。

BUG应该被认为是一个术语，表示缺陷。

缺陷是技术上正确的术语，表示事物没有按预期方式运行。

只要有可能，使用DEFECT代替BUG实际上就意味着我们承认我们的失败（我们的缺陷，对用户要求的缺乏理解或我们在实施中忽略的事情），而不是将其打扮成听起来更琐碎的“ bug” ”。

使用默认值。

尽量不要使用术语BUG。它愚蠢，无关紧要，历史悠久且琐碎无聊。

摘自《 IEEE软件工程术语标准标准词汇表》，该书在软件工程知识机构KA中因软件测试和软件质量而被引用：

错误。请参阅：错误；故障。

错误。（1）计算值，观察值或测量值或条件与真实值，指定值或理论上正确的值或条件之间的差。例如，计算结果与正确结果之间相差30米。（2）错误的步骤，过程或数据定义。例如，计算机程序中的指令不正确。（3）错误的结果。例如，当正确结果为10时，计算结果为12。（4）产生错误结果的人为行动。例如，程序员或操作员的错误操作。注意：虽然通常使用所有四个定义，但一个区别是将定义1分配给“错误”，将定义2分配给“故障”，将定义3分配给“故障”，将定义4分配给“错误”。参见a2so：动态错误；致命错误; 本地错误；语义错误 句法错误 静态错误 瞬态错误。

失败。系统或组件无法在指定的性能要求内执行其所需的功能。注意：容错准则区分人为操作（错误），其表现形式（硬件或软件故障），错误结果（故障）和错误结果的数量（错误）。另请参见：崩溃；相依失败; 例外; 故障模式; 失败率; 艰苦的失败 初期失败；独立失败；随机故障 软故障 卡住失败。

故障。（1）硬件设备或组件中的缺陷；例如短路或断线。（2）计算机程序中错误的步骤，过程或数据定义。注意：此定义主要由容错规范使用。在通常的用法中，术语“错误”和“错误”用于表达此含义。另请参见：数据敏感故障；程序敏感故障；等效故障 故障屏蔽 间歇性故障。

我认为失败的定义最相关。一切都是从错误开始的，无论是在需求，设计，实现还是测试用例/过程中。如果此错误在软件中显示出来，则将成为故障。故障是由软件中存在一个或多个故障引起的。

不过，我并不热衷于错误的正式定义。我非常喜欢dukeofgaming在其答案中提供的定义，但是，此答案中的一个是IEEE错误的标准定义。

Dan McGrath的答案非常正确。

• 错误是编码错误的结果
• 缺陷是对要求的偏离

也许举个例子可以更清楚一些。

示例：客户希望Web表单能够保存和关闭窗口。

方案1：Web表单有一个保存按钮和另一个关闭按钮。结果：缺陷，因为客户希望1按钮保存并关闭窗口。开发人员被误解并单独创建。因为两个按钮都满足了他们的要求，所以它不是错误，而是缺陷，因为它不符合客户的要求。

方案2：Web表单具有“保存并关闭”按钮，但仅保存但不关闭。结果：错误。因为该按钮未按要求/预期执行。开发人员知道应该产生该结果，但最终没有。（可能是编码错误）

不知道这是否更清楚。

p / s：从开发人员的角度来看（我曾经是），缺陷和bug都同样重要。我们仍然会修复它。

我们甚至遇到了奇怪的异常，我们将其归类为错误，并不断尝试找出原因以及如何解决。与缺陷相比，将其称为bug并不是一件容易的事。

不同之处在于术语“ bug”听起来很神奇。编程完成后，程序似乎可以随机包含错误。如果它具有随机错误，则表明您不符合规范，并且程序有错误。

缺陷表示程序不符合规范的错误。这更为严重，基本上可以说，任何错误都是程序的一个大问题，这意味着该程序不适合发布。

不同之处在于使用这些术语的程序员的态度。有数以百万计的发布有错误的程序，人们对此表示满意，因为它们出于某种原因接受错误是神奇且随机的，并且每个程序都至少包含一个错误。但是，使用术语“缺陷”的程序员对于发布带有缺陷的程序可能会感到不舒服，因为该术语意味着更高的严重性。

优先选择一个术语而不是另一个术语的含义每天都会影响我们。

根据可靠性：基本概念和术语：

当交付的服务偏离系统功能时，就会发生系统故障，后者就是系统的目标。的错误是这易于导致随后故障系统状态的那部分：影响服务的误差的指示发生故障或已经发生。错误的既定或假定原因是错误。

我将缺陷理解为是缺陷的别称。

错误是令人困惑的，并且取决于上下文，它可能表示故障还是失败。

请注意，这里没有提到规格：即使规格也可能是错误的。

这是我较早时根据ISTQB词汇为我的雇主Q-LEAP做的一项，我还检查了IEEE词汇。请享用。

错误和缺陷？即使可以对此进行无休止的讨论也是如此。我们还有其他事情要担心，生活已经很复杂，等等。

第40页的“如何使用Google测试软件”中有关如何野蛮使用该术语的示例。113.打开“ IEEE软件”的文章，并以相同的方式使用它。确实，在现实生活中很少有人会遇到“缺陷”这个词。

虫子的生活

错误和错误报告是每个测试人员都可以理解的工件。查找错误，分类错误，修复错误和倒退错误是提高软件质量的心跳和工作流程。这是Google最常规的测试部分，但是仍然存在一些有趣的偏离规范的情况。在本节中，我们将忽略为跟踪工作项而提交的错误，并使用该术语来标识实际的损坏代码。因此，错误通常代表工程团队的每小时和每天的工作流程。

一个bug诞生了。Google的每个人都发现并提交了错误。当产品经理在早期版本中发现与其规格/思想不同的问题时，就会提交错误。当开发人员意识到自己不小心检查了一个问题，或者在代码库的其他位置发现了一个问题，或者在对Google产品进行审查时，便提交了bug。错误也来自现场，来自众包测试人员，外部供应商测试，并且由监视特定于产品的Google网上论坛的社区经理提交。许多内部版本的应用程序还具有快速的一键式提交错误的方法，例如Google地图。有时，软件程序会通过API创建错误。

在特定的错误/任务/故障单/缺陷/问题/任何跟踪系统实例之外，这些词没有任何确切含义，因此讨论它们之间的区别是没有意义的。解决工作流时，应先解决术语并提供描述。

在我当前的环境中，“缺陷”是Jira中的任何项目。看来Jira本身使用术语“问题”。我们可能已经从较早的系统继承了它。当某些东西无法按预期和文档中所述运行时，“错误”是一种问题。当某些功能按预期运行但需要改进时，“功能请求”（这很明显而且很重要，但是如果描述了当前行为，它仍然是功能请求）。有更多类型，但是开发团队之外的人使用这两种类型来询问一些问题。

如果您为问题类型选择名称，则“ bug”和“ defect”听起来与我相似。它们之间的差异是风格上的。由于英语不是我的母语，所以我看不到太多，也不确定我所看到的是否正确。