软件缺陷级别定义【Rice老师】

软件缺陷的等级应如何划分
软件缺陷，常常又被叫做Bug。

所谓软件缺陷，即为计算机软
件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏
的功能缺陷。

缺陷的存在会导致软件产品在某种程度上不能满足用
户的需要。

缺陷的表现形式不仅体现在功能的失效方面，还体现在其他方面。

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

软件缺陷的等级应如何划分？
1）致命错误：造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

2）严重错误：系统主要功能部分丧失，数据库保存调用错误，用户数据丢失，以及功能菜单不能使用但是不影响其他功能的测试。

功能设计与需求严重不符，模块无法启动或调用，程序重启，自动
退出，关联程序间调用冲突，安全问题、稳定性等。

3）一般错误：功能没有完全实现但不影响使用，功能菜单存在缺陷但不影响系统稳定性。

4）建议问题：界面，性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等。

软件缺陷描述规*一、缺陷基本定义软件缺陷（Software Defect）：软件缺陷是对软件产品预期属性的偏离现象。

它包括检测缺陷和残留缺陷。

缺陷的优先性，分为5级，参考下面的方法确定：1)最高优先级(Blocker)，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷，或用户重点关注的问题,缺陷导致系统几乎不能使用或者测试不能继续，需立即修复。

2)较高优先级(Critical)，例如，影响软件功能和性能的一般缺陷, 严重影响测试，需要优先考虑；3)一般优先级(Major)，例如，本地化软件的*些字符没有翻译或者翻译不准确的缺陷,需要正常排队等待修复；4)低优先级(Minor)，例如，对软件的质量影响非常轻微或出现几率很低的缺陷,可以在开发人员有时间的时候再被纠正；5)最低优先级(Trival),例如，属于优化，可以不做修改的问题或暂时无法修复但影响不大的问题。

二、缺陷描述软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发工程师交流的最好机会。

一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。

否则，它就会使信息含糊不清，可能会误导开发人员,因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。

缺陷描述的原则：有效的缺陷描述有以下几个原则：➢可以重现：在缺陷的详细描述中提供精确的操作步骤，可以让发人员容易看懂；➢定位准确：缺陷描述准确，不会引起误解和歧义；➢描述清晰：对操作步骤的描述清晰，易于理解，应用客观的书面语，避免使用口语；➢完整统一：提供完整、前后统一的软件缺陷的步骤和信息，按照一致的格式书写全部缺陷报告，有关缺陷的格式参见"缺陷的格式”；➢短小简练：通过使用关键词，可以使问题摘要的描述短小简练，又能准确解释产生缺陷的现象。

如"在新建任务窗口中，选择直接下达，负责人收不到即时消息”中"新建任务窗口”、"直接下达”、"即时消息”等是关键词；➢特定条件：许多软件功能在通常情况下没有问题，而是在*种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或*种设置等），能够提供帮助开发人员找到原因的线索。

缺陷等级划分规定１．缺陷等级划分规范１．１Bug等级种类及定义:Bug等级可分为:致命,严重,一般的,微小的四种.致命（critical）：致命的错误，造成系统或应用程序崩溃（crash）、死机、系统悬挂、或造成数据丢失、主要功能组完全丧失严重（major）：严重错误，指功能或者特性（feature）没有实现，主要功能丧失，导致严重的问题，或致命的错误声明一般的（normal）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现功能，没有达到预期的效果。

如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等微小的（minor）：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等１．２等级划分步骤:1) 功能方面结合”缺陷发生率”(Exposure Risk)和”影响强度”(Impact Intensity)对Bug进行等级划分.”缺陷发生率”是指在运用产品过程中,出现某个缺陷的频率, 可分为四种:不可避免,经常,偶尔,很少.不可避免(Unaviodable):只要运行系统或应用程序,或者使用软件主要功能,该缺陷就能出现. 经常(Frequent):在使用软件过程中,需要通过几步操作出现,或者是一些不常用的非主要功能的缺陷,或者出现该缺陷的频率在30-70%的.偶尔(Occasional):缺陷出现的前提是通过多次操作或多个步骤,或者缺陷出现的概率在2%-30%.很少(Rare):低频率操作,或者出现的前提是通过N次操作或N个步骤,或者缺陷出现的概率低于2%的.“缺陷影响强度”是指在运用产品过程中,某个缺陷影响产品使用的程度,可分为三种:灾难性,障碍性,干扰性.灾难性(Disastrous):测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现；关键性能指标达不到要求；障碍性(Obstruction):系统的次要功能点或需求点没有实现；数据丢失或损坏。

附件一：缺陷级别定义和优先级定义1、缺陷级别定义2、缺陷优先级定义注：当缺陷被Reopen时，建议通过有效途径通知相关人员，特别是严重级别为high和view high。

3、缺陷报告规范✓在项目执行阶段，发现的所有问题都需要提交缺陷管理库－CQ中相应的Project库中，主要包括软件需求、开发程序缺陷、各种需要审核的文档等方面的内容；✓缺陷报告的填写，需要将问题的重现步骤写清晰，建议安1、2、3...形式提交，且缺陷的相关外部测试条件需要说明详细，缺陷标题要简明、扼要，不要用过于笼统和模糊的语言加以描述，根据需要适当的将出现的场景、日志等信息以附件形式提交；✓对于缺陷的回归，应在CQ中的Comments中注明回归的版本号，并依据问题的严重级别对回归的结果做相应的描述。

●具体的缺陷提交流程如下(针对测试人员)在缺陷的管理中，对于新增的Rejected和Suspend的缺陷，需要定期时常整理确认，对于未经项目经理、开发组长、测试组长和产品经理确认的缺陷，开发人员无权Rejected/Suspend，同时对于达成共识的Rejected缺陷一定要将意见写入CQ 库中的comments,对于Suspend状态的缺陷，建议要注明由于什么原因被刮起，在什么时间和条件下在处理等信息。

在测试任务完成以后，缺陷库中的缺陷状态应只以三种状态存在：Closed、经过确认并达成共识的Rejected/Suspend。

4、缺陷跟踪测试人员对其发现的缺陷有义务和责任进行全程的跟踪。

从缺陷的提交一直到缺陷的关闭，在这一整套的过程中，测试人员应该一丝不苟的进行把关，不要让错误轻易的从手边遛走。

要定期的向开发组通报缺陷状态，同时及时的更新缺陷库中缺陷的状态。

在一定的条件和时间内，还要对以关闭的缺陷做回归测试。

制定有效而可行的回归测试时间表，尽可能的减少由回归测试间隙产生的测试逃逸。

5、缺陷分析对于缺陷数据库，测试人员应该经常维护更新，并对缺陷的状态，数量，分布等状态做统计分析。

软件缺陷等级划分标准
软件缺陷等级划分标准是指根据软件缺陷的严重程度和影响范围，将软件缺陷分为不同等级，以便开发人员和测试人员能够更好地管理和解决软件缺陷。

软件缺陷等级划分标准通常由软件开发公司或项目组制定，也可以参考国际标准或行业标准。

一般来说，软件缺陷等级划分标准包括以下几个方面：
1. 缺陷等级的定义：通常包括严重、一般、轻微等等，不同等级的定义可能有所不同，但一般都是根据缺陷的影响程度和紧急程度来划分的。

2. 缺陷的影响范围：缺陷的影响范围通常包括功能、性能、安全等方面，不同的缺陷可能会对不同的方面产生影响，因此需要根据具体情况来划分。

3. 缺陷的修复时间：不同等级的缺陷需要在不同的时间内进行修复，一般来说，严重的缺陷需要在最短时间内进行修复，而轻微的缺陷可以在后续版本中进行修复。

4. 缺陷的优先级：缺陷的优先级通常是根据缺陷的紧急程度和影响程
度来划分的，优先级高的缺陷需要在优先处理，以保证软件的稳定性和安全性。

总的来说，软件缺陷等级划分标准是软件开发和测试过程中非常重要的一部分，它可以帮助开发人员和测试人员更好地管理和解决软件缺陷，提高软件的质量和稳定性。

因此，在软件开发和测试过程中，需要根据具体情况制定合理的软件缺陷等级划分标准，并严格按照标准进行管理和处理。

软件缺陷等级标准按照CMM5中定义的规范，BUG一般分致命，严重，一般和提示。

致命是严重影响产品的BUG，比如操作手册的错误，需求的错误等。

严重是产品中使功能无法实现的BUG，比如某个功能无法运行，GUI长时间僵死没有响应。

一般是某个BUG的发生，只影响了一个功能，而其他功能可以正常运行。

提示就是一些GUI的问题，或者友好性的问题。

更为详细的划分如下:A类—严重错误，包括以下各种错误：1．由于程序所引起的死机,非法退出2．死循环3．数据库发生死锁4．因错误操作导致的程序中断5．功能错误6．与数据库连接错误7．数据通讯错误-----------------------------------------------------------B类—较严重错误，包括以下各种错误：1．程序错误2．程序接口错误3．数据库的表、业务规则、缺省值未加完整性等约束条件-----------------------------------------------------------C类—一般性错误，包括以下各种错误：1．操作界面错误（包括数据窗口内列名定义、含义是否一致）2．打印内容、格式错误3．简单的输入限制未放在前台进行控制4．删除操作未给出提示5．数据库表中有过多的空字段-----------------------------------------------------------D类—较小错误，包括以下各种错误：1．界面不规范2．辅助说明描述不清楚3．输入输出不规范4．长操作未给用户提示5．提示窗口文字未采用行业术语6．可输入区域和只读区域没有明显的区分标志 E类—测试建议。

软件工程软件测试缺陷等级判定方法
软件工程软件测试缺陷等级判定方法
一、安全隐患
安全隐患是指潜在的安全威胁，可能会导致安全威胁发生。

安全隐患的等级可以根据其影响的范围划分，一般分为三个等级：高风险、中风险和低风险。

1. 高风险：高风险级别的安全隐患，指可能引发影响较大的安全事件，如暴露的敏感信息、访问控制缺陷、缓冲区溢出等。

2. 中风险：中风险级别的安全隐患，指可能引发一定影响的安全事件，如信息泄露、缓冲区错误、决策逻辑错误等。

3. 低风险：低风险级别的安全隐患，指可能会造成一定影响，但不会引发安全事件的潜在隐患，如软件界面设计等。

二、功能缺陷
功能缺陷是指在软件开发过程中，没有按设计要求实现的功能，或者根据用户的需求，软件系统未提供预期的功能。

功能缺陷等级主要有四个：高级别、中级别、低级别和建议级别。

1. 高级别缺陷：高级别缺陷是指程序失效或软件系统出现较严重错误，影响软件使用的缺陷。

2. 中级别缺陷：中级别缺陷是指程序失效或软件系统出现一定程度的错误，可能影响软件使用的缺陷。

3. 低级别缺陷：低级别缺陷是指程序失效或软件系统出现较小的错误，可能影响软件使用体验的缺陷。

4. 建议级别缺陷：建议级别缺陷是指软件系统出现的可优化的缺陷，或者是根据用户需求，软件系统没有进行相应的功能开发，但不影响软件使用的缺陷。

近日，加拿大达内科技公司、北京大学软件学院与亚信科技(中国)公司、精点科技(中国)公司、迪思杰科技(中国)公司、中通网络产业公司以及中关村科技园区的30多家企业达成定向人才培养计划。

从2005年5月8日开始，软件测试时代为这些企业量身培养IT就业市场紧缺的软件测试工程师百余名。

经过2个多月的培训，这些软件测试工程师将直接到领测软件测试时代的签约公司就业。

随着中国IT行业的发展，几乎每个中大型IT企业的产品在发布前都需要大量的质量控制、测试和文档工作。

由于前些年企业对产品的测试工作重视不够，又加上没有系统地测试培训课程，因此软件测试工程师及系统测试工程师将在短期内出现严重的短缺现象。

从近期的企业人才需求和薪金水平来看，测试工程师的年工资有逐年上升的明显迹象。

测试工程师这个职位将成为IT就业的新亮点。

测试工程师一般分为以下几个等级：测试工程师、高级测试工程师和资深测试工程师。

测试工程师一般承担以下工作：利用软件测试工具按照测试方案和流程对产品进行功能和性能测试，检查产品是否有缺陷，性能是否稳定；高级测试工程师一般的职责是：不但能够编写测试工具，而且能够设计和维护测试系统，编写测试方案，编写测试文档、编写安装和使用手册；资深测试工程师的职责要求更高：不但能够具有初级测试工程师和高级测试工程师的能力，而且能够对测试方案可能出现的问题能够进行分析和评估。

今天看到论坛里一个学员在问“到底应该是谁把缺陷状态置为PostPone,Rejected,Duplicate是Developer还是PM或CCB？”，还有学员对优先级这个字段理解的不够透彻，原话是“优先级的填写要看情况的。

因为有时Tester 开的bug 很多，而PM又有好多TESTER，那PM就来不及去一一看那些BUG了，这时Priority就得由tester填写”，而论坛里还有同学找了篇英文的文章来告诉大家“看，老外都是这么做的”。

我觉得有必要给大家解释透这两个概念，这样不至于在日后的工作中做错。

软件缺陷的严重程度标准定义软件缺陷的严重程度标准定义一、引言在软件开发和测试过程中，软件缺陷是不可避免的。

然而，确定缺陷的严重程度对于制定优先级和决定修复方案至关重要。

本文将探讨软件缺陷的严重程度标准定义，并根据深度和广度的要求进行全面评估。

二、软件缺陷的严重程度标准定义1. 严重程度分类软件缺陷的严重程度常常被分为严重、一般和轻微三种。

严重的软件缺陷会导致系统崩溃或功能无法正常使用，影响用户的核心体验；一般的缺陷可能会导致某些功能无法正常工作，但并不影响整体的使用；轻微的缺陷通常是一些小问题或界面上的不适，对系统功能影响较小。

2. 影响范围除了将缺陷分为严重、一般和轻微外，对缺陷的影响范围也是评定严重程度的重要因素。

一个缺陷可能只在特定条件下出现，仅影响少数用户，也可能是系统性的缺陷，影响广泛。

对于影响范围广泛的缺陷，即使影响程度较轻，也应该被视为严重的。

3. 修复难度修复软件缺陷的难度也是评估严重程度的重要因素之一。

一些看似严重的缺陷可能很容易修复，而一些看似轻微的问题可能需要大量的时间和资源。

评定软件缺陷的严重程度时，需要考虑修复的成本和时间。

4. 用户反馈用户反馈也是评估软件缺陷严重程度的重要指标。

对于影响用户使用体验的缺陷，即使在技术上可能属于轻微问题，也应该被重视。

三、对软件缺陷严重程度标准的个人观点和理解在评定软件缺陷的严重程度时，需要综合考虑多个因素，而不是仅仅依靠技术层面的评估。

从用户角度出发，对软件缺陷的影响程度可能和技术人员的评估有所不同，因此用户反馈应该被优先考虑。

修复难度和影响范围也是评定严重程度的重要因素，在制定软件缺陷的修复计划时，需要根据这些因素综合评估，确定优先级。

四、总结与回顾软件缺陷的严重程度标准定义涉及到多个方面，包括缺陷分类、影响范围、修复难度和用户反馈等。

在评定软件缺陷的严重程度时，需要综合考虑以上因素，并根据具体情况确定优先级和修复计划。

对于公司来说，确立明确的严重程度标准定义，能够帮助更好地管理和优化软件开发和测试过程，提高产品质量和用户满意度。

软件缺陷常常又被称为Bug。

所谓软件缺陷就是指计算机软件或者程序中存在的某种破坏正常运行能力的问题、错误或者隐藏的功能缺陷。

Bug 的存在会导致软件产品在某种程度上不能满足用户的需要。

在IEEE 中对Bug 有一个标准的定义:从产品内部看，是指软件产品开发或维护过程中存在的错误、毛病等各种问题。

从产品外部看，是指系统所需要实现的某种功能的失效或违背。

缺陷种类缺陷可以分为不同的种类：遗漏：指规定或预期的需求未体现在产品中。

错误：指需求是明确的，在实现阶段未将规格说明正确实现。

冗余：指需求规格说明未涉及的需求被实现了。

不满意：除了上面3 种情况外，用户对产品的实现不满意也称为缺陷。

缺陷的等级划分在不同的企业对软件缺陷等级的划分大同小异，大致可分为五个等级：致命：指造成系统或应用程序死机、崩溃、非法退出等，会造成用户数据丢失或被破坏，功能设计与需求严重不符的问题。

严重：指功能和特性没有实现，导致模块功能失效或异常退出，还有程序接口错误或者数据流错误等问题。

一般：指主要功能丧失，提示信息不太正确，用户界面设计太差以及删除未提示等问题。

提示：指对功能几乎没有影响，产品及属性仍可使用的问题。

建议：测试人员提出的建议、质疑等问题。

缺陷报告缺陷报告是测试执行完成后，最重要的输出之一，一份好的缺陷报告也是提高软件质量的重要保障。

不同的公司因为缺陷管理的流程不一样，可能有不同的缺陷报告模版。

但是一个完整的缺陷报告通常应该包含以下内容：编号：用数字进行唯一标识缺陷，通常是在缺陷管理工具中新建Bug 时会自动生成。

状态：通常描述当前缺陷的状态，比如修复、延期等。

标题：通常用一句比较简洁的话来概括Bug，通过描述可以初步推测Bug 原因，来提高处理的效率。

类型：主要为了进一步描述缺陷产生的原因，比如功能错误、接口错误、数据库错误等。

所属版本：描述当前Bug 所在的测试版本，便于后期回归时注意测试版本。

所属模块：描述Bug 所在的业务模块，便于后期统计缺陷的分布情况，利于在进行回归测试的方法及测试策略的改进。

软件缺陷定义软件缺陷概述软件缺陷，通常又被叫做Defect或者Bug，即为软件或程序中存在的某种破坏正常运行能力的问题、错误，其存在会导致软件产品在某种程度上不能满足用户的需要。

从产品内部看，缺陷是软件产品开发或维护过程中存在的问题、错误。

从产品外部看，缺项是系统所需要实现的某种功能的失效或违背。

软件缺陷属性软件缺陷的属性包括缺陷标识、缺陷类型、缺陷级别（或严重等级）、缺陷产生可能性（或概率）、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷根源（原因）。

以上属性是为了准确描述缺陷而赋予的，这里分别作介绍：1. 缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示；2. 缺陷类型：功能、用户界面、文档、软件包、性能、接口、兼容性等；a) 功能：影响了各种系统功能、逻辑的缺陷；b) 用户界面：影响了用户界面、人机交互特性的缺陷；c) 文档：影响发布和维护，包括注释、用户手册、设计文档等的缺陷；d) 软件包：由于软件配置库、变更管理或版本控制引起的错误；e) 性能：不满足系统可测量的属性值，如执行时间、事务处理速率等；f) 接口：与其他组件、模块、调用参数、控制块等不匹配、冲突；g) 兼容性：与工作环境、其他外设，如操作系统、浏览器、网络环境等不匹配、冲突；3. 缺陷级别：致命、严重、一般、轻微；（举例）a) 致命：系统任何一个主要功能完全失效，用户数据受到破坏，系统崩溃、悬挂、司机或者危机人身安全；b) 严重：系统的主要功能部分失效，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显影响；c) 一般：系统的次要功能没有完全实现，但不影响用户的正常使用。

如提示信息不准确或用户界面差、操作时间长等。

d) 轻微：使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响理解的错别字、排布不整齐等。

4. 缺陷产生可能性：必现、通常、有时、很少；a) 必现：按照一定路径必定出现，其产生概率为100%；b) 通常：按照测试用例（即已知步骤），通常情况下回产生这个缺陷，其产生频率大概是80%；c) 有时：按照测试用例，有时候产生这个缺陷，其产生频率大概是30%；d) 很少：按照测试用例，很少产生这个缺陷，其产生概率大概是1%以下；实际测试中，仅出现过一次后无法复现的缺陷也划分到此类；e) 缺陷优先级：参见“缺陷级别定义”章节；5. 缺陷状态：打开、已修复、关闭、拒绝、重复、重新打开、推迟、保留、不能重现；（可根据实际情况增加或减少使用的缺陷状态）a) 打开：问题还没有解决，确认“提交的缺陷”，等待处理，如新报的缺陷；b) 已修复：已被开发人员检查、修复过的缺陷，通过单元测试，认为已经解决但还没有被测试人员验证；c) 关闭：测试人员验证后，确认缺陷不存在之后的状态；d) 拒绝：开发人员认为不是缺陷；e) 重复：开发人员认为此缺陷与某打开的缺陷重复；f) 重新打开：测试人员验证后，确认缺陷仍然存在后的状态；g) 推迟：这个软件缺陷可以在下一个版本中解决；h) 保留：由于技术原因或者第三方软件的缺陷，开发人员不能修复的缺陷；i) 不能重现：开发人员不能再现这个缺陷，需要测试人员确认缺陷再现的步骤；6. 缺陷的起源：需求、架构、设计、编码、测试、用户；在软件生命周期中，缺陷所占比例：需求和架构阶段54%、设计阶段25%、编码阶段15%、其他6%；7. 缺陷的来源：需求说明书、设计文档、系统集成接口、数据流（库）、程序代码；a) 需求说明书：需求的错误或不清楚引起的问题；b) 设计文档：设计文档描述不准确，与需求说明书不一致的问题；c) 系统集成接口：系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷；d) 数据流（库）：由于数据字典、数据库中的错误引起的缺陷；e) 程序代码：纯粹由编码引起的缺陷；8. 缺陷的根源：测试策略，过程、工具盒方法，团队/人，缺乏组织和沟通，硬件，软件，工作环境；a) 测试策略：错误的测试范围，误解测试目标，超越测试能力等；b) 过程、工具和方法：无效的需求收集过程，过失的风险管理过程，不适用的项目管理方法，无效的变更控制过程等；c) 团队/人：项目团队职责较差，缺乏培训，没有经验的项目团队，缺乏士气等；d) 缺乏组织和沟通：缺乏用户参与，职责不明确、管理失败等；e) 硬件：硬件配置不对、缺乏等；f) 软件：软件配置不对、缺乏，或操作系统错误导致无法释放资源，工具软件错误，编译器错误等；g) 工作环境：组织机构调整，预算改变，工作环境恶劣等。

有关软件缺陷的知识【软件缺陷的定义】首先是Bug的定义：在软件程序中存在的任何一种破坏正常运行能力的问题或缺陷，都可以叫做“Bug”。

（1）软件未达到软件产品需求说明书中的要求（2）软件出现了软件产品需求说明书中指明不会出现的错误（3）软件功能超出了软件产品需求说明书中指明的范围（4）软件未达到软件产品说明书中未指明但应达到的要求（5）测试人员认为难以理解、不易使用、运行缓慢或最终用户认为不好的问题【软件缺陷的级别】建议：可用性方面的一些建议，如字体颜色等一些不影响使用的问题。

提示：一些小问题，如有个别错别字、文字排版不整齐等，对功能几乎没有影响，软件产品仍可使用。

一般：不太严重的错误，如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。

严重：严重错误，指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失或致命的错误声明。

致命：致命的错误，造成系统崩溃、死机或造成数据丢失、主要功能完全丧失等。

【软件缺陷的状态】凡是使用过缺陷管理工具，如BugFree、JIRA等都会知道Bug无非是这几种状态：新建、接受/处理、拒绝、已修复、关闭、重新打开、挂起。

状态之间的跳转图如下：【软件缺陷的处理】上面的知识点在各种网站和书籍上都可以查找到，但实际测试当中，测试人员需要严格的按照测试流程执行，时时检查开发人员是否在未沟通的情况下挂起或挂起BUG，另外软件发布时，基本上很少能达到100%的Bug修复后上线，那么如何在还有Bug遗留的情况下，评估是否可以发布呢？1、缺陷的挂起率首先项目发布时，缺陷的挂起率不能超过15%，并且被挂起的Bug也需要对影响面进行评估，对用户影响大的，比如有延迟问题，延迟时间超过15s，这类bug都原则上不允许挂起，需要优化解决，另外在测试报告中的测试建议中可以说明：● 可以全量发布：适用于没有挂起bug或没有重现率高的严重致命的挂起bug。

● 建议灰度发布：适用于挂起的严重致命bug重现率低（低于50%），或用户不容易感知。

软件测试缺陷定义和管理
我们需要知道的是软件BUG其实就是软件设计没有达到预期设计⽬标，导致在软件内存在的⼀种缺陷。

可以⼀句话概括：⼀切不符合需求规格说明书要求的，都可以视作软件缺陷。

定义：（1）软件未达到产品说明书标明功能
（2）软件出现了产品说明书指明不会出现的错误
（3）软件功能超出产品说明书指明范围
（4）软件未达到产品说明书未指出但应达到的⽬标
（5）软件测试⼈员认为软件难以理解.不易使⽤.运⾏缓慢或⽤户认为不好的问题
BUG的产⽣原因：1.需求不断变化 2.软件的复杂性 3.⼯期短，任务⼤ 4.⽂档不完善 5.程序设计错误 6.软硬件⽀持不完善 7.沟通交流不够缺陷报告处理流程：
缺陷报告模板：
缺陷的严重级别：致命：系统崩溃，404报错，报500，造成系统或应⽤程序崩溃，死机，系统悬挂，造成数据丢失，页⾯出现错误乱码，蓝屏等
严重：功能未实现，逻辑错误，影响⽤户正常操作，与需求完全不符，或因此BUG导致后续功能⽆法测试
⼀般：功能实现但不正确，功能上的错误，页⾯中的错误，逻辑实现但不正确
轻微：⽂案内容与实际不符，错别字，图⽚错误，建议性BUG
缺陷的优先级：可分为⾼，中，低，建议。

当然这个根据公司和⼯具不同，叫法不⼀样。

不过划分都是差不多的
⾼：BUG严重级别较⾼，需要⽴刻解决的，或者⼀般级别的但是⽐较棘⼿的
中：BUG严重级别⼀般的，不影响⽤户正常操作的
低：BUG严重级别处于较低的，可以下⼀次alpha测试前解决的
建议：建议性的BUG，可以改也可以不改。

缺陷BUG等级定义都分为那些级别缺陷BUG等级定义都分为那些级别缺陷等级等级名称等级定义P1 严重缺陷应用系统崩溃或系统资源使用严重不足：1、系统停机（含软件、硬件）或非法退出，且无法通过重启恢复；2、系统死循环；3、数据库发生死锁或程序原因导致数据库断连；4、系统关键性能不达标。

5、数据通讯错误或接口不通6、错误操作导致程序中断P2 较严重缺陷系统因软件严重缺陷导致下列问题：1、重要交易无法正常使用、功能不符合用户需求；2、重要计算错误；3、业务流程错误或不完整；4、使用某交易导致业务数据紊乱或丢失；5、业务数据保存不完整或无法保存到数据库。

6、周边接口出现故障（需考虑接口时效/数量等综合情况）；7、服务程序频繁需要重启（每天2次或以上）；8、批处理报错中断导致业务无法正常开展。

9、前端未合理控制并发或连续点击动作，导致后台服务无法及时响应。

10、在产品声明支持的不同平台下，出现部分重要交易无法使用或错误。

P3 一般性缺陷系统因软件一般缺陷导致下列问题：1、部分交易使用存在问题，不影响业务继续开展，但造成使用障碍。

2、初始化未满足客户要求或初始化错误3、功能点能实现，但结果错误；4、数据长度不一致；5、无数据有效性检查或检查不合理；6、数据来源不正确；7、显示/打印的内容或格式错误；8、删除操作不给提示；9、个别交易系统反应时间超出正常合理时间范围10、日志记录信息不正确或应记录而未记录11、在产品声明支持的不同平台下，出现部分一般交易无法使用或错误。

P4 较小缺陷系统因软件操作不便方面缺陷：1、系统某些查询、打印等实时性要求不高的辅助功能无法正常使用；2、界面错误3、菜单布局错误或不合理4、焦点控制不合理或不全面；5、光标,滚动条定位错误；6、辅助说明描述不准确或不清楚；7、提示窗口描述不准确或不清楚；8、日志信息不够完整或不清晰，影响问题诊断或分析的；P5 其他缺陷系统辅助功能缺陷：1、缺少产品使用、帮助文档、系统安装或配置方面需要信息；2、联机帮助、脱机手册与实际系统不匹配3、系统版本说明不正确；4、长时间操作未给用户进度提示；5、提示说明未采用行业规范语言；6、显示格式不规范7、界面不整齐8、软件界面、菜单位置、工具条位置、相应提示不美观，但不影响使用P6 建议、优化类建议优化类分享给朋友：. .。