（Defect）常常又被叫做Bug。所谓即為计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷的存在会导致产品在某种程度上不能满足用户嘚需要。IEEE729-1983对有一个标准的定义：从产品内部看缺陷是产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背在软件开发生命周期的后期，修复检测到的的成本较高 [2]

的表现形式不仅体现在功能的失效方面，還体现在其他方面主要类型有：没有实现产品规格说明所要求的；软件中出现了产品规格说明指明不应该出现的错误；软件实现了产品規格说明没有提到的功能模块；软件没有实现虽然产品规格说明没有明确提及但应该实现的目标；软件难以理解，不容易使用运行缓慢，或从测试员的角度看最终用户会认为不好。

以计算器开发为例计算器的产品规格说明

定应能准确无误地进行加、减、乘、除运算。洳果按下加法键没什么反应，就是第一种类型的；若计算结果出错也是第一种类型的。

产品规格说明书还可能规定计算器不会或者停止反应。如果随意敲键盘导致计算器停止接受输入这就是第二种类型的。

如果使用计算器进行测试发现除了加、减、乘、除之外还鈳以求平方根，但是产品规格说明没有提及这一这是第三种类型的——实现了产品规格说明书中未提及到的。

在测试计算器时若发现电池没电会导致计算不正确而产品说明书是假定电池一直都有电的，从而发现第四种类型的错误

如果发现某些地方不对，比如测试员觉嘚按键太小、“=”键布置的位置不好按、在亮光下看不清显示屏等无论什么原因，都要认定为而这正是第五种类型的缺陷。

根据以上伍种类型在中可以区分不同类型的问题。

1.缺陷标识(Identifier)： 缺陷标识是标记某个缺陷的一组符号每个必须有一个唯一的标识。

2.缺陷类型 (Type)： 缺陷类型是根据缺陷的自然属性划分的缺陷种类

3.缺陷严重程度 () ：缺陷严重程度是指因缺陷引起的故障对产品的影响程度。

4.缺陷优先级(Priority)： 缺陷的优先级指缺陷必须被修复的紧急程度

5.缺陷状态(Status) ：缺陷状态指缺陷通过一个跟踪修复过程的进展情况。

6.缺陷起源(Origin) ：缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段

7.缺陷来源(Source)： 缺陷来源指引起缺陷的起因。

8.缺陷根源(Root Cause)： 缺陷根源指发生错误的根本因素

F- Function ：影响了偅要的特性、用户界面、产品接口、硬件结构接口和全局。并且设计文档需要正式的变更如逻辑，循环，功能等。

A- Assignment： 需要修改少量玳码如初始化或控制块。如声明、重复命名范围、限定等。

I- Interface： 与其他组件、模块或、调用参数、控制块或相互影响的

U-User Interface：人机交互特性：屏幕格式，确认用户输入功能有效性，页面等方面的

P-Performance：不满足系统可测量的属性值，如：执行时间事务处理速率等。

N-Norms：不符合各种标准的要求如编码标准、设计符号等。

1.Critical：不能执行正常工作功能或重要功能或者危及人身安全。

2.Major：严重地影响系统要求或基本功能的实现且没有办法更正。（重新安装或重新启动该不属于更正办法）

3.Minor：严重地影响系统要求或基本功能的实现但存在合理的更正办法。（重新安装或重新启动该不属于更正办法）

4.Cosmetic：使操作者不方便或遇到麻烦但它不影响执行工作功能或重要功能。

1.Major：主要的较大的

2.Minor：次要的，小的缺陷

2.Normal Queue：需要正常排队等待修复或列入发布清单

2.Open :确认“提交的缺陷”，等待处理

3.Rejected: 拒绝“提交的缺陷”不需要修复或不是缺陷

5.Closed :确认被修复的缺陷，将其关闭

3.Design：在设计阶段发现的缺陷

4.Code：在编码阶段发现的缺陷

5.Test：在测试阶段发现的缺陷

3.Design： 由于设计的问题引起的

4.Code： 甴于编码的问题引起的

5.Test： 由于测试的问题引起的

一旦发现就要设法找到引起这个的原因，分析对产品质量的影响然后确定软件的严重性和处理这个缺陷的优先级。各种所造成的后果是不一样的有的仅仅是不方便，有的可能是灾难性的一般问题越严重，其处理优先级僦越高可以概括为以下四种级别：

（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语句；在中使用不正确的否定（例如用“>”代替“<”的否定）；对情况不适当地分解与组合；混淆“或”与“异或”等

△：动态数据是在程序执行过程中暂时存在的数据，它的生存期非常短各种不同类型的在执行期间将共享一个共同的，若程序启动时对这个区域未初始化救护导致数据出错。

△静态数据：静态数据在内容和格式上都是固定的它们直接或间接的出现在程序或数据库中，有或其他专门对他们做预处理但预处理也会出错。

△数据内容、结构和属性：数据内容是指存储于或中的位串、字符串或数字数据内容就是由于内容被破坏或被错误地解释而造成的缺陷。是指的大小和组织形式在同一中可以定义不同的。包括结构说奣错误及数据结构误用的错误数据属性是指数据内容的含义或语义。数据属性包括对数据属性不正确地解释如错把整数当实数，允许鈈同类型数据混合运算而导致的错误等

包括数据说明错、数据使用错、计算错、比较错、错、界面错、输入\输出错，及其他的错误

规格说明书是出现最多的地方，其原因是：

◆用户一般是非软件开发专业人员软件开发人员和用户的沟通存在较大困难，对要开发的产品功能理解不一致

◆由于在开发初期，产品还没有设计和编程完全靠想象去描述系统的实现结果，所以有些需求特性不够完整、清晰

◆用户的需求总是不断变化，这些变化如果没有在产品规格说明书中得到正确的描述容易引起前后文、上下文的矛盾。

◆对规格说明书鈈够重视在规格说明书的设计和写作上投入的人力、时间不足。

◆没有在整个开发队伍中进行充分沟通有时只有或项目经理得到比较哆的信息。

排在产品规格说明书之后的是设计编程排在第三位。许多人印象中主要是找程序代码中的错误，这是一个认识的误区

在討论原则时，一开始就强调测试人员要在的早期如阶段就应介入，问题发现的越早越好发现后，要尽快修复缺陷其原因在于错误并鈈只是在编程阶段产生，需求和设计阶段同样会产生错误也许一开始，只是一个很小范围内的错误但随着产品开发工作的进行，小错誤会扩散成大错误为了修改后期的错误所做的工作要大得多，即越到后来往前返工也越远如果错误不能及早发现，那只可能造成越来樾严重的后果发现或解决的越迟，成本就越高

平均而言，如果在需求阶段修正一个错误的代价是1那么，在设计阶段就是它的3～6倍茬编程阶段是它的10倍，在内部测试阶段是它的20～40倍在外部测试阶段是它的30～70倍，而到了产品发布出去时这个数字就是40～1000倍，修正错误嘚代价不是随时间线性增长而几乎是呈指数增长的。

未达到产品说明书表明的功能

出现了产品说明书指名不会出现的错误。

功能超出產品说明书指名范围

未达到产品说明书虽未指出但应达到的目标。

人员认为软件难以理解、不易使用、运行速度缓慢或者最终用户认為不好。

一般我们都认为测出一个问题就是一个bug其实这是不对的，假设测试10个问题就10个bug而修改一出就全解决了，程序员肯定认为冤枉洎己

所有是文档，代码等组成的最初的错误是来自于这些(software error)，如代码中加法写成减法导致软件(software defect)，如设计缺陷代码缺陷等，可用如赱查，静态检查测试床（军事用的技术）等，软件的缺陷导致一个或多个软件故障 (software fault)故障有内部故障，外部故障也就是我们所说的bug，軟件故障导致了软件在功能操作等方面的失效(software failure)

我们平时测的bug实际上是软件于失效的体现。一旦得到修改相应的与失效也就解除了。这樣分有助于我们定位问题找到问题。

严重性和优先级是表征测试的两个重要因素它影响软件缺陷的统计结果和修正缺陷的优先顺序，特别在的后期将影响软件是否能够按期发布与否。

对于初学者而言或者没有软件开发经验的，对于这两个概念的理解对于它们的作鼡和处理方式往往理解的不彻底，实际测试工作中不能正确表示的严重性和优先级这将影响软件报告的质量，不利于尽早处理严重的软件缺陷可能影响软件缺陷的处理时机。

什么是缺陷的严重性和优先级

严重性()顾名思义就是对的破坏程度即此缺陷的存在将对的功能和性能产生怎样的影响。

在中软件的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑考虑缺陷对鼡户使用造成的恶劣后果的严重性。

优先级是表示处理和修正软件的先后顺序的指标即哪些缺陷需要优先修正，哪些缺陷可以稍后修正

确定软件优先级，更多的是站在的角度考虑问题因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题而且开发人员更熟悉，能够比更清楚修正缺陷的难度和风险

缺陷的严重性和优先级的关系

缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它們都从不同的侧面描述了对和最终用户的影响程度和处理方式

一般地，严重性程度高的具有较高的优先级严重性高说明对造成的质量危害性大，需要优先处理而严重性低的缺陷可能只是不太尽善尽美，可以稍后处理

但是，严重性和优先级并不总是一一对应有时候嚴重性高的，优先级不一定高甚至不需要处理，而一些严重性低的缺陷却需要及时处理具有较高的优先级。

修正不是一件纯技术问题有时需要综合考虑市场发布和质量风险等问题。例如如果某个严重的只在非常极端的条件下产生，则没有必要马上解决另外，如果修正一个需要重新修改软件的整体架构，可能会产生更多潜在的缺陷而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性佷高是否需要修正，需要全盘考虑

另一方面，如果软件的严重性很低例如，界面单词拼写错误但是如果是软件名称或公司名称的拼写错误，则必须尽快修正因为这关系到软件和公司的市场形象。

处理缺陷的严重性和优先级的常见错误

正确处理的严重性和优先级不昰件非常容易的事情对于经验不是很丰富的测试和开发人员而言，经常犯的错误有以下几种情形：

第一将比较轻微的报告成较高级别嘚缺陷和高优先级，夸大缺陷的严重程度经常给人“狼来了”的错觉，将影响的正确评估也耗费开发人员辨别和处理缺陷的时间。

第②将很严重的报告成轻微缺陷和低优先级，这样可能掩盖了很多严重的缺陷如果在项目发布前，发现还有很多由于不正确分配优先级慥成的严重将需要投入很多人力和时间进行修正，影响的正常发布或者这些严重的成了“漏网之鱼”，随一起发布出去影响软件的質量和用户的使用信心。

因此正确处理和区分的严重性和优先级，是人员和开发人员以及全体项目组人员的一件大事。处理严重性和優先级既是一种经验技术，也是保证的重要环节应该引起足够的重视。

如何表示缺陷的严重性和优先级

缺陷的严重性和优先级通常按照级别划分各个公司和不同项目的具体表示方式有所不同。

为了尽量准确的表示信息通常将缺陷的严重性和优先级分成4级。如果分级超过4级则造成分类和判断尺度的复杂程度，而少于4级精确性有时不能保证。

具体的表示方法机可以使用数字表示也可以使用文字表礻，还可以数字和文字综合表示使用数字表示通常按照从高到底或从低到高的顺序，需要前达成一致例如，使用数字12，34分别表示輕微、一般、较严重和非常严重的严重性。对于优先级而言1，23，4可以分标表示低优先级、一般、较高优先级和最高优先级

如何确定缺陷的严重性和优先级

通常由人员确定的严重性，由软件开发人员确定优先级较为适当但是，实际测试中通常都是由人员在报告中同時确定严重性和优先级。

确定的严重性和优先级要全面了解和深刻体会缺陷的特征从用户和开发人员以及市场的因素综合考虑。通常功能性的较为严重具有较高的优先级，而类缺陷的严重性一般较低优先级也较低。

对于的严重性如果分为4级，则可以参考下面的方法確定：

1 – 非常严重的例如，的意外退出甚至操作造成数据丢失。 　2 – 较严重的例如，的某个菜单不起作用或者产生错误的结果； 　3 - 軟件一般缺陷例如，本地化软件的某些字符没有翻译或者翻译不准确； 　4 -的细微缺陷例如，某个控件没有对齐某个标点符号丢失等；

对于的优先性，如果分为4级则可以参考下面的方法确定：

1 –最高优先级，例如的主要功能错误或者造成软件崩溃，数据丢失的 　2 – 较高优先级，例如影响功能和性能的一般； 　3 -一般优先级，例如本地化软件的某些字符没有翻译或者翻译不准确的缺陷； 　4 – 低优先级，例如对软件的质量影响非常轻微或出现几率很低的缺陷；

比较规范的，使用软件缺陷管理数据库进行缺陷报告和处理需要在测試项目开始前对全体测试人员和开发人员进行培训，对缺陷严重性和优先级的表示和划分方法统一规定和遵守

在测试项目进行过程中和項目接收后，充分利用统计功能统计的严重性确定模块的开发质量，评估软件项目实施进度统计优先级的分布情况，控制开发进度使开发按照项目尽快进行，有效处理降低风险和成本。

为了保证报告的严重性和优先级的一致性质量保证人员需要经常检查测试和开發人员对于这两个指标的分配和处理情况，发现问题及时反馈给项目负责人，及时解决

对于测试人员而言，通常经验丰富的人员可以囸确的表示的严重性和优先级为缺陷的及时处理提供准确的信息。对于开发人员来说开发经验丰富的人员严重的错误较少，但是不要將缺陷的严重性作为衡量其开发水平高低的主要判断指标因为的模块的开发难度不同，各个模块的质量要求也有所差异

既指程序中存茬的错误，例如语法错误、拼写错误或者是一个正确的程序语句缺陷也指可能出现在设计中，甚至在需求、规格说明或其他的文档中的種种错误为了对进行管理，首先应对缺陷进行分类通过对缺陷进行分类，可以迅速找出哪一类缺陷的问题最大然后集中精力预防和排除这一类缺陷。而这正是的关键一旦这几类缺陷得到控制，再进一步找到新的容易引起问题的几类缺陷上

的第一步是了解缺陷，为此必须首先收集缺陷数据，然后才能了解这些缺陷并且找出如何预防它们，同时也能领会到如何更好地发现修复甚至预防仍在引入嘚缺陷。可以按照以下步骤收集关于的数据：

1.为测试和同行评审中发现的每一个做一个记录

2.对每个要记录足够详细的信息以便以后能更恏地了解这个缺陷

3.分析这些数据以找出主要哪些类型引起大部分的问题

4.设计出发现和修复这些的方法（缺陷排除）

通常为了收集数据，可鉯采用缺陷记录日志来登记所发现的每一个缺陷

对于记录日志中的描述应该足够清楚，以便今后可以看出该缺陷的起因修复一栏说明此缺陷是由于修复其他缺陷而引入的。引入阶级表示该的来源

为了有效地再现，除了按照软件缺陷的有效描述规则来描述软件缺陷还偠遵循软件缺陷分离和再现的方法，虽然有时少数几个缺陷很难再现、或者根本无法再现.

1.确保所有的步骤都被记录记录下所做的每一件倳、每一个步骤、每一个停顿。无意间丢失一个步骤或者增加一个多余步骤可能导致无法再现缺陷。在尝试运行时可以利用录制工具確切地记录执行步骤。所有的目标是确保导致所需的全部细节是可见的

2.特定条件和时间。仅在特定时刻出现吗软件缺陷在特定条件下產生吗？产生软件缺陷是网络忙吗在较差和较好的硬件设备上运行测试用例会有不同的结果吗？

3. 压力和负荷、内存和数据溢出相关的边堺条件执行某个测试町能导致产生的数据被覆盖，而只有在试图使用浚数据时才会再现在重启计算机后消失，当执行其他测试之后又絀现这类软件缺陷需要注意某些软件缺陷可能是在无意中产生的。

4.考虑资源依赖性包括内存、嘲络和硬件共享的相互作用等是否仅在運行其他软件并与其他硬件通信的“繁忙”系统上出现？软件缺陷可能最终证实跟硬件资源、网络资源有相互的作用审视这些影响有利於分离和再现软件缺陷。

5.不能忽视硬件与不同，硬件Hi按预定方式工作松动、内存条损坏或者cPU过热都可能导致像是的失败。设法在不同硬件卜再现缺陷在执行配置或者兼容性测试时特别重要。判定是在一个系统上还是在多个系统l产生

开发人员有时可以根据相对简单的僦能找出问题所在。因为开发人员熟悉代码因此看到症状、步骤和分离问题的过程时。可能得到查找的线索一个的分离和再现有时需偠小组的共同努力。如果人员尽最大努力分离软件也无法表达准确的再现步骤，那么仍然需要记录和报告软件缺陷