类别
缺陷的表现形式不仅体现在功能的失效方面，还体现在其他方面。主要类型有：软件没有实现产品规格说明所要求的功能模块；软件中出现了产品规格说明指明不应该出现的错误；软件实现了产品规格说明没有提到的功能模块；软件没有实现虽然产品规格说明没有明确提及但应该实现的目标；软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好。
以计算器开发为例。计算器的产品规格说明
定应能准确无误地进行加、减、乘、除运算。如果按下加法键，没什么反应，就是第一种类型的缺陷；若计算结果出错，也是第一种类型的缺陷。
产品规格说明书还可能规定计算器不会死机，或者停止反应。如果随意敲键盘导致计算器停止接受输入，这就是第二种类型的缺陷。
如果使用计算器进行测试，发现除了加、减、乘、除之外还可以求平方根，但是产品规格说明没有提及这一功能模块。这是第三种类型的缺陷——软件实现了产品规格说明书中未提及到的功能模块。
在测试计算器时若发现电池没电会导致计算不正确，而产品说明书是假定电池一直都有电的，从而发现第四种类型的错误。
软件测试员如果发现某些地方不对，比如测试员觉得按键太小、“=”键布置的位置不好按、在亮光下看不清显示屏等，无论什么原因，都要认定为缺陷。而这正是第五种类型的缺陷。
根据以上五种缺陷类型，在软件测试中可以区分不同类型的问题。
分类标准
缺陷属性
1.缺陷标识(Identifier)：缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识。
2.缺陷类型(Type)：缺陷类型是根据缺陷的自然属性划分的缺陷种类。
3.缺陷严重程度(Severity)：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
4.缺陷优先级(Priority)：缺陷的优先级指缺陷必须被修复的紧急程度。
5.缺陷状态(Status)：缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
6.缺陷起源(Origin)：缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。
7.缺陷来源(Source)：缺陷来源指引起缺陷的起因。
8.缺陷根源(Root Cause)：缺陷根源指发生错误的根本因素。
缺陷类型（Type）
F-Function：影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷。
A-Assignment：需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。
I-Interface：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
C-Checking：提示的错误信息，不适当的数据验证等缺陷。
BBuild/package/merge：由于配置库、变更管理或版本控制引起的错误。
D-Documentation：影响发布和维护，包括注释。
G-Algorithm：算法错误。
U-UserInterface：人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷。
P-Performance：不满足系统可测量的属性值，如：执行时间，事务处理速率等。
N-Norms：不符合各种标准的要求，如编码标准、设计符号等。
缺陷严重程度（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，那么，在设计阶段就是它的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可以分标表示低优先级、一般、较高优先级和最高优先级。
如何确定缺陷的严重性和优先级
通常由软件测试人员确定缺陷的严重性，由软件开发人员确定优先级较为适当。但是，实际测试中，通常都是由软件测试人员在缺陷报告中同时确定严重性和优先级。
确定缺陷的严重性和优先级要全面了解和深刻体会缺陷的特征，从用户和开发人员以及市场的因素综合考虑。通常功能性的缺陷较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般较低，优先级也较低。
其他注意事项
比较规范的软件测试，使用软件缺陷管理数据库进行缺陷报告和处理，需要在测试项目开始前对全体测试人员和开发人员进行培训，对缺陷严重性和优先级的表示和划分方法统一规定和遵守。
在测试项目进行过程中和项目接收后，充分利用统计功能统计缺陷的严重性，确定软件模块的开发质量，评估软件项目实施进度。统计优先级的分布情况，控制开发进度，使开发按照项目尽快进行，有效处理缺陷，降低风险和成本。
为了保证报告缺陷的严重性和优先级的一致性，质量保证人员需要经常检查测试和开发人员对于这两个指标的分配和处理情况，发现问题，及时反馈给项目负责人，及时解决。
对于测试人员而言，通常经验丰富的人员可以正确的表示缺陷的严重性和优先级，为缺陷的及时处理提供准确的信息。对于开发人员来说，开发经验丰富的人员严重缺陷的错误较少，但是不要将缺陷的严重性作为衡量其开发水平高低的主要判断指标，因为软件的模块的开发难度不同，各个模块的质量要求也有所差异。
管理指南
收集缺陷
缺陷既指程序中存在的错误，例如语法错误、拼写错误或者是一个正确的程序语句，缺陷也指可能出现在设计中，甚至在需求、规格说明或其他的文档中的种种错误。为了对缺陷进行管理，首先应对缺陷进行分类，通过对缺陷进行分类，可以迅速找出哪一类缺陷的问题最大，然后集中精力预防和排除这一类缺陷。而这正是缺陷管理的关键，一旦这几类缺陷得到控制，再进一步找到新的容易引起问题的几类缺陷上。
了解缺陷
缺陷管理的第一步是了解缺陷，为此，必须首先收集缺陷数据，然后才能了解这些缺陷，并且找出如何预防它们，同时也能领会到如何更好地发现，修复甚至预防仍在引入的缺陷。可以按照以下步骤收集关于缺陷的数据：
1.为测试和同行评审中发现的每一个缺陷做一个记录
2.对每个缺陷要记录足够详细的信息，以便以后能更好地了解这个缺陷
3.分析这些数据以找出主要哪些缺陷类型引起大部分的问题
4.设计出发现和修复这些缺陷的方法（缺陷排除）
通常为了收集缺陷数据，可以采用缺陷记录日志来登记所发现的每一个缺陷。
对于缺陷记录日志中的描述应该足够清楚，以便今后可以看出该缺陷的起因。修复缺陷一栏说明此缺陷是由于修复其他缺陷而引入的。引入阶级表示该缺陷的来源。
步骤
为了有效地再现软件缺陷，除了按照软件缺陷的有效描述规则来描述软件缺陷，还要遵循软件缺陷分离和再现的方法，虽然有时少数几个缺陷很难再现、或者根本无法再现.
1.确保所有的步骤都被记录。记录下所做的每一件事、每一个步骤、每一个停顿。无意间丢失一个步骤或者增加一个多余步骤，可能导致无法再现软件缺陷。在尝试运行测试用例时，可以利用录制工具确切地记录执行步骤。所有的目标是确保导致软件缺陷所需的全部细节是可见的。
2.特定条件和时间。软件缺陷仅在特定时刻出现吗？软件缺陷在特定条件下产生吗？产生软件缺陷是网络忙吗？在较差和较好的硬件设备上运行测试用例会有不同的结果吗？
3.压力和负荷、内存和数据溢出相关的边界条件。执行某个测试町能导致产生缺陷的数据被复盖，而只有在试图使用浚数据时才会再现。在重启计算机后软件缺陷消失，当执行其他测试之后又出现这类软件缺陷，需要注意某些软件缺陷可能是在无意中产生的。
4.考虑资源依赖性包括内存、嘲络和硬件共享的相互作用等。软件缺陷是否仅在运行其他软件并与其他硬件通信的“繁忙”系统上出现？软件缺陷可能最终证实跟硬件资源、网络资源有相互的作用，审视这些影响有利于分离和再现软件缺陷。
5.不能忽视硬件。与软件不同，硬件Hi按预定方式工作。板卡松动、内存条损坏或者cPU过热都可能导致像是软件缺陷的失败。设法在不同硬件卜再现软件缺陷。在执行配置或者兼容性测试时特别重要。判定软件缺陷是在一个系统上还是在多个系统l产生。
开发人员有时可以根据相对简单的错误信息就能找出问题所在。因为开发人员熟悉代码，因此看到症状、测试用例步骤和分离问题的过程时。可能得到查找软件缺陷的线索。一个软件缺陷的分离和再现有时需要小组的共同努力。如果软件测试人员尽最大努力分离软件缺陷，也无法表达准确的再现步骤，那么仍然需要记录和报告软件缺陷。
