缺陷的严重性和优先级
- 格式:doc
- 大小:20.50 KB
- 文档页数:3
关于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(接受):经过缺陷评审委员会的确认,认为缺陷确实存在。
BUG等级划分方法一、四级的划分方式:1.BUG等级划分建议:目前project上的BUG严重程度分为五个等级,按照CMM5中定义的规范,BUG严重等级可分为3-5个等级,由于我们公司的CMM水平还处于初级阶段,将BUG等级划分过细不符合我们当前的CMM水平,同时也不利于测试人员对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.尽量使用业界惯用的表达术语和表达方法使用业界惯用的表达术语和表达方法,保证表达准确,体现专业化。
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、在软件测试中,黑盒测试也被称为功能测试,而白盒测试则侧重于结构测试。
草稿终稿公开秘密机密绝密受控不受控文档修改记录*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 何为缺陷的轻重缓急现代管理学之父彼得·德鲁克说过:“做事情必须分清轻重缓急。
软件缺陷的分布规律
软件缺陷的分布规律如下:
一旦发现软件缺陷,就要设法找到引起这个缺陷的原因,分析对产品质量的影响,然后确定软件缺陷的严重性和处理这个缺陷的优先级。
各种缺陷所造成的后果是不一样的,有的仅仅是不方便,有的可能是灾难性的。
一般问题越严重,其处理优先级就越高,可以概括为以下四种级别:
(1)微小的(Minor)。
一些小问题如有个别错别字、文字排版不整齐等,对功能几乎没有影响,软件产品仍可使用。
(2)一般的(Major)。
不太严重的错误,如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。
(3)严重的(Critical)。
严重错误,指功能模块或特性没有实现,主要功能部分丧失,次要功能全部丧失,或致命的错误声明。
(4)致命的(Fatal)。
致命的错误,造成系统崩溃、死机,或造成数据丢失、主要功能完全丧失等。
除了严重性之外,还存在反映软件缺陷处于一种什么样的状态,以便于及时跟踪和管理,下面是不同的缺陷状态。
激活状态(Open):问题没有解决,测试人员新报告的缺陷或者验证后缺陷仍旧存在。
已修正状态(Fixed):开发人员针对缺陷,修正软件后已解决问题或通过单元测试。
关闭状态(Close):测试人员经过验证后,确认缺陷不存在之后的状态。
以上是三种基本的状态,还有一些是需要相应的状态描述,如“保留”,“不一致”状态等。
•
本地化世界网
严重性和优先级是表征软件测试缺陷的两个重要因素,它影响软件缺陷的统计结果和修正缺陷的优先顺序,特别在软件测试的后期,将影响软件是否能够按期发布与否。
对于软件测试初学者而言,或者没有软件开发经验的测试工程师,对于这两个概念的理解,对于它们的作用和处理方式往往理解的不彻底,实际测试工作中不能正确表示缺陷的严重性和优先级。
这将影响软件缺陷报告的质量,不利于尽早处理严重的软件缺陷,可能影响软件缺陷的处理时机。
什么是缺陷的严重性和优先级
严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度,即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。
在软件测试中,软件缺陷的严重性的判断应该从软件最终用户的观点做出判断,即判断缺陷的严重性要为用户考虑,考虑缺陷对用户使用造成的恶劣后果的严重性。
优先级是表示处理和修正软件缺陷的先后顺序的指标,即哪些缺陷需要优先修正,哪些缺陷可以稍后修正。
确定软件缺陷优先级,更多的是站在软件开发工程师的角度考虑问题,因为缺陷的修正顺序是个复杂的过程,有些不是纯粹技术问题,而且开发人员更熟悉软件代码,能够比测试工程师更清楚修正缺陷的难度和风险。
缺陷的严重性和优先级的关系
缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。
它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。
一般地,严重性程度高的软件缺陷具有较高的优先级。
严重性高说明缺陷对软件造成的质量危害性大,需要优先处理,而严重性低的缺陷可能只是软件不太尽善尽美,可以稍后处理。
但是,严重性和优先级并不总是一一对应。
有时候严重性高的软件缺陷,优先级不一定高,甚至不需要处理,而一些严重性低的缺陷却需要及时处理,具有较高的优先级。
修正软件缺陷不是一件纯技术问题,有时需要综合考虑市场发布和质量风险等问题。
例如,如果某个严重的软件缺陷只在非常极端的条件下产生,则没有必要马上解决。
另外,如果修正一个软件缺陷,需要重新修改软件的整体架构,可能会产生更多潜在的缺陷,而且软件由于市场的压力必须尽快发布,此时即使缺陷的严重性很高,是否需要修正,需要全盘考虑。
另一方面,如果软件缺陷的严重性很低,例如,界面单词拼写错误,但是如果是软件名称或公司名称的拼写错误,则必须尽快修正,因为这关系到软件和公司的市场形象。
处理缺陷的严重性和优先级的常见错误
正确处理缺陷的严重性和优先级不是件非常容易的事情,对于经验不很丰富的测试和开发人员而言,经常犯的错误有以下集中情形:
第一,将比较轻微的缺陷报告成较高级别的缺陷和高优先级,夸大缺陷的严重程度,经常给人“狼来了”的错觉,将影响软件质量的正确评估,也耗费开发人员辨别和处理缺陷的时间。
第二,将很严重的缺陷报告成轻微缺陷和低优先级,这样可能掩盖了很多严重的缺陷。
如果在项目发布前,发现还有很多由于不正确分配优先级造成的严重缺陷,将需要投入很多人力和时间进行修正,影响软件的正常发布。
或者这些严重的缺陷成了“漏网之鱼”,随软件一起发布出去,影响软件的质量和用户的使用信心。
因此,正确处理和区分缺陷的严重性和优先级,是软件测试人员和开发人员,以及全体项目组人员的一件大事。
处理严重性和优先级,既是一种经验技术,也是保证软件质量的重要环节,应该引起足够的重视。
如何表示缺陷的严重性和优先级
缺陷的严重性和优先级通常按照级别划分,各个公司和不同项目的具体表示方式有所不同。
为了尽量准确的表示缺陷信息,通常将缺陷的严重性和优先级分成4级。
如果分级超过4级,则造成分类和判断尺度的复杂程度,而少于4级,精确性有时不能保证。
具体的表示方法机可以使用数字表示,也可以使用文字表示,还可以数字和文字综合表示。
使用数字表示通常按照从高到底或从低到高的顺序,需要软件测试前达成一致。
例如,使用数字1,2,3,4分别表示轻微、一般、较严重和非常严重的严重性。
对于优先级而言,1,2,3,4可以分标表示低优先级、一般、较高优先级和最高优先级。
如何确定缺陷的严重性和优先级
通常由软件测试人员确定缺陷的严重性,由软件开发人员确定优先级较为适当。
但是,实际测试中,通常都是由软件测试人员在缺陷报告中同时确定严重性和优先级。
确定缺陷的严重性和优先级要全面了解和深刻体会缺陷的特征,从用户和开发人员以及市场的因素综合考虑。
通常功能性的缺陷较为严重,具有较高的优先级,而软件界面类缺陷的严重性一般较低,优先级也较低。
对于缺陷的严重性,如果分为4级,则可以参考下面的方法确定:
1 —非常严重的缺陷,例如,软件的意外退出甚至操作系统崩溃,造成数据丢失。
2 —较严重的缺陷,例如,软件的某个菜单不起作用或者产生错误的结果;
3 - 软件一般缺陷,例如,本地化软件的某些字符没有翻译或者翻译不准确;
4 - 软件界面的细微缺陷,例如,某个控件没有对齐,某个标点符号丢失等;
对于缺陷的优先性,如果分为4级,则可以参考下面的方法确定:
1 —最高优先级,例如,软件的主要功能错误或者造成软件崩溃,数据丢失的缺陷。
2 —较高优先级,例如,影响软件功能和性能的一般缺陷;
3 -一般优先级,例如,本地化软件的某些字符没有翻译或者翻译不准确的缺陷;
4 —低优先级,例如,对软件的质量影响非常轻微或出现几率很低的缺陷;
其他注意事项
比较规范的软件测试,使用软件缺陷管理数据库进行缺陷报告和处理,需要在测试项目开始前对全体测试人员和开发人员进行培训,对缺陷严重性和优先级的表示和划分方法统一规定和遵守。
在测试项目进行过程中和项目接收后,充分利用统计功能统计缺陷的严重性,确定软件模块的开发质量,评估软件项目实施进度。
统计优先级的分布情况,控制开发进度,使开发按照项目尽快进行,有效处理缺陷,降低风险和成本。
为了保证报告缺陷的严重性和优先级的一致性,质量保证人员需要经常检查测试和开发人员对于这两个指标的分配和处理情况,发现问题,及时反馈给项目负责人,及时解决。
对于测试人员而言,通常经验丰富的人员可以正确的表示缺陷的严重性和优先级,为缺陷的及时处理提供准确的信息。
对于开发人员来说,开发经验丰富的人员严重缺陷的错误较少,但是不要将缺陷的严重性作为衡量其开发水平高低的主要判断指标,因为软件的模块的开发难度不同,各个模块的质量要求也有所差异。