Question

软件缺陷管理

Answer 1

The First “Computer Bug” | 首个“计算机Bug”

1947年9月9日，哈佛大学测试马克II型艾肯中继器计算机，操作员在电板编号为70的中继器触点旁发现了一只飞蛾。然后操作员把飞蛾贴在计算机日志上了，并写下了“首个发现bug的实际案例”。他们提出了一个词，“debug（调试）”了机器，从而引入新术语“debugging a computer program（调试计算机程序）”。

In 1988, the log, with the moth still taped by the entry, was in the Naval Surface Warfare Center Computer Museum at Dahlgren, Virginia.

1988年，这个仍然贴着飞蛾的日志，保存于弗吉尼亚州达尔格伦的海军水面作战中心计算机博物馆。

以下的两句话明确了缺陷的产生。

软件缺陷的产生主要有软件产品的特点和开发过程决定的。比如需求不够清晰，频繁变更等；或者软件由于竞争非常激烈，技术日新月异，使用新技术也容易产生问题。大致有以下几种主要原因：

软件测试就是为了更早、更快的发现缺陷。换句话说，缺陷的发现可以看作是测试工作的主要成果之一。软件缺陷管理的实施，至少有如下三个基本目的：

软件缺陷（Defect），常常又被叫做Bug。 所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

bug 和 defect

飞蛾或者虫子爬进主机引起短路，造成计算机失效的事件中，我们可以看到bug就是虫子或者是虫子引发失效这样的事件。那么defect又是什么呢？

真正的Defect是计算机维护工程师提出来的那个问题：在主机的散热孔那里可以加装一层更加细密的金属网，即不影响散热，又可以防止虫子爬到主机里。这是计算机设计人员疏忽的地方，是产品真正的Defect。而虫子引发的那个故障只是这个Defect导致的故障的其中一种表现形式。也就是说，Bug是Defect的一种表现形式，而一个Defect是可以引起多种Bug的。

软件测试使用各种术语描述软件出现的问题，通用的术语如下：

在可以预见的时期内，软件仍将由人来开发。在整个软件生存期的各个阶段，都贯穿者人的直接或间接的干预。然而，人难免犯错误，这必然给软件留下不良的痕迹。软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。

软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一个逗号、多一语句等。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。

软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。譬如，软件处于执行一个多余循环过程时，我们说软件出现故障。此时若无时当的措施（容错）加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。

软件失效是指软件运行时产生 的一种不希望或不可接受的外部行为结果。失效是指功能部件执行其规定功能的能力丧失。软件失效是指软件运行时产生的一种不希望或不可接受的外部行为。

软件错误是一种人为错误。一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时，便产生一个软件故障；同一个软件缺陷在不同条件下被激活，可能产生不同的软件故障。软件故障如果没有集市的容错措施加以处理，便不可避免地导致软件失效；同一个软件故障在不同条件下可能产生不同的软件失效。

测试执行过程中，发现软件失效后，提出书面的报告，提供给开发人员或者其他负责人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。

软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初并且最好的机会。一个好的描述，需要使用简单、准确、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。因此，准确的报告软件缺陷是非常重要的。

软件缺陷的属性从大的方面包括以下几部分：

综上所述，一个完整的缺陷报告需要包括以下内容。

| 缺陷的状态 | 描述 |

| ---------------------------- | ----------------------- |

| 激活的或打开的（Active or Open） | 缺陷的起始状态，问题还没有解决，等待修复 |

| 已修正的或已修复的（Fixed or Resolved） | 已被开发人员检查和修复，等待验证人员验证 |

| 关闭的或非激活的（Close or Inactive） | 验证通过，确认缺陷已经可以关闭 |

| 重新打开 （Reopen） | 验证不通过，需要 |

| 推迟 （Deferred） | 缺陷不严重，在下一个版本中解决 |

| 保留 （On hold） | 由于技术原因或者其他原因，暂时无法解决 |

| 功能增强 | 发现的缺陷符合当前说明书。是一个有待改进的问题 |

| 不是缺陷 | |

| 不能重现 | |

| 需要更多信息 | |

| 缺陷的严重级别 | 描述 |

| ------------ | -------------------------------- |

| 致命（Fatal） | 系统的主要功能完全失效，用户利益受到损失、系统崩溃、死机等 |

| 严重（Critical） | 系统的主要功能部分失效，数据无法保存、提供的服务受到影响 |

| 一般（Major） | 系统的次要功能没有完全实现，不影响用户的正常使用，如提示不准确等 |

| 较小（Minor） | 用户体验不好，不影响功能实现 |

| 缺陷的优先级 | 描述 |

| -------- | ----------------------- |

| 立即解决（P1） | 缺陷导致系统不可使用，无法测试或者测试无法继续 |

| 高优先级（P2） | 缺陷严重，影响测试，需要优先考虑 |

| 正常排队（P3） | 缺陷需要正常排队等待修复 |

| 低优先级（P4） | 缺陷可以在开发人员有时间的时候被修正 |

缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。

一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。

但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。

生命周期的概念是从诞生到消亡所经历的过程。软件缺陷经历了从被发现、报告、到其被修复、验证、直至最后关闭的过程。为了完整的描述这个过程，设定了不同阶段的缺陷状态来体现缺陷不同的生命阶段。对于测试人员来说，需要关注软件缺陷状态的变化，并和开发人员保持良好的沟通，使缺陷能够及时得到处理和修正。

缺陷状态的跟踪

缺陷趋势的分析

缺陷分布分析

累计缺陷趋势分析