## 缺陷的内容
缺陷：软件缺陷（Defect），常常又被叫做Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致[软件]产品在某种程度上不能满足用户的需要。IEEE729-1983对[缺陷]有一个标准的定义：从产品内部看，缺陷是[软件]产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
缺陷类别：
缺陷的表现形式不仅体现在功能的失效方面，还体现在其他方面。主要类型有：
1软件没有实现产品规格说明所要求的功能模块；
2软件中出现了产品规格说明指明不应该出现的错误；
3软件实现了产品规格说明没有提到的功能模块；
4软件没有实现虽然产品规格说明没有明确提及但应该实现的目标；
5软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好。
以计算器开发为例。计算器的产品规格说明
定应能准确无误地进行加、减、乘、除运算。如果按下加法键，没什么反应，就是第一种类型的缺陷；若计算结果出错，也是第一种类型的缺陷。
产品规格说明书还可能规定计算器不会死机，或者停止反应。如果随意敲键盘导致计算器停止接受输入，这就是第二种类型的缺陷。
如果使用计算器进行测试，发现除了加、减、乘、除之外还可以求平方根，但是产品规格说明没有提及这一功能模块。这是第三种类型的缺陷——软件实现了产品规格说明书中未提及到的功能模块。
在测试计算器时若发现电池没电会导致计算不正确，而产品说明书是假定电池一直都有电的，从而发现第四种类型的错误。
软件测试员如果发现某些地方不对，比如测试员觉得按键太小、“=”键布置的位置不好按、在亮光下看不清显示屏等，无论什么原因，都要认定为缺陷。而这正是第五种类型的缺陷。
根据以上五种缺陷类型，在软件测试中可以区分不同类型的问题。
## 分类标准
### 缺陷属性
1.缺陷标识(Identifier)： 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识。
2.缺陷类型 (Type)： 缺陷类型是根据缺陷的自然属性划分的缺陷种类。
3.缺陷严重程度 ：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
4.缺陷优先级(Priority)： 缺陷的优先级指缺陷必须被修复的紧急程度。
5.缺陷状态(Status) ：缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
6.缺陷起源(Origin) ：缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。
7.缺陷来源(Source)： 缺陷来源指引起缺陷的起因。
8.缺陷根源(Root Cause)： 缺陷根源指发生错误的根本因素。
### 缺陷严重程度（Severity）
[**软件测试**]**错误严重程度**
1.Critical：不能执行正常工作功能或重要功能。或者危及人身安全。
2.Major：严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）
3.Minor：严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）
4.Cosmetic：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
5.Other：其它错误。
**评审错误严重程度**
1.Major：主要的，较大的缺陷
2.Minor：次要的，小的缺陷
### 缺陷优先级（Priority）
1.Resolve Immediately：缺陷必须被立即解决。
2.Normal Queue：缺陷需要正常排队等待修复或列入软件发布清单。
3.Not Urgent：缺陷可以在方便时被纠正。
### 缺陷状态（Status）
1.Submitted: 已提交的缺陷
2.Open :确认“提交的缺陷”，等待处理
3.Rejected: 拒绝“提交的缺陷”，不需要修复或不是缺陷
4.Resolved :缺陷被修复
5.Closed :确认被修复的缺陷，将其关闭
### 缺陷起源（Origin）
1.Requirement：在需求阶段发现的缺陷
2.Architecture：在构架阶段发现的缺陷
3.Design：在设计阶段发现的缺陷
4.Code：在编码阶段发现的缺陷
5.Test：在测试阶段发现的缺陷
### 缺陷来源（Source）
1.Requirement： 由于需求的问题引起的缺陷
2.Architecture： 由于构架的问题引起的缺陷
3.Design： 由于设计的问题引起的缺陷
4.Code： 由于编码的问题引起的缺陷
5.Test： 由于测试的问题引起的缺陷
6.Integration： 由于集成的问题引起的缺陷
## 级别
一旦发现软件缺陷，就要设法找到引起这个缺陷的原因，分析对产品质量的影响，然后确定软件缺陷的严重性和处理这个缺陷的优先级。各种缺陷所造成的后果是不一样的，有的仅仅是不方便，有的可能是灾难性的。一般问题越严重，其处理优先级就越高，可以概括为以下四种级别：
（1）微小的（Minor）。一些小问题如有个别错别字、文字排版不整齐等，对功能几乎没有影响，软件产品仍可使用。
（2）一般的（Major）。不太严重的错误，如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。
（3）严重的（Critical）。严重错误，指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明。
（4）致命的（Fatal）。致命的错误，造成系统崩溃、死机，或造成数据丢失、主要功能完全丧失等。
除了严重性之外，还存在反映软件缺陷处于一种什么样的状态，以便于及时跟踪和管理，下面是不同的缺陷状态。
·激活状态（Open）：问题没有解决，测试人员新报告的缺陷或者验证后缺陷仍旧存在。
·已修正状态（Fixed）：开发人员针对缺陷，修正软件后已解决问题或通过单元测试。
·关闭状态（Close）：测试人员经过验证后，确认缺陷不存在之后的状态。
以上是三种基本的状态，还有一些是需要相应的状态描述，如“保留”，“不一致”状态等。
## 产生原因
在软件开发的过程中，软件缺陷的产生是不可避免的。那么造成软件缺陷的主要原因有哪些？从软件本身、团队工作和技术问题等角度分析，就可以了解造成软件缺陷的主要因素。
软件缺陷的产生主要是由软件产品的特点和开发过程决定的。
### 软件本身
1.需求不清晰，导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷。
2.系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。
3.对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。
4.对一些实时应用，要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时间上不协调，不一致性带来的问题。
5.没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统安全性、可靠性的隐患。
6.系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题；在系统实际应用中，数据量很大。从而会引起强度或负载问题。
7.由于通信端口多、存取和加密手段的矛盾性等，会造成系统的安全性或适用性等问题。
8.新技术的采用，可能涉及技术或系统兼容的问题，事先没有考虑到。
### 团队工作
1.系统需求分析时对客户的需求理解不清楚，或者和用户的沟通存在一些困难。
2.不同阶段的开发人员相互理解不一致。例如，软件设计人员对需求分析的理解有偏差，编程人员对系统设计规格说明书某些内容重视不够，或存在误解。
3.对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。
4.项目组成员技术水平参差不齐，新员工较多，或培训不够等原因也容易引起问题。
### 技术问题
1.算法错误：在给定条件下没能给出正确或准确的结果。
2.语法错误：对于编译性语言程序，编译器可以发现这类问题；但对于解释性语言程序，只能在测试运行时发现。
3.计算和精度问题：计算的结果没有满足所需要的精度。
4.系统结构不合理、算法选择不科学，造成系统性能低下
5.接口参数传递不匹配，导致模块集成出现问题。
### 项目管理的问题
1.缺乏质量文化，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容易挤掉需求分析、评审、测试、等时间，遗留的缺陷会比较多。
2.系统分析时对客户的需求不是十分清楚，或者和用户的沟通存在一些困难。
3.开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进行，工作不够充分，结果也就不完整、不准确，错误较多；周期短，还给各类开发人员造成太大的压力，引起一些人为的错误。
4.开发流程不够完善，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题。
5.文档不完善，风险估计不足等。
## 构成
从软件测试观点出发，软件缺陷有以下五大类：
### 功能缺陷
（1）规格说明书缺陷：规格说明书可能不完全，有二义性或自身矛盾。另外，在设计过程中可能修改功能，如果不能紧跟这种变化并及时修改规格说明书，则产生规格说明书错误。
（2）功能缺陷：程序实现的功能与用户要求的不一致。这常常是由于规格说明书包含错误的功能、多余的功能或遗漏的功能所致。在发现和改正这些[缺陷]的过程中又可能引入新的缺陷。
（3）测试缺陷：软件测试的设计与实施发生错误。特别是系统级的功能测试，要求复杂的测试环境和数据库支持，还需要对测试进行脚本编写。因此软件测试自身也可能发生错误。另外，如果测试人员对系统缺乏了解，或对规格说明书做了错误的解释，也会发生许多错误。
（4）测试标准引起的缺陷：对软件测试的标准要选择适当，若测试标准太复杂，则导致测试过程出错的可能就大。
### 系统缺陷
◆外部接口缺陷：外部接口是指如终端、打印机、通信线路等系统与外部环境通讯的手段。所有外部接口之间、人与机器之间的通讯都使用形式的或非形式的专门协议。如果协议有错，或太复杂，难以理解，致使在使用中出错。此外，还包括对输入/输出格式错误理解，对输入数据不合理的容错等。
◆内部接口缺陷：内部接口是指程序内部子系统或模块之间的联系。它所发生的缺陷与外部接口相同，只是与程序内实现的细节有关，如设计协议错、输入/输出格式错、数据保护不可靠、子程序访问错等。
◆硬件结构缺陷：与硬件结构有关的软件缺陷在于不能正确的理解硬件如何工作。如忽视或错误地理解分页机构、地址生成、通道容量、I/O指令、中断处理、设备初始化和启动等而导致的出错。
◆操作系统缺陷：与操作系统有关的软件缺陷在于不了解操作系统的工作机制而导致出错。当然，操作系统本身也有缺陷，但是一般用户很难发现这种缺陷。
◆软件结构缺陷：由于软件结构不合理而产生的缺陷。这种缺陷通常与系统的负载有关，而且往往在系统满载时才出现。如错误地设置局部参数或全局参数；错误地假定寄存器与存储器单元初始化了；错误地假定被调用子程序常驻内存或非常驻内存等，都将导致软件出错。
◆控制与顺序缺陷：如忽视了时间因素而破坏了事件的顺序；等待一个不可能发生的条件；漏掉先决条件；规定错误的优先级或程序状态；漏掉处理步骤；存在不正确的处理步骤或多余的处理步骤等。
◆资源管理缺陷：由于不正确地使用资源而产生的缺陷。如使用未经获准的资源；使用后未释放资源；资源死锁；把资源链接到错误的队列中等
### 加工缺陷
◇算法与操作缺陷：是指在算术运算、函数求值和一般操作过程中发生的缺陷。如数据类型转换错；除法溢出；不正确地使用关系运算符；不正确地使用整数与浮点数做比较等。
◇初始化缺陷：如忘记初始化工作区，忘记初始化寄存器和数据区；错误地对循环控制变量赋初值；用不正确的格式、数据或类类型进行初始化等。
◇控制和次序缺陷：与系统级同名缺陷相比，它是局部缺陷。如遗漏路径；不可达到的代码；不符合语法的循环嵌套；循环返回和终止的条件不正确；漏掉处理步骤或处理步骤有错等。
◇静态逻辑缺陷：如不正确地使用switch语句；在表达式中使用不正确的否定（例如用“>”代替“<”的否定）；对情况不适当地分解与组合；混淆“或”与“异或”等。
### 数据缺陷
△动态数据缺陷：动态数据是在程序执行过程中暂时存在的数据，它的生存期非常短。各种不同类型的动态数据在执行期间将共享一个共同的存储区域，若程序启动时对这个区域未初始化，救护导致数据出错。
△静态数据缺陷：静态数据在内容和格式上都是固定的。它们直接或间接的出现在程序或数据库中，有编译程序或其他专门对他们做预处理，但预处理也会出错。
△数据内容、结构和属性缺陷：数据内容是指存储于存储单元或数据结构中的位串、字符串或数字。数据内容缺陷就是由于内容被破坏或被错误地解释而造成的缺陷。数据结构是指数据元素的大小和组织形式。在同一存储区域中可以定义不同的数据结构。数据结构缺陷包括结构说明错误及数据结构误用的错误。数据属性是指数据内容的含义或语义。数据属性缺陷包括对数据属性不正确地解释，如错把整数当实数，允许不同类型数据混合运算而导致的错误等。
