缺陷的严重性和优先级
关于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.尽量使用业界惯用的表达术语和表达方法使用业界惯用的表达术语和表达方法,保证表达准确,体现专业化。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
•
本地化世界网
严重性和优先级是表征软件测试缺陷的两个重要因素,它影响软件缺陷的统计结果和修正缺陷的优先顺序,特别在软件测试的后期,将影响软件是否能够按期发布与否。
对于软件测试初学者而言,或者没有软件开发经验的测试工程师,对于这两个概念的理解,对于它们的作用和处理方式往往理解的不彻底,实际测试工作中不能正确表示缺陷的严重性和优先级。
这将影响软件缺陷报告的质量,不利于尽早处理严重的软件缺陷,可能影响软件缺陷的处理时机。
什么是缺陷的严重性和优先级
严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度,即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。
在软件测试中,软件缺陷的严重性的判断应该从软件最终用户的观点做出判断,即判断缺陷的严重性要为用户考虑,考虑缺陷对用户使用造成的恶劣后果的严重性。
优先级是表示处理和修正软件缺陷的先后顺序的指标,即哪些缺陷需要优先修正,哪些缺陷可以稍后修正。
确定软件缺陷优先级,更多的是站在软件开发工程师的角度考虑问题,因为缺陷的修正顺序是个复杂的过程,有些不是纯粹技术问题,而且开发人员更熟悉软件代码,能够比测试工程师更清楚修正缺陷的难度和风险。
缺陷的严重性和优先级的关系
缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。
它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。
一般地,严重性程度高的软件缺陷具有较高的优先级。
严重性高说明缺陷对软件造成的质量危害性大,需要优先处理,而严重性低的缺陷可能只是软件不太尽善尽美,可以稍后处理。
但是,严重性和优先级并不总是一一对应。
有时候严重性高的软件缺陷,优先级不一定高,甚至不需要处理,而一些严重性低的缺陷却需要及时处理,具有较高的优先级。
修正软件缺陷不是一件纯技术问题,有时需要综合考虑市场发布和质量风险等问题。
例如,如果某个严重的软件缺陷只在非常极端的条件下产生,则没有必要马上解决。
另外,如果修正一个软件缺陷,需要重新修改软件的整体架构,可能会产生更多潜在的缺陷,而且软件由于市场的压力必须尽快发布,此时即使缺陷的严重性很高,是否需要修正,需要全盘考虑。
另一方面,如果软件缺陷的严重性很低,例如,界面单词拼写错误,但是如果是软件名称或公司名称的拼写错误,则必须尽快修正,因为这关系到软件和公司的市场形象。
处理缺陷的严重性和优先级的常见错误
正确处理缺陷的严重性和优先级不是件非常容易的事情,对于经验不很丰富的测试和开发人员而言,经常犯的错误有以下集中情形:
第一,将比较轻微的缺陷报告成较高级别的缺陷和高优先级,夸大缺陷的严重程度,经常给人“狼来了”的错觉,将影响软件质量的正确评估,也耗费开发人员辨别和处理缺陷的时间。
第二,将很严重的缺陷报告成轻微缺陷和低优先级,这样可能掩盖了很多严重的缺陷。
如果在项目发布前,发现还有很多由于不正确分配优先级造成的严重缺陷,将需要投入很多人力和时间进行修正,影响软件的正常发布。
或者这些严重的缺陷成了“漏网之鱼”,随软件一起发布出去,影响软件的质量和用户的使用信心。
因此,正确处理和区分缺陷的严重性和优先级,是软件测试人员和开发人员,以及全体项目组人员的一件大事。
处理严重性和优先级,既是一种经验技术,也是保证软件质量的重要环节,应该引起足够的重视。
如何表示缺陷的严重性和优先级
缺陷的严重性和优先级通常按照级别划分,各个公司和不同项目的具体表示方式有所不同。
为了尽量准确的表示缺陷信息,通常将缺陷的严重性和优先级分成4级。
如果分级超过4级,则造成分类和判断尺度的复杂程度,而少于4级,精确性有时不能保证。
具体的表示方法机可以使用数字表示,也可以使用文字表示,还可以数字和文字综合表示。
使用数字表示通常按照从高到底或从低到高的顺序,需要软件测试前达成一致。
例如,使用数字1,2,3,4分别表示轻微、一般、较严重和非常严重的严重性。
对于优先级而言,1,2,3,4可以分标表示低优先级、一般、较高优先级和最高优先级。
如何确定缺陷的严重性和优先级
通常由软件测试人员确定缺陷的严重性,由软件开发人员确定优先级较为适当。
但是,实际测试中,通常都是由软件测试人员在缺陷报告中同时确定严重性和优先级。
确定缺陷的严重性和优先级要全面了解和深刻体会缺陷的特征,从用户和开发人员以及市场的因素综合考虑。
通常功能性的缺陷较为严重,具有较高的优先级,而软件界面类缺陷的严重性一般较低,优先级也较低。
对于缺陷的严重性,如果分为4级,则可以参考下面的方法确定:
1 —非常严重的缺陷,例如,软件的意外退出甚至操作系统崩溃,造成数据丢失。
2 —较严重的缺陷,例如,软件的某个菜单不起作用或者产生错误的结果;
3 - 软件一般缺陷,例如,本地化软件的某些字符没有翻译或者翻译不准确;
4 - 软件界面的细微缺陷,例如,某个控件没有对齐,某个标点符号丢失等;
对于缺陷的优先性,如果分为4级,则可以参考下面的方法确定:
1 —最高优先级,例如,软件的主要功能错误或者造成软件崩溃,数据丢失的缺陷。
2 —较高优先级,例如,影响软件功能和性能的一般缺陷;
3 -一般优先级,例如,本地化软件的某些字符没有翻译或者翻译不准确的缺陷;
4 —低优先级,例如,对软件的质量影响非常轻微或出现几率很低的缺陷;
其他注意事项
比较规范的软件测试,使用软件缺陷管理数据库进行缺陷报告和处理,需要在测试项目开始前对全体测试人员和开发人员进行培训,对缺陷严重性和优先级的表示和划分方法统一规定和遵守。
在测试项目进行过程中和项目接收后,充分利用统计功能统计缺陷的严重性,确定软件模块的开发质量,评估软件项目实施进度。
统计优先级的分布情况,控制开发进度,使开发按照项目尽快进行,有效处理缺陷,降低风险和成本。
为了保证报告缺陷的严重性和优先级的一致性,质量保证人员需要经常检查测试和开发人员对于这两个指标的分配和处理情况,发现问题,及时反馈给项目负责人,及时解决。
对于测试人员而言,通常经验丰富的人员可以正确的表示缺陷的严重性和优先级,为缺陷的及时处理提供准确的信息。
对于开发人员来说,开发经验丰富的人员严重缺陷的错误较少,但是不要将缺陷的严重性作为衡量其开发水平高低的主要判断指标,因为软件的模块的开发难度不同,各个模块的质量要求也有所差异。