软件缺陷（Defect），常常又被叫做Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
软件缺陷的类别
缺陷的表现形式不仅体现在功能的失效方面，还体现在其他方面。主要类型有：软件没有实现产品规格说明所要求的功能模块；软件中出现了产品规格说明指明不应该出现的错误；软件实现了产品规格说明没有提到的功能模块；软件没有实现虽然产品规格说明没有明确提及但应该实现的目标；软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好。
以计算器开发为例。计算器的产品规格说明
定应能准确无误地进行加、减、乘、除运算。如果按下加法键，没什么反应，就是第一种类型的缺陷；若计算结果出错，也是第一种类型的缺陷。
产品规格说明书还可能规定计算器不会死机，或者停止反应。如果随意敲键盘导致计算器停止接受输入，这就是第二种类型的缺陷。
如果使用计算器进行测试，发现除了加、减、乘、除之外还可以求平方根，但是产品规格说明没有提及这一功能模块。这是第三种类型的缺陷——软件实现了产品规格说明书中未提及到的功能模块。
在测试计算器时若发现电池没电会导致计算不正确，而产品说明书是假定电池一直都有电的，从而发现第四种类型的错误。
软件测试员如果发现某些地方不对，比如测试员觉得按键太小、“=”键布置的位置不好按、在亮光下看不清显示屏等，无论什么原因，都要认定为缺陷。而这正是第五种类型的缺陷。
软件缺陷(software defect)分类标准
缺陷属性
属性名称 描述 缺陷标识(Identifier) 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识 缺陷类型 (Type) 缺陷类型是根据缺陷的自然属性划分的缺陷种类。 缺陷严重程度 (Severity) 缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。 缺陷优先级(Priority) 缺陷的优先级指缺陷必须被修复的紧急程度。 缺陷状态(Status) 缺陷状态指缺陷通过一个跟踪修复过程的进展情况。 缺陷起源(Origin) 缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。 缺陷来源(Source) 缺陷来源指引起缺陷的起因。 缺陷根源(Root Cause) 缺陷根源指发生错误的根本因素。
缺陷类型（Type）
缺陷类型编号 缺陷类型 描述 10 F- Function 影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷。 20 A- Assignment 需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。 30 I- Interface 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。 40 C- Checking 提示的错误信息，不适当的数据验证等缺陷。 50 B Build/package/merge 由于配置库、变更管理或版本控制引起的错误。 60 D- Documentation 影响发布和维护，包括注释。 70 G- Algorithm 算法错误。 80 U-User Interface 人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷。 90 P-Performance 不满足系统可测量的属性值，如：执行时间，事务处理速率等。 100 N-Norms 不符合各种标准的要求，如编码标准、设计符号等。
缺陷严重程度（Severity）
1.3.1 软件测试错误严重程度
# 缺陷严重等级 描述 1 Critical 不能执行正常工作功能或重要功能。或者危及人身安全。 2 Major 严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法） 3 Minor 严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法） 4 Cosmetic 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。 5 Other 其它错误。
1.3.2 同行评审错误严重程度
# 缺陷严重等级 描述 Major 主要的，较大的缺陷 Minor 次要的，小的缺陷
缺陷优先级（Priority）
# 缺陷优先级 描述 1 Resolve Immediately 缺陷必须被立即解决。 2 Normal Queue 缺陷需要正常排队等待修复或列入软件发布清单。 3 Not Urgent 缺陷可以在方便时被纠正。
缺陷状态（Status）
缺陷状态 描述 Submitted 已提交的缺陷 Open 确认“提交的缺陷”，等待处理 Rejected 拒绝“提交的缺陷”，不需要修复或不是缺陷 Resolved 缺陷被修复 Closed 确认被修复的缺陷，将其关闭
缺陷起源（Origin）
缺陷起源 描述 Requirement 在需求阶段发现的缺陷 Architecture 在构架阶段发现的缺陷 Design 在设计阶段发现的缺陷 Code 在编码阶段发现的缺陷 Test 在测试阶段发现的缺陷
缺陷来源（Source）
缺陷来源 描述 Requirement 由于需求的问题引起的缺陷 Architecture 由于构架的问题引起的缺陷 Design 由于设计的问题引起的缺陷 Code 由于编码的问题引起的缺陷 Test 由于测试的问题引起的缺陷 Integration 由于集成的问题引起的缺陷
软件缺陷的级别
一旦发现软件缺陷，就要设法找到引起这个缺陷的原因，分析对产品质量的影响，然后确定软件缺陷的严重性和处理这个缺陷的优先级。各种缺陷所造成的后果是不一样的，有的仅仅是不方便，有的可能是灾难性的。一般问题越严重，其处理优先级就越高，可以概括为以下四种级别：
（1）微小的（Minor）。一些小问题如有个别错别字、文字排版不整齐等，对功能几乎没有影响，软件产品仍可使用。
（2）一般的（Major）。不太严重的错误，如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。
（3）严重的（Critical）。严重错误，指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明。
（4）致命的（Fatal）。致命的错误，造成系统崩溃、死机，或造成数据丢失、主要功能完全丧失等。
除了严重性之外，还存在反映软件缺陷处于一种什么样的状态，以便于及时跟踪和管理，下面是不同的缺陷状态。
·激活状态（Open）：问题没有解决，测试人员新报告的缺陷或者验证后缺陷仍旧存在。
·已修正状态（Fixed）：开发人员针对缺陷，修正软件后已解决问题或通过单元测试。
·关闭状态（Close）：测试人员经过验证后，确认缺陷不存在之后的状态。
以上是三种基本的状态，还有一些是需要相应的状态描述，如“保留”，“不一致”状态等。
软件缺陷产生的原因
在软件开发的过程中，软件缺陷的产生是不可避免的。那么造成软件缺陷的主要原因有哪些？从软件本身、团队工作和技术问题等角度分析，就可以了解造成软件缺陷的主要因素。
软件缺陷的产生主要是由软件产品的特点和开发过程决定的。
软件本身
①需求不清晰，导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷。
②系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。
③对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。
④对一些实时应用，要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时间上不协调，不一致性带来的问题。
⑤没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统安全性、可靠性的隐患。
⑥系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题；在系统实际应用中，数据量很大。从而会引起强度或负载问题。
⑦由于通信端口多、存取和加密手段的矛盾性等，会造成系统的安全性或适用性等问题。
⑧新技术的采用，可能涉及技术或系统兼容的问题，事先没有考虑到。
团队工作
☆系统需求分析时对客户的需求理解不清楚，或者和用户的沟通存在一些困难。
☆不同阶段的开发人员相互理解不一致。例如，软件设计人员对需求分析的理解有偏差，编程人员对系统设计规格说明书某些内容重视不够，或存在误解。
☆对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。
☆项目组成员技术水平参差不齐，新员工较多，或培训不够等原因也容易引起问题。
技术问题
○算法错误：在给定条件下没能给出正确或准确的结果。
○语法错误：对于编译性语言程序，编译器可以发现这类问题；但对于解释性语言程序，只能在测试运行时发现。
○计算和精度问题：计算的结果没有满足所需要的精度。
○系统结构不合理、算法选择不科学，造成系统性能低下。
○接口参数传递不匹配，导致模块集成出现问题。
项目管理的问题
· 缺乏质量文化，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容易挤掉需求分析、评审、测试、等时间，遗留的缺陷会比较多。
· 系统分析时对客户的需求不是十分清楚，或者和用户的沟通存在一些困难。
· 开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进行，工作不够充分，结果也就不完整、不准确，错误较多；周期短，还给各类开发人员造成太大的压力，引起一些人为的错误。
· 开发流程不够完善，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题。
· 文档不完善，风险估计不足等。
软件缺陷的构成
从软件测试观点出发，软件缺陷有以下五大类：
功能缺陷
（1）规格说明书缺陷：规格说明书可能不完全，有二义性或自身矛盾。另外，在设计过程中可能修改功能，如果不能紧跟这种变化并及时修改规格说明书，则产生规格说明书错误。
功 规格说明书 404
能 功能 147
缺 测试 7
陷 总计 558 27%
（2）功能缺陷：程序实现的功能与用户要求的不一致。
软件缺陷
这常常是由于规格说明书包含错误的功能、多余的功能或遗漏的功能所致。在发现和改正这些缺陷的过程中又可能引入新的缺陷。
（3）测试缺陷：软件测试的设计与实施发生错误。特别是系统级的功能测试，要求复杂的测试环境和数据库支持，还需要对测试进行脚本编写。因此软件测试自身也可能发生错误。另外，如果测试人员对系统缺乏了解，或对规格说明书做了错误的解释，也会发生许多错误。
（4）测试标准引起的缺陷：对软件测试的标准要选择适当，若测试标准太复杂，则导致测试过程出错的可能就大。
系统缺陷
◆外部接口缺陷：外部接口是指如终端、打印机、通信线路等系统与外部环境通讯的手段。所有外部接口之间、人与机器之间的通讯都使用形式的或非形式的专门协议。如果协议有错，或太复杂，难以理解，致使在使用中出错。此外，还包括对输入/输出格式错误理解，对输入数据不合理的容错等。
内部接口 29 系 硬件 63
统 操作系统 2
缺 软件结构 193
陷 控制与顺序 43
资源 8
总计 338 16% ◆内部接口缺陷：内部接口是指程序内部子系统或模块之间的联系。它所发生的缺陷与外部接口相同，只是与程序内实现的细节有关，如设计协议错、输入/输出格式错、数据保护不可靠、子程序访问错等。
◆硬件结构缺陷：与硬件结构有关的软件缺陷在于不能正确的理解硬件如何工作。如忽视或错误地理解分页机构、地址生成、通道容量、I/O指令、中断处理、设备初始化和启动等而导致的出错。
◆操作系统缺陷：与操作系统有关的软件缺陷在于不了解操作系统的工作机制而导致出错。当然，操作系统本身也有缺陷，但是一般用户很难发现这种缺陷。
◆软件结构缺陷：由于软件结构不合理而产生的缺陷。这种缺陷通常与系统的负载有关，而且往往在系统满载时才出现。如错误地设置局部参数或全局参数；错误地假定寄存器与存储器单元初始化了；错误地假定被调用子程序常驻内存或非常驻内存等，都将导致软件出错。
◆控制与顺序缺陷：如忽视了时间因素而破坏了事件的顺序；等待一个不可能发生的条件；漏掉先决条件；规定错误的优先级或程序状态；漏掉处理步骤；存在不正确的处理步骤或多余的处理步骤等。
◆资源管理缺陷：由于不正确地使用资源而产生的缺陷。如使用未经获准的资源；使用后未释放资源；资源死锁；把资源链接到错误的队列中等。
加工缺陷
◇算法与操作缺陷：是指在算术运算、函数求值和一般操作过程中发生的缺陷。如数据类型转换错；除法溢出；不正确地使用关系运算符；不正确地使用整数与浮点数做比较等。
算术 114 加 初始化 15
工 控制与次序 271
缺 静态逻辑 13
陷 其他 120
总计 533 26% ◇初始化缺陷：如忘记初始化工作区，忘记初始化寄存器和数据区；错误地对循环控制变量赋初值；用不正确的格式、数据或类类型进行初始化等。
◇控制和次序缺陷：与系统级同名缺陷相比，它是局部缺陷。如遗漏路径；不可达到的代码；不符合语法的循环嵌套；循环返回和终止的条件不正确；漏掉处理步骤或处理步骤有错等。
◇静态逻辑缺陷：如不正确地使用switch语句；在表达式中使用不正确的否定（例如用“>”代替“<”的否定）；对情况不适当地分解与组合；混淆“或”与“异或”等。
数据缺陷
△动态数据缺陷：动态数据是在程序执行过程中暂时存在的数据，它的生存期非常短。各种不同类型的动态数据在执行期间将共享一个共同的存储区域，若程序启动时对这个区域未初始化，救护导致数据出错。
类型 36 数 结构 34
据 初始值 51
错 其他 120
误 总计 241 12%
△静态数据缺陷：静态数据在内容和格式上都是固定的。它们直接或间接的出现在程序或数据库中，有编译程序或其他专门对他们做预处理，但预处理也会出错。
△数据内容、结构和属性缺陷：数据内容是指存储于存储单元或数据结构中的位串、字符串或数字。数据内容缺陷就是由于内容被破坏或被错误地解释而造成的缺陷。数据结构是指数据元素的大小和组织形式。在同一存储区域中可以定义不同的数据结构。数据结构缺陷包括结构说明错误及数据结构误用的错误。数据属性是指数据内容的含义或语义。数据属性缺陷包括对数据属性不正确地解释，如错把整数当实数，允许不同类型数据混合运算而导致的错误等。
代码缺陷
包括数据说明错、数据使用错、计算错、比较错、控制流错、界面错、输入\输出错，及其他的错误。
规格说明书是软件缺陷出现最多的地方，其原因是：
程序编写错误 78 4%
文档和其他错误 322 16%
◆用户一般是非软件开发专业人员，软件开发人员和用户的沟通存在较大困难，对要开发的产品功能理解不一致。
◆由于在开发初期，软件产品还没有设计和编程，完全靠想象去描述系统的实现结果，所以有些需求特性不够完整、清晰。
◆用户的需求总是不断变化，这些变化如果没有在产品规格说明书中得到正确的描述，容易引起前后文、上下文的矛盾。
◆对规格说明书不够重视，在规格说明书的设计和写作上投入的人力、时间不足。
◆没有在整个开发队伍中进行充分沟通，有时只有设计师或项目经理得到比较多的信息。
排在产品规格说明书之后的是设计，编程排在第三位。许多人印象中，软件测试主要是找程序代码中的错误，这是一个认识的误区。
修复软件缺陷的代价
在讨论软件测试原则时，一开始就强调测试人员要在软件开发的早期，如需求分析阶段就应介入，问题发现的越早越好。发现缺陷后，要尽快修复缺陷。其原因在于错误并不只是在编程阶段产生，需求和设计阶段同样会产生错误。也许一开始，只是一个很小范围内的错误，但随着产品开发工作的进行，小错误会扩散成大错误，为了修改后期的错误所做的工作要大得多，即越到后来往前返工也越远。如果错误不能及早发现，那只可能造成越来越严重的后果。缺陷发现或解决的越迟，成本就越高。
平均而言，如果在需求阶段修正一个错误的代价是1，那么，在设计阶段就是它的3～6倍，在编程阶段是它的10倍，在内部测试阶段是它的20～40倍，在外部测试阶段是它的30～70倍，而到了产品发布出去时，这个数字就是40～1000倍，修正错误的代价不是随时间线性增长，而几乎是呈指数增长的。
软件未达到产品说明书表明的功能。
软件出现了产品说明书指名不会出现的错误。
软件功能超出产品说明书指名范围。
软件未达到产品说明书虽未指出但应达到的目标。
软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
一般我们都认为测出一个问题就是一个bug，其实这是不对的，假设测试10个问题就10个bug，而修改一出就全解决了，程序员肯定认为冤枉自己。
所有软件是文档，代码等组成的，最初的错误是来自于这些软件错误(software error)，如代码中加法写成减法。软件错误导致软件缺陷(software defect)，如设计缺陷，代码缺陷等，可用静态测试，如走查，静态检查，测试床（军事软件用的技术）等，软件的缺陷导致一个或多个软件故障 (software fault)，故障有内部故障，外部故障，也就是我们所说的bug，软件故障导致了软件在功能操作等方面的失效(software failure)。
我们平时测的bug实际上是软件故障于失效的体现。一旦软件错误得到修改，相应的故障与失效也就解除了。这样分有助于我们定位问题，找到问题。
软件缺陷的严重性和优先级
严重性和优先级是表征软件测试缺陷的两个重要因素，它影响软件缺陷的统计结果和修正缺陷的优先顺序，特别在软件测试的后期，将影响软件是否能够按期发布与否。
对于软件测试初学者而言，或者没有软件开发经验的测试工程师，对于这两个概念的理解，对于它们的作用和处理方式往往理解的不彻底，实际测试工作中不能正确表示缺陷的严重性和优先级。这将影响软件缺陷报告的质量，不利于尽早处理严重的软件缺陷，可能影响软件缺陷的处理时机。
什么是缺陷的严重性和优先级
严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。
在软件测试中，软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。
优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。
确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。
缺陷的严重性和优先级的关系
缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。
一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。
但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。
修正软件缺陷不是一件纯技术问题，有时需要综合考虑市场发布和质量风险等问题。例如，如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上解决。另外，如果修正一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多潜在的缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。
另一方面，如果软件缺陷的严重性很低，例如，界面单词拼写错误，但是如果是软件名称或公司名称的拼写错误，则必须尽快修正，因为这关系到软件和公司的市场形象。
处理缺陷的严重性和优先级的常见错误
正确处理缺陷的严重性和优先级不是件非常容易的事情，对于经验不很丰富??情形：
第一，将比较轻微的缺陷报告成较高级别的缺陷和高优先级，夸大缺陷的严重程度，经常给人“狼来了”的错觉，将影响软件质量的正确评估，也耗费开发人员辨别和处理缺陷的时间。
第二，将很严重的缺陷报告成轻微缺陷和低优先级，这样可能掩盖了很多严重的缺陷。如果在项目发布前，发现还有很多由于不正确分配优先级造成的严重缺陷，将需要投入很多人力和时间进行修正，影响软件的正常发布。或者这些严重的缺陷成了“漏网之鱼”，随软件一起发布出去，影响软件的质量和用户的使用信心。
因此，正确处理和区分缺陷的严重性和优先级，是软件测试人员和开发人员，以及全体项目组人员的一件大事。处理严重性和优先级，既是一种经验技术，也是保证软件质量的重要环节，应该引起足够的重视。
如何表示缺陷的严重性和优先级
缺陷的严重性和优先级通常按照级别划分，各个公司和不同项目的具体表示方式有所不同。
为了尽量准确的表示缺陷信息，通常将缺陷的严重性和优先级分成4级。如果分级超过4级，则造成分类和判断尺度的复杂程度，而少于4级，精确性有时不能保证。
具体的表示方法机可以使用数字表示，也可以使用文字表示，还可以数字和文字综合表示。使用数字表示通常按照从高到底或从低到高的顺序，需要软件测试前达成一致。例如，使用数字1，2，3，4分别表示轻微、一般、较严重和非常严重的严重性。对于优先级而言，1，2，3，4可以分标表示低优先级、一般、较高优先级和最高优先级。
如何确定缺陷的严重性和优先级
通常由软件测试人员确定缺陷的严重性，由软件开发人员确定优先级较为适当。但是，实际测试中，通常都是由软件测试人员在缺陷报告中同时确定严重性和优先级。
确定缺陷的严重性和优先级要全面了解和深刻体会缺陷的特征，从用户和开发人员以及市场的因素综合考虑。通常功能性的缺陷较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般较低，优先级也较低。
对于缺陷的严重性，如果分为4级，则可以参考下面的方法确定：
1 – 非常严重的缺陷，例如，软件的意外退出甚至操作系统崩溃，造成数据丢失。 2 – 较严重的缺陷，例如，软件的某个菜单不起作用或者产生错误的结果； 3 - 软件一般缺陷，例如，本地化软件的某些字符没有翻译或者翻译不准确； 4 - 软件界面的细微缺陷，例如，某个控件没有对齐，某个标点符号丢失等；
对于缺陷的优先性，如果分为4级，则可以参考下面的方法确定：
1 –最高优先级，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷。 2 – 较高优先级，例如，影响软件功能和性能的一般缺陷； 3 -一般优先级，例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷； 4 – 低优先级，例如，对软件的质量影响非常轻微或出现几率很低的缺陷；
其他注意事项
比较规范的软件测试，使用软件缺陷管理数据库进行缺陷报告和处理，需要在测试项目开始前对全体测试人员和开发人员进行培训，对缺陷严重性和优先级的表示和划分方法统一规定和遵守。
在测试项目进行过程中和项目接收后，充分利用统计功能统计缺陷的严重性，确定软件模块的开发质量，评估软件项目实施进度。统计优先级的分布情况，控制开发进度，使开发按照项目尽快进行，有效处理缺陷，降低风险和成本。
为了保证报告缺陷的严重性和优先级的一致性，质量保证人员需要经常检查测试和开发人员对于这两个指标的分配和处理情况，发现问题，及时反馈给项目负责人，及时解决。
对于测试人员而言，通常经验丰富的人员可以正确的表示缺陷的严重性和优先级，为缺陷的及时处理提供准确的信息。对于开发人员来说，开发经验丰富的人员严重缺陷的错误较少，但是不要将缺陷的严重性作为衡量其开发水平高低的主要判断指标，因为软件的模块的开发难度不同，各个模块的质量要求也有所差异。
软件缺陷(software defect)管理指南
1、如何收集缺陷
缺陷既指程序中存在的错误，例如语法错误、拼写错误或者是一个正确的程序语句，缺陷也指可能出现在设计中，甚至在需求、规格说明或其他的文档中的种种错误。为了对缺陷进行管理，首先应对缺陷进行分类，通过对缺陷进行分类，可以迅速找出哪一类缺陷的问题最大，然后集中精力预防和排除这一类缺陷。而这正是缺陷管理的关键，一旦这几类缺陷得到控制，再进一步找到新的容易引起问题的几类缺陷上。
1．1 缺陷类型
缺陷类 型编号 缺陷类型 描述 10 F-功能 如逻辑,指针,循环,递归,功能等缺陷 20 G-语法 拼写、标点符号、打字 30 A-赋值 如声明、重复命名，作用域 40 I-接口 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷 50 B-联编打包 由于配置库、变更管理或版本控制引起的错误 60 D-文档 需求、设计类文档 70 U-用户接口 人机交互特性：屏幕格式，确认用户输入，功能有效性 80 P-性能 不满足系统可测量的属性值，如：执行时间，事务处理速率等 90 N-标准 不符合各种标准的要求，如编码标准、设计符号等 100 E-环境 设计、编译、其他支持系统问题
1．2 了解缺陷
缺陷管理的第一步是了解缺陷，为此，必须首先收集缺陷数据，然后才能了解这些缺陷，并且找出如何预防它们，同时也能领会到如何更好地发现，修复甚至预防仍在引入的缺陷。可以按照以下步骤收集关于缺陷的数据：
◆ 为测试和同行评审中发现的每一个缺陷做一个记录
◆ 对每个缺陷要记录足够详细的信息，以便以后能更好地了解这个缺陷
◆ 分析这些数据以找出主要哪些缺陷类型引起大部分的问题
◆ 设计出发现和修复这些缺陷的方法（缺陷排除）
通常为了收集缺陷数据，可以采用缺陷记录日志来登记所发现的每一个缺陷
日期 编号 状态 类型 缺陷来源 排除阶段 修改时间 修复缺陷 描述： 描述： 描述：
对于缺陷记录日志中的描述应该足够清楚，以便今后可以看出该缺陷的起因。修复缺陷一栏说明此缺陷是由于修复其他缺陷而引入的。引入阶级表示该缺陷的来源，缺陷的来源可以分为以下几类：
缺陷来源 描述 Requirement 由于需求的问题引起的缺陷 Architecture 由于构架的问题引起的缺陷 Design 由于设计的问题引起的缺陷 Code 由于编码的问题引起的缺陷 Test 由于测试的问题引起的缺陷 Integration 由于集成的问题引起的缺陷
排除阶级表示发现和修复这个缺陷的阶级，通常分为如下：
排除阶段 描述 Requirement 在需求阶段发现的缺陷 Architecture 在构架阶段发现的缺陷 Design 在设计阶段发现的缺陷 Code 在编码阶段发现的缺陷 Test 在测试阶段bsp;
2、如何分析和统计缺陷
为了更好地分析缺陷，需要对缺陷在严重程度、优先级以及状态上加以区分。
2．1 缺陷严重程度
# 缺陷严重等级 描述 1 严重缺陷（Critical） 不能执行正常工作功能或重要功能。或者危及人身安全 2 较大缺陷（Major） 严重地影响系统要求或基本功能的实现，且没有办法更正。 （重新安装或重新启动该软件不属于更正办法） 3 较小缺陷（Minor） 严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法） 4 轻微缺陷（Cosmetic） 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。 5 其他缺陷（Other） 其它错误
2．2 解决优先级（Priority）
# 解决优先级 描述 1 立即解决 （Resolve Immediately） 缺陷必须被立即解决。 2 正常排队 （Normal Queue） 缺陷需要正常排队等待修复或列入软件发布清单。 3 不紧急 （Not Urgent） 缺陷可以在方便时被纠正。
, 让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序, , , , 员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求Bug，处理的流程如图。 这样处理有以下好处，首先需求Bug再不象以前，没有人进行确认，需求的处理人员本来就是需求人员，由他们确认与跟踪是最好不过的，因为他们对需求有绝对的权威。同时测试人员其实就是最早的用户，他们的需求就是用户的需求，这种方法加强了需求人员与测试人员的沟通，使需求得到有效的补充，从而让产品更加完善。还有测试人员从本质上来说与程序员还是对立的，这里如果为了这样一个不是软件本身问题的问题形成与开发人员的对立，则会出现赢得战役而丢失整个战争的情况，测试人员协调好与开发人员的关系，让他们更有效的对软件本身的缺陷形成有效的关注是最好的。还有最为关键的一点，测试人员的激情是最重要的，如果他们的想法没有得到体现，这时会渐渐的失去对测试的兴趣，从而软件的质量则会无法得到保证，通过这种方法可以让他们看到自己的建议可以通过对需求人员的反映得到实现，让他们时时觉得自己的想法是可以通过这种方法来有效的推行，这样工作的积极性才会有保障。
不过从实施的角度来说，还是有一定的困难的，首先要让大家改变以前那种凡是Bug就是由开发人员负责的观念，其次需求人员的工作量要加大，不过广泛的了解需求是他们的本份工作，想来不会很困难，还有必需要有有效的Bug管理工具，比如BugManage等等，不要出现那种对需求人员说了，可过两天就忘的情况出现，这时需求Bug的生命周期会出现跨越两个软件开发周期??要延长对这些需求Bug的管理，不过我想这些需求是他们提出的，会有兴趣对这些Bug进行管理的。
