缺陷的严重性和优先级

合集下载

关于BUG严重程度、处理优先级、bug类型的划分

关于BUG严重程度、处理优先级、bug类型的划分转载⼀严重程度致命：系统⽆法正常运⾏严重：很明显的错误性的bug较重：相对明显的错误性的bug⼀般：常见的bug建议类：（暂时保留，可能去掉）⼆优先级说明：紧急相当于执⾏前的准备⼯作，重要相当于后续的⼯作重要且紧急：优先级最⾼，⼀定要做的重要不紧急：暂时可以先缓⼀缓但⼀定要做的紧急不重要：可以先准备下，随时准备做的不紧急不重要：可忽略不计的三 bug类型：功能错误：功能上的错误性bug代码错误：⼀般很少出现，通常在⾃测时出现（对⽩盒测试、⾃测的⽐较适合）内容相关：业务逻辑⽅⾯以及业务描述等相关问题表单相关：表单逻辑、样式、内容问题⽤户界⾯：UI表现，包括对话框样式和⽂字描述问题需求变动：原有的需求基础上的更改新增需求：会议上提出的新需求，⾮正式会议提出的不属于该项设计⽂档：数据库设计⽂档、概要/详细设计⽂档建议：功能已满⾜但待改善，属于改良性建议配置相关：如web服务器或者数据库服务器配置等问题安装部署：项⽬部署时出现的错误，可能不是程序本⾝的问题⽽是⼯具本⾝和⼈为因素引起安全相关：加密和⽔印等安全信息性能压⼒：负载、压⼒测试标准规范：根据国际标准或者公司内部制定的某标准测试脚本：如⽤⼯具LR编写并执⾏脚本进⾏测试事务跟踪：产品缺陷/bug跟踪（Defect/bug Tracking）⼯作任务跟踪（Task Tracking）问题解决过程跟踪（Problem Tracking）产品需求管理（Request Management）客户服务过程跟踪（Customer Support TrackingBad Case：和⽤例没有关联起来，所以暂时不⽤其他：尽量避免⽤该项，不便于统计但仍保留。

软件缺陷描述规范

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

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

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

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

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

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

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

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

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

软件缺陷等级划分标准

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

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

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

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

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

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

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

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

缺陷管理流程描述

缺陷管理的流程在软件的开发、评审、测试和使用的过程中，我们都可能面临或碰到软件产品没有按照设计要求运行、使用不方便或在某种程度上不能满足用户的要求等此类问题，这些我们可以通称为缺陷。

软件缺陷是软件开发过程中的"副产品"。

缺陷会存在于软件产品的整个生命周期中：可以是软件代码的问题、系统文档（开发文档和测试文档等）存在的问题，或者是用户的帮助文档和使用指南方面的问题等。

测试是发现缺陷的主要手段，也是它的主要目的。

测试活动和开发活动一样，是项目质量保证不可或缺的重要部分。

因此，对于测试活动的主要产物：缺陷，我们需要建立一个完善的缺陷管理流程，来对缺陷进行报告、查询、分类、跟踪、处理和验证等。

本文主要针对在开发测试活动中发现的缺陷，其相应的缺陷管理流程，以及在流程中主要的缺陷状态、参与缺陷的角色和缺陷相关的主要活动以及缺陷的等级分类等。

1.缺陷状态的主要处理过程：2.和缺陷相关的角色：测试工程师：在这里主要是指发现和报告缺陷的测试人员。

在一般流程中，他需要对这个缺陷后续相关的状态负责：包括相关人员对这个缺陷相关信息的询问回答，以及在build中的验证测试和后面正式版本的验证测试。

●开发工程师：这里主要指对这个缺陷进行研究和修改的开发人员。

同时，他需要对修改后的缺陷在提交测试人员正式测试验证之前需要进行验证测试。

●缺陷评审委员会：主要由项目经理、测试经理、质量经理、开发经理以及资深的开发、测试工程师等组成。

他们对缺陷进行确认以及将之分配给相应的开发人员进行修改。

●版本经理：负责将已经解决的缺陷相关的配置信息融入到新的版本，提交新的测试和相关的验证测试。

3.缺陷状态的含义解释：●New（新缺陷）：软件中新发现报告的缺陷，一般由测试人员提交。

当然也可能是开发人员自己在单元或代码测试过程中提交，或从软件使用的最终用户或测试现场反馈得到的缺陷报告。

●Accepted（接受）：经过缺陷评审委员会的确认，认为缺陷确实存在。

软件缺陷的属性

缺陷根源测试策略过程，工具和方法
团队/人缺乏组织和通讯
描述
错误的测试范围，误解了测试目标，超越测试能力等无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，没有估算规程，无效的变更控制过程等项目团队职责交叉，缺乏培训,没有经验的项目团队，缺乏士气和动机不纯等缺乏用户参与，职责不明确，管理失败等
硬件软件
工作环境
硬件配置不对、缺乏，或处理器缺陷导致算术精度丢失，内存溢出等软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，2000 千年虫问题等。组织机构调整，预算改变，工作环境恶劣，如噪音过大。
已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证
关闭或非激活(Closed or Inactive)
测试人员验证后，确认缺陷不存在之后的状态。
重新打开(Reopen)
测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复
推迟(Deferred)
这个软件缺陷可以在下一个版本中解决
描述需求说明书的错误、或不清楚引起的问题
设计文档描述不准确、和需求说明书不一致的问题
系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷
由于数据字典、数据库中的错误引起的缺陷
纯粹在编码中的问题所引起的缺陷
缺陷根源：指造成上述错误的根本因素，以寻求软件开发流程的改进、管理水平的提高，如软件缺陷根源列表所示：
缺陷起源需求构架
设计编码测试用户
描述在需求阶段发现的缺陷
在系统构架设计阶段发现的缺陷在程序设计阶段发现的缺陷
在编码阶段发现的缺陷
在测试阶段发现的缺陷

缺陷等级的划分

BUG等级划分方法一、四级的划分方式：1.BUG等级划分建议：目前project上的BUG严重程度分为五个等级，按照CMM5中定义的规范，BUG严重等级可分为3-5个等级，由于我们公司的CMM水平还处于初级阶段，将BUG等级划分过细不符合我们当前的CMM水平，同时也不利于测试人员对BUG等级的精确划分。

根据我们公司的情况，同时参照其它中小公司的等级划分标准，建议将BUG等级划分四个等级，分别为致命、严重、一般、提示。

● 致命(可对应目前BUG体系中的“非常严重”)：致命性问题主要为：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。

具体基本上可分为：○严重花屏○内存泄漏○用户数据丢失或破坏○系统崩溃/死机/冻结○模块无法启动或异常退出○严重的数值计算错误○功能设计与需求严重不符○其它导致无法测试的错误● 严重(可对应目前BUG体系中的“严重”)严重性问题主要为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。

具体基本上可分为：○功能未实现○功能错误○系统刷新错误○语音或数据通讯错误○轻微的数值计算错误○系统所提供的功能或服务受明显的影响● 一般(可对应于目前BUG体系中的“普通”)一般性问题主要为：界面、性能缺陷具体基本上可分为：○操作界面错误(包括数据窗口内列名定义、含义是否一致) ○边界条件下错误○提示信息错误(包括未给出信息、信息提示错误等)○长时间操作无进度提示○系统未优化(性能问题)○光标跳转设置不好，鼠标(光标)定位错误● 提示(可对应于目前BUG体系中的“轻微及建议”)提示性问题主要为：易用性及建议性问题具体基本上可分为：○ 界面格式等不规范○ 辅助说明描述不清楚○ 操作时未给用户提示○ 可输入区域和只读区域没有明显的区分标志○ 个别不影响产品理解的错别字○ 文字排列不整齐等一些小问题○ 建议注意：对于结构及硬件问题，由于产品测试部仅是进行辅助测试，碰到此类问题时，均将于定位于等级“致命”，具体情况由结构及硬件部门相关人员确认。

测试文档二 bug严重程度和优先级(缺陷管理)

bug严重级别和优先级别定义Bug严重级别：是指因缺陷引起的故障对软件产品的影响程度。

由测试人员指定。

如下：最高级(1类)-- 致命级别阻止对后续功能的测试，通常适用于以下情况1 模块无法启动或异常退出2界面/功能Crash 导致一系列测试不能运行3严重花屏4数据丢失（用户数据，服务器数据）5系统崩溃/死机/冻结6 业务逻辑错误（数据计算错误：例如支付错误，业务流程缺失或者走错）7功能设计和需求严重不符8服务器400，500等错误9 影响流程问题，升级失败10 业务逻辑流程中断跳转到其他页面次最高级（2类）- 严重级别在当前发布版本中必须修复，即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性1 Bug 的出现导致软件没有完成用户的需求2 系统刷新错误3数值计算错误4影响功能及界面的错误字或拼写错误5 安全性问题6 兼容性问题（用户群体大，影响严重）7 数据不准，建单据报错8 引发性新BUG（说明此单BUG是由于前面修改BUG或做的新需求导致其它模块出现新的错误。

一般（3类）一般级别-- 在时间许可的范围内修复，即界面、性能缺陷1 只有在极端条件下才会重现的Bug2 在特定配置情况下不会出现的Bug3 操作界面错误（包括数据窗口内列名定义、含义是否一致）4 边界条件下错误5 提示信息错误6系统未优化，性能问题7 兼容性问题（有一定用户群体，影响较大）低（4类）轻微-- 不影响当前发布，可以推迟到下一个发布中修复，即易用性及建设性问题1 不能稳定重现的Bug2 因为电脑上装有其他干扰软件产生的Bug3 非功能性Bug, 如日志，错误回复等4 界面规格不规范5 辅助说明描述不清6 操作时未给用户提示信息7 个别不影响产品功能的错别字8 文字排列不整齐9兼容性问题（用户群体不大，影响相对较小）10 错误提示信息不准确有歧义Priority（优先级）1 Immediate（紧急，一类）即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。

初级软件测试面试题

初级软件测试面试题1.请描述如何划分缺陷与错误严重性和优先级别？给软件缺陷与错误划分严重性和优先级的通用原则：（1）表示软件缺陷所造成饿危害和恶劣程度。

（2）优先级表示修复缺陷的重要程度和次序。

严重性：（1）严重：系统崩溃、数据丢失、数据毁坏（2）较严重：操作性错误、结果错误、遗漏功能（3）一般：小问题、错别字、UI布局、罕见故障（4）建议：不影响使用的瑕疵或更好的实现。

优先级：（1）最高优先级：立即修复，停止进一步测试。

（2）次高优先级：在产品发布之前必须修复。

（3）中等优先级：如果时间允许应该修复。

（4）最低优先级：可能会修复，但是也可能发布。

2.一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。

一套完整的测试应该由五个阶段组成：1.测试计划首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。

2.测试设计将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。

3.测试开发建立可重复使用的自动测试过程。

4.测试执行执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。

测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。

5.测试评估结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。

3.一条软件缺陷都记录了哪些内容？1.通用UI要统一、准确缺陷报告的UI要与测试的软件UI保持一致，便于查找定位。

2.尽量使用业界惯用的表达术语和表达方法使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。

软件缺陷的严重性和优先级

D类——较小错误
1、界面不规范 2、辅助说明描述不清楚 3、输入输出不规范 4、长操作未给用户提示 5、提示窗口文字未采用行业术语 6、可输入区域和只读区域没有明显的区分标志
软件缺陷的优先级列表
缺陷优先级县级立即解决高优先级正常排队低优先级描述缺陷导致系统几乎不能使用，需立即修复缺陷严重，影响测试，需优先考虑缺陷需要正常排队等待修复缺陷可以在开发人员有时间的时候被纠正
软件缺陷的严重性和优先级
软件缺陷的描述
• 软件缺陷，也就是我们平常在编程过程中遇到的所谓的bug。详细的说就是导致计算机软件或者程序不能够正常运行的一些语法问题、符号问题、参数问题、错误或者一些隐藏的功能缺陷。软件缺陷会导致客户在使用过程中不能实现客户想要完成的功能，所以在软件测试的过程中，我们要尽早的发现软件的缺陷并竭尽所能的改善它，使软件变的完美。
优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。
软件缺陷严重性的等级划分
A类——致命错误 B类——严重错误 C类——一般性错误 D类——较小错误
A类——致பைடு நூலகம்错误
1、由于程序所引起的死机，非法退出。 2、死循环 3、数据库发生死锁 4、因错误操作导致的程序中断 5、功能错误 6、与数据库链接错误 7、数据通讯错误
处理严重性和优先级常见的错误
第一、常常将比较轻微的缺陷报告成较为严重的缺陷和较高的优先级。夸大了缺陷的程度。这样会消耗开发人员辨别和处理缺陷的时间。第二、与第一个错误刚好相反，常常把较大的缺陷报告成较小的缺陷和较低的优先级，这样就掩盖了很多严重的缺陷，给软件带来很多麻烦，也造成了很多漏网之鱼。因此，正确处理和区分缺陷的严重性和优先级，是软件测试人员和开发人员，以及全体项目组人员的一件大事。处理严重性和优先级，既是一种经验技术，也是保证软件质量的重要环节，应该引起足够的重视。

问题严重程度和优先级定义

关于缺陷等级的那些事
一、缺陷的等级
缺陷等级主要从两个方便进行划分：缺陷的优先级（p）、缺陷的严重程度（级别）缺陷的优先级分为四类： 1- Immediate 、2- Urgent 、3- High 、4- Normal 1、Immediate 即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。 2、Urgent即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。 3、High即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。 4、Normal即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。即问题在系统发布以前必须确认解决或确认可以不予解决。缺陷的严重程度分为四类：1-Blocker、2-Critical、3-Major 、4-Minor 1、 Blocker即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。 2、Critical 即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。 3、3、 Major 即界面、性能缺陷、兼容性。 4、 Minor 即易用性及建议性问题。
二、严重级别的细化
1-Blocker
严重花屏
2-Critical
功能未实现
3-Mቤተ መጻሕፍቲ ባይዱjor
操作界面错误（包括数据窗口内列名定义、含义是否一致）
边界条件下错误提示信息错误（包括未给出信息、信息提示错误等）长时间操作无进度提示系统未优化（性能问题）光标跳转设置不好，鼠标（光标）定位错误
4-Minor
界面格式等不规范
内存泄漏用户数据丢失或破坏系统崩溃/死机/冻结模块无法启动或异常退出严重的数值计算错误

2024年软件资格考试软件评测师(中级)(基础知识、应用技术)合卷试卷及答案指导

2024年软件资格考试软件评测师(基础知识、应用技术)合卷(中级)自测试卷(答案在后面)一、基础知识（客观选择题，75题，每题1分，共75分）1、在软件测试中，下列哪一项不属于黑盒测试方法？A. 等价类划分B. 边界值分析C. 代码审查D. 因果图法2、关于软件质量保证（SQA）与软件测试的关系，以下说法正确的是：A. SQA仅关注于软件开发过程中的测试活动。

B. 软件测试是SQA的一个重要组成部分，但不是全部。

C. SQA的目标是确保软件产品无任何缺陷。

D. 软件测试可以完全替代SQA的作用。

3、以下关于软件测试用例的设计原则，描述错误的是（）。

A. 测试用例应覆盖所有可能的输入值B. 测试用例应具有可追溯性C. 测试用例应具有独立性D. 测试用例应具有可维护性4、在软件开发生命周期（SDLC）中，以下哪个阶段不涉及软件测试活动？（）A. 需求分析阶段B. 设计阶段C. 编码阶段D. 部署阶段5、以下关于软件工程中软件需求规格说明书（SRS）的说法，哪一项是错误的？A、SRS是软件需求分析阶段产生的文档，用于详细描述软件的功能和非功能需求。

B、SRS应具有无歧义性、一致性、可验证性、可理解性等特点。

C、SRS中应包含软件的界面设计、性能需求等详细信息。

D、SRS的编写应由软件开发团队负责，与用户需求无关。

6、在软件测试过程中，以下哪种测试方法主要用于验证软件的兼容性？A、单元测试B、集成测试C、系统测试D、兼容性测试7、下列关于软件测试模型的说法中，哪一项是错误的？A. V模型表示软件开发与测试活动并行进行，强调了测试计划应尽早开始。

B. W模型是在V模型的基础上增加了软件各开发阶段早期的测试概念。

C. H模型指出软件测试是一个独立的过程，贯穿于产品的整个生命周期，与其他过程并发地进行。

D. X模型提出针对完整的程序进行集成编码和测试。

8、在软件测试中，黑盒测试也被称为功能测试，而白盒测试则侧重于结构测试。

第二讲缺陷级别和生命周期(1课时)

软件缺陷--严重性
不同的公司不同的测试规范不同的缺陷级别定义
某公司的软件缺陷级别定义：
Bug实例
1、点击”登录系统”系统未响应 2、点击”登录系统”弹出错误提示：error，但仍可进入 3、按钮”登录系统”中的文字上下居中显示
软件缺陷 –优先级
缺陷优先级：表示修复缺陷的先后次序的指标一般优先级的划分用ABCD或数字1—4表示，A或1表示最高级别，D或4表示最低级别。
fixedduplicatewontfixlater等verified测试人员对状态为resolved的bug进行回归测试时的状态reopen测试人员在进行回归测试时发现问题没有得到解决则将bug的状态修改为reopenclosed关闭bug时标注为closed本节课程内容bug严重性和优先级bug的状态和生命周期jirabugzillabugfree软件缺陷状态三种无效的bugdesign设计需求就是这么设计的duplicate这个问题别人已经发现repro无法复现的问题四种有效的bugfixed问题被修复external外部原因比如浏览器操作系统其他第三方软件造成的问题postponed发现的太晚了下一个版本讨论是否解决wontfix是个问题但是不值得修复bug的七种解决方案缺陷状态描述active活动bug的初始状态
Bug的七种解决方案
By Design 设计需求就是这么设计的这个问题别人已经发现
三种无效的Bug Duplicate Not Repro
Fixed 四种有效的Bug External Postponed Won’t Fix
无法复现的问题
问题被修复外部原因(比如浏览器、操作系统、其他第三方软件)造成的问题发现的太晚了，下一个版本讨论是否解决是个问题，但是不值得修复

软件缺陷分类标准

草稿终稿公开秘密机密绝密受控不受控文档修改记录*S – START A - ADDED M - MODIFIED D - DELETED目录1 引言 ................................................................... 错误!未定义书签。

1.1 编写目的........................................................... 错误!未定义书签。

1.2 定义与缩写......................................................... 错误!未定义书签。

1.3 参考资料........................................................... 错误!未定义书签。

2 软件缺陷分类标准 ....................................................... 错误!未定义书签。

2.1 缺陷属性........................................................... 错误!未定义书签。

2.2 缺陷类型........................................................... 错误!未定义书签。

2.3 缺陷严重限度....................................................... 错误!未定义书签。

2.4 缺陷优先级......................................................... 错误!未定义书签。

2.5 缺陷状态........................................................... 错误!未定义书签。

软件测试__缺陷类型划分

缺陷（BUG）类型划分1简介1.1目的本文档的目的是为同行评审、软件测试提供缺陷分类的标准1.2范围本文档适用于软件项目的软件测试活动及同行评审活动1.3 对象测试工程师、质量工程师1.4 术语1、软件缺陷对软件产品预期属性的偏离，包括内部测试缺陷和遗留缺陷2、内部测试缺陷软件进入用户使用前被检测出来的缺陷3、遗留缺陷（1）软件进入用户测试阶段，用户检测出的缺陷（2）软件发布使用后，用户检测出的缺陷2缺陷分类标准2.1缺陷属性2.2缺陷类型本文按照目前web应用测试软件缺陷的特征进行分类，结合部门产品，简要描述各类缺陷的情况2.3缺陷严重性2.4缺陷优先级2.5缺陷状态（1）TD中的缺陷状态（2）excel中的缺陷状态2.6缺陷起源2.7缺陷来源2.8缺陷根源3缺陷状态的处理过程教你如何用WORD文档(2012-06-27 192246)转载▼标签：杂谈1. 问：WORD 里边怎样设置每页不同的页眉？如何使不同的章节显示的页眉不同？答：分节，每节可以设置不同的页眉。

文件――页面设置――版式――页眉和页脚――首页不同。

2. 问：请问word 中怎样让每一章用不同的页眉？怎么我现在只能用一个页眉，一改就全部改了？答：在插入分隔符里，选插入分节符，可以选连续的那个，然后下一页改页眉前，按一下“同前”钮，再做的改动就不影响前面的了。

简言之，分节符使得它们独立了。

这个工具栏上的“同前”按钮就显示在工具栏上，不过是图标的形式，把光标移到上面就显示出”同前“两个字来。

3. 问：如何合并两个WORD 文档，不同的页眉需要先写两个文件，然后合并，如何做？答：页眉设置中，选择奇偶页不同与前不同等选项。

4. 问：WORD 编辑页眉设置，如何实现奇偶页不同比如：单页浙江大学学位论文，这一个容易设；双页：（每章标题），这一个有什么技巧啊？答：插入节分隔符，与前节设置相同去掉，再设置奇偶页不同。

5. 问：怎样使WORD 文档只有第一页没有页眉，页脚？答：页面设置－页眉和页脚，选首页不同，然后选中首页页眉中的小箭头，格式－边框和底纹，选择无，这个只要在“视图”――“页眉页脚”，其中的页面设置里，不要整个文档，就可以看到一个“同前”的标志，不选，前后的设置情况就不同了。

缺陷划分规划

缺陷划分规划为了在各项目中后期能对各项目质量做比较全面合理的评估，本次缺陷管理过程中定义了比较充分的质量评估考察点，将缺陷进行了多角度划分，下面将各划分方法一一列出。

1.1缺陷（defect）与错误的严重级别（severity）定义问题性质QC中级别概要描述详细描述致命性问题5-Urgent（紧急）引起系统数据错误、操作不能继续进行、死机、系统崩溃等问题；系统崩溃造成系统宕机应用系统停止工作导致程序异常退出的错误4-Very High（非常高）应用程序不能正常运行\窗口打开异常\死循环\数据被破坏资源泄露严重性明显功能性问题3-High（高）功能不能正常完成或完成有误的问题主要功能未正常实现功能执行错误弹出系统异常告警性问题2-Medium（中）功能完成正常，但由于非正常操作而引起系统提示警告，属于系统健壮性问题；系统容错处理异常输入框没有按照约定进行数据约束窗口没有按照既定规定处理没有合理弹出应用异常处理（正常提示）建议性问题1-Low（低）不影响目前系统的使用，但可进行进一步完善和优化，是测试人员提出的优化建议；界面文字拼音错误；不影响目前系统的使用，但可进行进一步完善和优化，是测试人员提出的优化建议；1.2缺陷（defect）的状态（status）定义优先级别描述New（新建）测试中新报告的软件缺陷Open（打开）被确认并分配给相关开发人员处理Fixed（已修复）开发人员已完成修正，等待测试人员验证Reopen（重新打开）对开发人员已修复的缺陷，经回归测试后发现问题仍然存在Rejected（已否决）拒绝修改此缺陷，但要说明拒绝理由Postponed（延迟修改）不在当前版本修复的错误，下一版修复Closed（已关闭）缺陷已被成功修复1.3缺陷（defect）的优先级（priority）定义优先级别描述5-Urgent（紧急）高优先级，马上响应，对于紧急需要处理的问题。

一般要求2小时内必须要求开发组做出响应。

试述软件缺陷的严重性与优先级

试述软件缺陷的严重性与优先级作者：陈顺来源：《无线互联科技》2013年第08期摘要：严重性和优先级是软件缺陷的两个重要属性，在软件测试过程中如果对两者的概念、划分方法和关联性理解的不够准确，不但对缺陷的统计结果、缺陷报告的质量造成影响，而且还会延误软件的正常发布期限。

本文就如何正确区分和处理缺陷的严重性和优先级展开讨论，旨在提高软件质量、降低研发风险。

关键词：软件测试；缺陷；严重性；优先级缺陷的严重性是指缺陷对被测试系统造成的破坏程度的大小，这种破坏既包括缺陷对被测系统的影响程度，也包括缺陷妨碍系统使用的程度。

在软件测试中，判断缺陷的严重性应该从软件最终用户的角度出发，评估缺陷给用户造成的恶劣后果和产生的损失。

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

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

1 四种错误和轻重缓急1.1 判断缺陷的4种错误正确处理和区分缺陷的严重性和优先级，是包括软件测试人员和开发人员在内的全体项目组成员的一件大事，对于经验不很丰富的项目组成员来说，经常会犯下述4种错误：①把低严重性的缺陷当作高严重性来处理。

②把高严重性的缺陷当作低严重性来处理。

③把低优先级的缺陷当作高优先级来处理。

④把高优先级的缺陷当作低优先级来处理。

在此，可以将这4种错误归结为2类，在测试工作中，犯了前2种错误说明在缺陷的判断上“不分轻重”，出现后2种错误则表示在缺陷的判断上“不分缓急”。

如果要在测试工作中准确判断缺陷的严重性与优先级，应该合理区分轻重缓急，这既是保证软件质量的重要环节，也是项目组成员能力与经验的最好体现。

1.2 何为缺陷的轻重缓急现代管理学之父彼得·德鲁克说过：“做事情必须分清轻重缓急。

缺陷严重级程度与优先级别

2严重的逻辑错误
3常用操作平台不能正常使用功能(WIN XP/WIN 2000/WIN VISTA)
4常用浏览器不能正常使用（IE6.0/IE7.0/FireFox）
5超时限制的时间设置不合理
6未登录即可浏览页面
7给客户演示等过程中客户重点指出的，严重级别却不是很高的BUG,建议级别定义至少是非常高
6模块提供的数据不合理，例如(查询“录入人”的下拉项提示为非用户名字段)
7负载,基本功能不能完整使用例如:
1.功能不符
2.程序接口错误
3.数据流错误
4.轻微数据计算错误等
高
1快捷方式不正确，如能够回车直接进入下一步的设计成了空格直接进入下一步
一般
操作性错误、错误结果、遗漏功能等影响系统要求或基本功能的实现,例如:
1.界面错误（附详细说明）
2.打印内容、格式错误
3.简单的输入限制未放在前台进行控制
4.删除操作未给出提示
5.数据输入没有边界值限定或不合理
中
1提示信息不明确，并且非常容易误导用户做出错误操作或判断。
2软件功能的实现过程中弹出未控制的系统错误提示，导致流程中断
低
1提示信息不明确，不正确或不合理
2界面设计存在缺陷、凌乱或不友好
3整体风格不统一
4虽有不尽人意之处，但不影响用户操作或用户使用频率较低，并且不会造成错误
5局部界面不够美观
建议
建议,不影响使用的瑕疵或更好的实现等
对软件各方面提出的更好的改进性的意见。
缺陷严重级程度与优先级别，在填写缺陷选择这两项时，可先参照该对照表：
缺陷严重程度
缺陷严重程度描述
缺陷优先级
缺陷优先级描述
致命
阻碍流程、系统崩溃导致重大任务不能正常进行的缺陷,例如:

缺陷严重级别的定义

从用户角度：
个别功能使用不够方便，但是不影响用户使用的问题
1、用户界面不太友好；
2、使用不习惯；
3、好的操作建议等；
BUG优先级
解决时限
说明
P1
最高优先级，BUG必须马上修复
P2
次高优先级，必须马上修复，或在下一版本前修复
P3
按照项目正常进度解决，（建议在下一个Alpha版本前修改）
如果项目一个Build版本与Alpha版本对应，则无区分，按照项目Bug解决计划执行
1、BUG的严重级别表明BUG的破坏和影响程度；
2、BUG的优先级表明BUG解决的紧急程度；
严重级别
状态描述
举例
Blocks
（致命）
致命错误：
a：导致运行中断(应用程序崩溃)、预期的功能没有得到实现、测试工作无法继续进行等。
b：由于程序引起的非法死机，退出，数据丢失，主要功能完全丧失，系统悬挂等错误。
3、界面显示不美观但对用户不产生影响的问题；
4、不经常出现而且用户可恢复的非严重问题，
5、辅助说明描述不清楚
6、操作时未给用户提示
7、可输入区域和只读区域没有明显的区分标志
8、个别不影响产品理解的错别字
9、文字排列不整齐等一些小问题
Trivial
（建议性）
建议性意见：
从使用者角度，提出的建议性意见。
2、客户环境本身没有问题的情况下，网络不稳，频繁断线，掉线
3、实现的功能与相关需求严重不符，
4、功能未实现
5、功能错误
6、系统刷新错误
7、语音或数据通讯错误
8、轻微的数值计算错误
9、系统所提供的功能或服务受到明显的影响
Major
（一般性错误）

软件缺陷的分布规律

软件缺陷的分布规律
软件缺陷的分布规律如下：
一旦发现软件缺陷，就要设法找到引起这个缺陷的原因，分析对产品质量的影响，然后确定软件缺陷的严重性和处理这个缺陷的优先级。

各种缺陷所造成的后果是不一样的，有的仅仅是不方便，有的可能是灾难性的。

一般问题越严重，其处理优先级就越高，可以概括为以下四种级别：
（1）微小的（Minor）。

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

（2）一般的（Major）。

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

（3）严重的（Critical）。

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

（4）致命的（Fatal）。

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

除了严重性之外，还存在反映软件缺陷处于一种什么样的状态，以便于及时跟踪和管理，下面是不同的缺陷状态。

激活状态（Open）：问题没有解决，测试人员新报告的缺陷或者验证后缺陷仍旧存在。

已修正状态（Fixed）：开发人员针对缺陷，修正软件后已解决问题或通过单元测试。

关闭状态（Close）：测试人员经过验证后，确认缺陷不存在之后的状态。

以上是三种基本的状态，还有一些是需要相应的状态描述，如“保留”，“不一致”状态等。