软件缺陷(software defect)是对软件产品预期属性的偏离现象。它包括检测缺陷和残留缺陷。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。
一、软件缺陷(software defect)分类标准
1.1 缺陷属性
缺陷标识(Identifier)：缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识。
缺陷类型 (Type)：缺陷类型是根据缺陷的自然属性划分的缺陷种类。
缺陷严重程度 (Severity)：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
缺陷优先级(Priority)：缺陷的优先级指缺陷必须被修复的紧急程度。
缺陷状态(Status)：缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
缺陷起源(Origin)：缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。
缺陷来源(Source)：缺陷来源指引起缺陷的起因。
缺陷根源(Root Cause)：缺陷根源指发生错误的根本因素。
1.2 缺陷类型（Type）
10 F- Function 影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷。
20 A- Assignment 需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。
30 I- Interface 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
40C- Checking提示的错误信息，不适当的数据验证等缺陷。
50B Build/package/merge由于配置库、变更管理或版本控制引起的错误。
60D- Documentation影响发布和维护，包括注释。
70G- Algorithm算法错误。
80U-User Interface人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷。
90P-Performance不满足系统可测量的属性值，如：执行时间，事务处理速率等。
100N-Norms不符合各种标准的要求，如编码标准、设计符号等。
1.3 缺陷严重程度（Severity）
1.3.1 软件测试错误严重程度
1Critical不能执行正常工作功能或重要功能。或者危及人身安全。
2Major严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）
3Minor严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）
4Cosmetic使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
5Other其它错误。
1.3.2 同行评审错误严重程度
Major主要的，较大的缺陷
Minor次要的，小的缺陷
1.4 缺陷优先级（Priority）
1Resolve Immediately缺陷必须被立即解决。
2Normal Queue缺陷需要正常排队等待修复或列入软件发布清单。
3Not Urgent缺陷可以在方便时被纠正。
1.5 缺陷状态（Status）
Submitted已提交的缺陷
Open确认“提交的缺陷”，等待处理
Rejected 拒绝“提交的缺陷”，不需要修复或不是缺陷
Resolved 缺陷被修复
Closed确认被修复的缺陷，将其关闭
1.6 缺陷起源（Origin）
Requirement在需求阶段发现的缺陷
Architecture在构架阶段发现的缺陷
Design在设计阶段发现的缺陷
Code在编码阶段发现的缺陷
Test在测试阶段发现的缺陷
1.7 缺陷来源（Source）
Requirement由于需求的问题引起的缺陷
Architecture由于构架的问题引起的缺陷
Design由于设计的问题引起的缺陷
Code由于编码的问题引起的缺陷
Test由于测试的问题引起的缺陷
Integration由于集成的问题引起的缺陷
1.8 缺陷根源（Root Cause）
二、软件缺陷(software defect)的严重性和优先级
严重性和优先级是表征软件测试缺陷的两个重要因素，它影响软件缺陷的统计结果和修正缺陷的优先顺序，特别在软件测试的后期，将影响软件是否能够按期发布与否。
对于软件测试初学者而言，或者没有软件开发经验的测试工程师，对于这两个概念的理解，对于它们的作用和处理方式往往理解的不彻底，实际测试工作中不能正确表示缺陷的严重性和优先级。这将影响软件缺陷报告的质量，不利于尽早处理严重的软件缺陷，可能影响软件缺陷的处理时机。
什么是缺陷的严重性和优先级 ?
严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。
在软件测试中，软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。
优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。
确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。
缺陷的严重性和优先级的关系
缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。
一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。
但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。
修正软件缺陷不是一件纯技术问题，有时需要综合考虑市场发布和质量风险等问题。例如，如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上解决。另外，如果修正一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多潜在的缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。
另一方面，如果软件缺陷的严重性很低，例如，界面单词拼写错误，但是如果是软件名称或公司名称的拼写错误，则必须尽快修正，因为这关系到软件和公司的市场形象。
处理缺陷的严重性和优先级的常见错误
正确处理缺陷的严重性和优先级不是件非常容易的事情，对于经验不很丰富的测试和开发人员而言，经常犯的错误有以下集中情形：
第一，将比较轻微的缺陷报告成较高级别的缺陷和高优先级，夸大缺陷的严重程度，经常给人“狼来了”的错觉，将影响软件质量的正确评估，也耗费开发人员辨别和处理缺陷的时间。
第二，将很严重的缺陷报告成轻微缺陷和低优先级，这样可能掩盖了很多严重的缺陷。如果在项目发布前，发现还有很多由于不正确分配优先级造成的严重缺陷，将需要投入很多人力和时间进行修正，影响软件的正常发布。或者这些严重的缺陷成了“漏网之鱼”，随软件一起发布出去，影响软件的质量和用户的使用信心。
因此，正确处理和区分缺陷的严重性和优先级，是软件测试人员和开发人员，以及全体项目组人员的一件大事。处理严重性和优先级，既是一种经验技术，也是保证软件质量的重要环节，应该引起足够的重视。
如何确定缺陷的严重性和优先级
通常由软件测试人员确定缺陷的严重性，由软件开发人员确定优先级较为适当。但是，实际测试中，通常都是由软件测试人员在缺陷报告中同时确定严重性和优先级。
确定缺陷的严重性和优先级要全面了解和深刻体会缺陷的特征，从用户和开发人员以及市场的因素综合考虑。通常功能性的缺陷较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般较低，优先级也较低。
对于缺陷的严重性，如果分为4级，则可以参考下面的方法确定：
1 – 非常严重的缺陷，例如，软件的意外退出甚至操作系统崩溃，造成数据丢失。
2 – 较严重的缺陷，例如，软件的某个菜单不起作用或者产生错误的结果；
3 - 软件一般缺陷，例如，本地化软件的某些字符没有翻译或者翻译不准确；
4 - 软件界面的细微缺陷，例如，某个控件没有对齐，某个标点符号丢失等；
对于缺陷的优先性，如果分为4级，则可以参考下面的方法确定：
1 –最高优先级，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷。
2 – 较高优先级，例如，影响软件功能和性能的一般缺陷；
3 -一般优先级，例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷；
4 – 低优先级，例如，对软件的质量影响非常轻微或出现几率很低的缺陷；
其他注意事项
比较规范的软件测试，使用软件缺陷管理数据库进行缺陷报告和处理，需要在测试项目开始前对全体测试人员和开发人员进行培训，对缺陷严重性和优先级的表示和划分方法统一规定和遵守。
在测试项目进行过程中和项目接收后，充分利用统计功能统计缺陷的严重性，确定软件模块的开发质量，评估软件项目实施进度。统计优先级的分布情况，控制开发进度，使开发按照项目尽快进行，有效处理缺陷，降低风险和成本。
为了保证报告缺陷的严重性和优先级的一致性，质量保证人员需要经常检查测试和开发人员对于这两个指标的分配和处理情况，发现问题，及时反馈给项目负责人，及时解决。
对于测试人员而言，通常经验丰富的人员可以正确的表示缺陷的严重性和优先级，为缺陷的及时处理提供准确的信息。对于开发人员来说，开发经验丰富的人员严重缺陷的错误较少，但是不要将缺陷的严重性作为衡量其开发水平高低的主要判断指标，因为软件的模块的开发难度不同，各个模块的质量要求也有所差异。
三、软件缺陷(software defect)的分类与管理
通常大家发现软件缺陷时会对软件缺陷进行分类，可分类的方式只有一种，就是严重极别,难道没有其它的分法吗。比如我们碰到下面这种情况，测试人员发现有一种功能是必需加入进去的，这时他与程序员说，程序员说没有时间或是不必要，这时这种情况则会形成两者的扯皮，最终的结果也就不了了知了，这样会戳伤了测试人员的积极性，下次他们再也不会尽心的考虑产品的问题，只要可以运行就可以了。其实这种情况是可以解决的,下面我会提到一个新的软件缺陷分类概念，从而有效的解决这个问题。
在软件缺陷中不仅仅只是严重极别，更多的则是功能没有做到。说到这里也许大家都理解了，就是需求没有考虑到，可需求不会一次就很完美的，需要大家的共同努力，来不断的完善。那么怎样才能让测试人员提出的好的建议得到有效的执行？这就是我下面想说的。在软件缺陷中还有一种分法，跟据缺陷内容来分, , ，主要分为需求Bug与程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都知道是由相关开发人员进行处理。下面主要讨论一下需求Bug,需求Bug从名称上来就知道是要交由需求人员进行处理，可怎么处理，怎样在处理的过程中有效的, 让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序, , , , 员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求Bug，处理的流程如图。
这样处理有以下好处，首先需求Bug再不象以前，没有人进行确认，需求的处理人员本来就是需求人员，由他们确认与跟踪是最好不过的，因为他们对需求有绝对的权威。同时测试人员其实就是最早的用户，他们的需求就是用户的需求，这种方法加强了需求人员与测试人员的沟通，使需求得到有效的补充，从而让产品更加完善。还有测试人员从本质上来说与程序员还是对立的，这里如果为了这样一个不是软件本身问题的问题形成与开发人员的对立，则会出现赢得战役而丢失整个战争的情况，测试人员协调好与开发人员的关系，让他们更有效的对软件本身的缺陷形成有效的关注是最好的。还有最为关键的一点，测试人员的激情是最重要的，如果他们的想法没有得到体现，这时会渐渐的失去对测试的兴趣，从而软件的质量则会无法得到保证，通过这种方法可以让他们看到自己的建议可以通过对需求人员的反映得到实现，让他们时时觉得自己的想法是可以通过这种方法来有效的推行，这样工作的积极性才会有保障。
不过从实施的角度来说，还是有一定的困难的，首先要让大家改变以前那种凡是Bug就是由开发人员负责的观念，其次需求人员的工作量要加大，不过广泛的了解需求是他们的本份工作，想来不会很困难，还有必需要有有效的Bug管理工具，比如BugManage等等，不要出现那种对需求人员说了，可过两天就忘的情况出现，这时需求Bug的生命周期会出现跨越两个软件开发周期，因为有些需求会在下一版实现，这时测试人员需要延长对这些需求Bug的管理，不过我想这些需求是他们提出的，会有兴趣对这些Bug进行管理的。
四、软件缺陷(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 由于集成的问题引起的缺陷
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进行管理的。
