软件缺陷管理
缺陷管理
缺陷管理问题的引出
The First “Computer Bug” | 首个“计算机Bug”
Moth found trapped between points at Relay # 70, Panel F, of the Mark II Aiken Relay Calculator while it was being tested at Harvard University, 9 September 1947. The operators affixed the moth to the computer log, with the entry: “First actual case of bug being found”. They put out the word that they had “debugged” the machine, thus introducing the term “debugging a computer program”.
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。 所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
bug 和 defect
飞蛾或者虫子爬进主机引起短路，造成计算机失效的事件中，我们可以看到bug就是虫子或者是虫子引发失效这样的事件。那么defect又是什么呢？
真正的Defect是计算机维护工程师提出来的那个问题：在主机的散热孔那里可以加装一层更加细密的金属网，即不影响散热，又可以防止虫子爬到主机里。这是计算机设计人员疏忽的地方，是产品真正的Defect。而虫子引发的那个故障只是这个Defect导致的故障的其中一种表现形式。也就是说，Bug是Defect的一种表现形式，而一个Defect是可以引起多种Bug的。
术语解释
软件测试使用各种术语描述软件出现的问题，通用的术语如下：
软件错误
Software Error， 导致软件包含故障的人的行为。软件生存期内的人为错误，导致软件缺陷产生。是人为过程，相对于软件本身是外部行为。
在可以预见的时期内，软件仍将由人来开发。在整个软件生存期的各个阶段，都贯穿者人的直接或间接的干预。然而，人难免犯错误，这必然给软件留下不良的痕迹。软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。
软件缺陷
Software Defect，软件的异常情况，软件存在的一些短板。存在于软件（文档、数据、程序）中的偏差，导致软件在某个特定条件下出现故障，这时称软件缺陷被激活。
软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一个逗号、多一语句等。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。
软件故障
Software Fault，引起一个功能组件不能完成所要求的功能的一种意外情况。软件运行过程中出现的不希望或不可接收的内部状态。是动态行为。
软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。譬如，软件处于执行一个多余循环过程时，我们说软件出现故障。此时若无时当的措施（容错）加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。
软件失效
Software Failure，功能组件执行其规定功能的能力丧失。软件运行时产生的不希望或不可接受的外部行为结果。
软件失效是指软件运行时产生 的一种不希望或不可接受的外部行为结果。失效是指功能部件执行其规定功能的能力丧失。软件失效是指软件运行时产生的一种不希望或不可接受的外部行为。
软件错误是一种人为错误。一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时，便产生一个软件故障；同一个软件缺陷在不同条件下被激活，可能产生不同的软件故障。软件故障如果没有集市的容错措施加以处理，便不可避免地导致软件失效；同一个软件故障在不同条件下可能产生不同的软件失效。
缺陷的类型
-
遗漏（Missing）
-
错误（Error）
-
额外的实现（Extra）
-
改进（Enhancement）
缺陷的评价标准
-
软件未实现需求规格说明书要求的功能
-
软件未实现需求规格说明书虽未明确提及但应该实现的目标
-
软件出现了需求规格说明书指明不应出现的错误
-
软件实现了需求规格说明书未提到的功能
-
软件难以理解、不易使用、运行缓慢，或者从测试工程师的角度来看——最终用户会认为不好
缺陷报告
测试执行过程中，发现软件失效后，提出书面的报告，提供给开发人员或者其他负责人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。
软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初并且最好的机会。一个好的描述，需要使用简单、准确、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。因此，准确的报告软件缺陷是非常重要的。
-
清晰准确的软件缺陷描述可以减少被开发人员退回来的缺陷数量
-
提高软件缺陷修复的速度，使每一个小组能够有效的工作
-
提高测试人员的可信任度，可以得到开发人员对有效缺陷的快速或者及时响应
-
加强开发人员、测试人员和管理人员的协同工作，让他们可以更好的工作
缺陷报告单写作准则（5C）
-
Correct（准确）
-
每个组成部分的描述准确，不会引起误解
-
Clear（清晰）
-
每个组成部分的描述清晰，易于理解
-
Concise（简洁）
-
只包含必不可少的信息，不包括任何多余的内容
-
Complete（完整）
-
包含复现该缺陷的完整步骤和其他本质信息
-
Consistent（一致）
-
按照一致的格式书写全部缺陷报告
缺陷报告的有效描述规则
-
单一准确。每个报告只针对一个软件缺陷。在一个报告中报告了多个软件缺陷的弊端，通常是缺陷只能部分被修复，不能得到彻底的修复。
-
可以再现。提供缺陷产生的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷。通常情况下，开发人员只有再现了缺陷，才能够正确的修改。
-
完整统一。提供完整的、前后统一的产生软件缺陷的步骤和信息。例如：图片信息，日志文件等。
-
短小精炼。通过使用关键词，可以使软件缺陷的标题描述既短小精炼，又能准确解释产生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中的
主页、导航栏、分辨率等关键词。 -
特定条件。许多软件功能在通常情况下没有问题，而是在某种特定的条件下才会存在存在缺陷，所以软件缺陷报告描述不要忽视这些看似细节但又必要的特定条件（如：特定的操作系统、浏览器或某种设置等），这些条件是帮助开发人员找到原因的线索。
-
不做评价。在软件缺陷描述中不要带有个人观点，不要对开发人员进行评价。软件缺陷报告是针对产品，针对问题本身，将事实或现象客观的描述出来就可以了，不需要任何评价或议论。
缺陷报告的内容
软件缺陷的属性从大的方面包括以下几部分：
-
可跟踪信息：缺陷标识ID
-
基本描述信息：标题、描述、环境、所属模块、产品版本、状态
-
修正所需信息：严重程度、优先级、类型、频率、缺陷提交人、缺陷指定解决人、来源
-
供事后分析所需的信息：产生原因、构建软件包跟踪、版本跟踪、提交时间、修正时间、验证时间
综上所述，一个完整的缺陷报告需要包括以下内容。
-
缺陷编号
-
缺陷标题和描述
-
缺陷基本信息：操作系统、测试版本、产品和模块
-
缺陷类型
-
缺陷的严重程度
-
缺陷的重现频率
-
缺陷的优先级
-
缺陷的状态
-
缺陷相关人员：提交人、指定解决人、验证人
-
步骤
-
期望的结果
-
实际发生的结果
-
附件：截图、日志文件等
缺陷的状态
| 缺陷的状态 | 描述 |
| ---------------------------- | ----------------------- |
| 激活的或打开的（Active or Open） | 缺陷的起始状态，问题还没有解决，等待修复 |
| 已修正的或已修复的（Fixed or Resolved） | 已被开发人员检查和修复，等待验证人员验证 |
| 关闭的或非激活的（Close or Inactive） | 验证通过，确认缺陷已经可以关闭 |
| 重新打开 （Reopen） | 验证不通过，需要 |
| 推迟 （Deferred） | 缺陷不严重，在下一个版本中解决 |
| 保留 （On hold） | 由于技术原因或者其他原因，暂时无法解决 |
| 功能增强 | 发现的缺陷符合当前说明书。是一个有待改进的问题 |
| 不是缺陷 | |
| 不能重现 | |
| 需要更多信息 | |
缺陷的严重级别
| 缺陷的严重级别 | 描述 |
| ------------ | -------------------------------- |
| 致命（Fatal） | 系统的主要功能完全失效，用户利益受到损失、系统崩溃、死机等 |
| 严重（Critical） | 系统的主要功能部分失效，数据无法保存、提供的服务受到影响 |
| 一般（Major） | 系统的次要功能没有完全实现，不影响用户的正常使用，如提示不准确等 |
| 较小（Minor） | 用户体验不好，不影响功能实现 |
缺陷的优先级
| 缺陷的优先级 | 描述 |
| -------- | ----------------------- |
| 立即解决（P1） | 缺陷导致系统不可使用，无法测试或者测试无法继续 |
| 高优先级（P2） | 缺陷严重，影响测试，需要优先考虑 |
| 正常排队（P3） | 缺陷需要正常排队等待修复 |
| 低优先级（P4） | 缺陷可以在开发人员有时间的时候被修正 |
缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。
一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。
但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。
缺陷跟踪和分析
缺陷生命周期
生命周期的概念是从诞生到消亡所经历的过程。软件缺陷经历了从被发现、报告、到其被修复、验证、直至最后关闭的过程。为了完整的描述这个过程，设定了不同阶段的缺陷状态来体现缺陷不同的生命阶段。对于测试人员来说，需要关注软件缺陷状态的变化，并和开发人员保持良好的沟通，使缺陷能够及时得到处理和修正。
缺陷跟踪和分析
缺陷状态的跟踪
缺陷趋势的分析
缺陷分布分析
累计缺陷趋势分析
