严重性和优先级是表征软件测试缺陷的两个重要因素,它影响软件缺陷的统计结果和修正缺陷的优先顺序,特别在软件测试的后期,将影响软件是否能够按期发布与否。
严重性(Severity):顾名思义就是软件缺陷对软件质量的破坏程度,即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。
优先级:是表示处理和修正软件缺陷的先后顺序的指标,即哪些缺陷需要优先修正,哪些缺陷可以稍后修正。
一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?
1.和BUG对应的软件版本
2.开发的借口人员,测试人员
3.BUG的优先级
4.BUG的严重程度
5.BUG可能属于的模块
6.BUG的标题
7.BUG的描述
8.BUG的截图
9.BUG的状态
10.BUG的错误类型(数据,界面。。。。)
软件缺陷的优先级
严重性和优先级是表征软件测试缺陷的两个重要因素,它影响软件缺陷的统计结果和修正缺陷的优先顺序,特别在软件测试的后期,将影响软件是否能够按期发布与否。
对于软件测试初学者而言,或者没有软件开发经验的测试工程师,对于这两个概念的理解,对于它们的作用和处理方式往往理解的不彻底,实际测试工作中不能正确表示缺陷的严重性和优先级。这将影响软件缺陷报告的质量,不利于尽早处理严重的软件缺陷,可能影响软件缺陷的处理时机。
什么是缺陷的严重性和优先级
严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度,即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。
在软件测试中,软件缺陷的严重性的判断应该从软件最终用户的观点做出判断,即判断缺陷的严重性要为用户考虑,考虑缺陷对用户使用造成的恶劣后果的严重性。
优先级是表示处理和修正软件缺陷的先后顺序的指标,即哪些缺陷需要优先修正,哪些缺陷可以稍后修正。
确定软件缺陷优先级,更多的是站在软件开发工程师的角度考虑问题,因为缺陷的修正顺序是个复杂的过程,有些不是纯粹技术问题,而且开发人员更熟悉软件代码,能够比测试工程师更清楚修正缺陷的难度和风险。
缺陷的严重性和优先级的关系
缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。
一般地,严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大,需要优先处理,而严重性低的缺陷可能只是软件不太尽善尽美,可以稍后处理。
但是,严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷,优先级不一定高,甚至不需要处理,而一些严重性低的缺陷却需要及时处理,具有较高的优先级。
修正软件缺陷不是一件纯技术问题,有时需要综合考虑市场发布和质量风险等问题。例如,如果某个严重的软件缺陷只在非常极端的条件下产生,则没有必要马上解决。另外,如果修正一个软件缺陷,需要重新修改软件的整体架构,可能会产生更多潜在的缺陷,而且软件由于市场的压力必须尽快发布,此时即使缺陷的严重性很高,是否需要修正,需要全盘考虑。
另一方面,如果软件缺陷的严重性很低,例如,界面单词拼写错误,但是如果是软件名称或公司名称的拼写错误,则必须尽快修正,因为这关系到软件和公司的市场形象。
处理缺陷的严重性和优先级的常见错误
正确处理缺陷的严重性和优先级不是件非常容易的事情,对于经验不是很丰富的测试和开发人员而言,经常犯的错误有以下几种情形:
第一,将比较轻微的缺陷报告成较高级别的缺陷和高优先级,夸大缺陷的严重程度,经常给人“狼来了”的错觉,将影响软件质量的正确评估,也耗费开发人员辨别和处理缺陷的时间。
第二,将很严重的缺陷报告成轻微缺陷和低优先级,这样可能掩盖了很多严重的缺陷。如果在项目发布前,发现还有很多由于不正确分配优先级造成的严重缺陷,将需要投入很多人力和时间进行修正,影响软件的正常发布。或者这些严重的缺陷成了“漏网之鱼”,随软件一起发布出去,影响软件的质量和用户的使用信心。
因此,正确处理和区分缺陷的严重性和优先级,是软件测试人员和开发人员,以及全体项目组人员的一件大事。处理严重性和优先级,既是一种经验技术,也是保证软件质量的重要环节,应该引起足够的重视。
如何表示缺陷的严重性和优先级
缺陷的严重性和优先级通常按照级别划分,各个公司和不同项目的具体表示方式有所不同。
为了尽量准确的表示缺陷信息,通常将缺陷的严重性和优先级分成4级。如果分级超过4级,则造成分类和判断尺度的复杂程度,而少于4级,精确性有时不能保证。
具体的表示方法机可以使用数字表示,也可以使用文字表示,还可以数字和文字综合表示。使用数字表示通常按照从高到底或从低到高的顺序,需要软件测试前达成一致。例如,使用数字1,2,3,4分别表示轻微、一般、较严重和非常严重的严重性。对于优先级而言,1,2,3,4可以分标表示低优先级、一般、较高优先级和最高优先级。
如何确定缺陷的严重性和优先级
通常由软件测试人员确定缺陷的严重性,由软件开发人员确定优先级较为适当。但是,实际测试中,通常都是由软件测试人员在缺陷报告中同时确定严重性和优先级。
确定缺陷的严重性和优先级要全面了解和深刻体会缺陷的特征,从用户和开发人员以及市场的因素综合考虑。通常功能性的缺陷较为严重,具有较高的优先级,而软件界面类缺陷的严重性一般较低,优先级也较低。
对于缺陷的严重性,如果分为4级,则可以参考下面的方法确定:
1 – 非常严重的缺陷,例如,软件的意外退出甚至操作系统崩溃,造成数据丢失。 2 – 较严重的缺陷,例如,软件的某个菜单不起作用或者产生错误的结果; 3 - 软件一般缺陷,例如,本地化软件的某些字符没有翻译或者翻译不准确; 4 -软件界面的细微缺陷,例如,某个控件没有对齐,某个标点符号丢失等;
对于缺陷的优先性,如果分为4级,则可以参考下面的方法确定:
1 –最高优先级,例如,软件的主要功能错误或者造成软件崩溃,数据丢失的缺陷。 2 – 较高优先级,例如,影响软件功能和性能的一般缺陷; 3 -一般优先级,例如,本地化软件的某些字符没有翻译或者翻译不准确的缺陷; 4 – 低优先级,例如,对软件的质量影响非常轻微或出现几率很低的缺陷;
其他注意事项
比较规范的软件测试,使用软件缺陷管理数据库进行缺陷报告和处理,需要在测试项目开始前对全体测试人员和开发人员进行培训,对缺陷严重性和优先级的表示和划分方法统一规定和遵守。
在测试项目进行过程中和项目接收后,充分利用统计功能统计缺陷的严重性,确定软件模块的开发质量,评估软件项目实施进度。统计优先级的分布情况,控制开发进度,使开发按照项目尽快进行,有效处理缺陷,降低风险和成本。
为了保证报告缺陷的严重性和优先级的一致性,质量保证人员需要经常检查测试和开发人员对于这两个指标的分配和处理情况,发现问题,及时反馈给项目负责人,及时解决。
对于测试人员而言,通常经验丰富的人员可以正确的表示缺陷的严重性和优先级,为缺陷的及时处理提供准确的信息。对于开发人员来说,开发经验丰富的人员严重缺陷的错误较少,但是不要将缺陷的严重性作为衡量其开发水平高低的主要判断指标,因为软件的模块的开发难度不同,各个模块的质量要求也有所差异。
软件缺陷怎么描述
认识软件缺陷,首先要了解软件缺陷的概念,其次是了解软件缺陷的详细特征,最后就是它的属性了,再高一个层次就是学习利用管理软件缺陷的工具了。 1、首先介绍软件缺陷的概念
软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。 2、软件缺陷的详细特征 a、单一准确
b、可以再现(要求软件缺陷具有精确的步骤) c、完整统一 d、短小简练 e、特定条件 f、补充完整 g、不做评价
3、软件缺陷的属性
软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。 下面详细介绍一下以上这些属性:
a、缺陷标识:是标记某个缺陷的唯一标识,可以用数字序号表示; b、缺陷类型:功能、用户界面、文档、软件包、性能、系统\模块接口 功能:影响了各种系统功能、逻辑的缺陷;
用户界面:影响了用户界面、人机交互特性,包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷;
文档:影响发布和维护,包括注释、用户手册、设计文档; 软件包:由于软件配置库、变更管理或版本控制引起的错误;
性能:不满足系统可测量的属性值,如执行时间、事务处理速率等; 系统\模块接口:与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。
c、缺陷严重程度:致命(Fatal)、严重(Ceritical)、一般(Major)、较小(Minor)
致命:系统任何一个主要功能完全丧失,用户数据受到破坏,系统崩溃、悬挂、死机或者危机人身安全; 严重:系统的主要功能部分丧失,数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显的影响;
一般:系统的次要功能没有完全实现,但不影响用户的正常使用。例如:提示信息不太准确或用户界面差、操作时间长等一些问题;
较小:使操作者不方便或遇到麻烦,但它不影响功能过的操作和执行,如个别不影响产品理解的错别字、文字排列不整齐等一些小问题 d、缺陷产生可能性:总是、通常、有时、很少
总是:总是产生这个软件缺陷,其产生的频率是100%;
通常:按照测试用例,通常情况下会产生这个软件缺陷,其产生的频率大概是80%—90%;
有时:按照测试用例,有时候产生这个软件缺陷,其产生的频率大概是30%—50%;
如何提交高质量的软件缺陷记录
1) 通用UI要统一、准确
缺陷报告的UI要与测试的软件UI保持一致,便于查找定位。
2) 尽量使用业界惯用的表达术语和表达方法
使用业界惯用的表达术语和表达方法,保证表达准确,体现专业化。
3) 每条缺陷报告只包括一个缺陷
每条缺陷报告只包括一个缺陷,可以使缺陷修正者迅速定位一个缺陷,集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。
4) 不可重现的缺陷也要报告
首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现,若尽力之后仍不能重现,仍然要报告此缺陷,但在报告中要注明无法再现,缺陷出现的频率。
5) 明确指明缺陷类型
根据缺陷的现象,总结判断缺陷的类型。例如,即功能缺陷、界面缺陷、数据缺陷,合理化建议这是最常见的缺陷或缺陷类型,其他形式的缺陷或缺陷也从属于其中某种形式。
6) 明确指明缺陷严重等级和优先等级
时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决,小装饰性问题可能被当作高优先级。
7) 描述 (Description) ,简洁、准确,完整,揭示缺陷实质,记录缺陷或缺陷出现的位置
描述要准确反映缺陷的本质内容,简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷,包含缺陷发生时的用户界面(UI)是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。
8) 短行之间使用自动数字序号,使用相同的字体、字号、行间距
短行之间使用自动数字序号,使用相同的字体、字号、行间距,可以保证各条记录格式一致,做到规范专业。
9) 每一个步骤尽量只记录一个操作
保证简洁、条理井然,容易重复操作步骤。
10) 确认步骤完整,准确,简短
保证快速准确的重复缺陷,“完整”即没有缺漏,“准确”即步骤正确,“简短”即没有多余的步骤。
11) 根据缺陷,可选择是否进行图象捕捉
为了直观的观察缺陷或缺陷现象,通常需要附加缺陷或缺陷出现的界面,以图片的形式作为附件附着在记录的“附件”部分。为了节省空间,又能真实反映缺陷或缺陷本质,可以捕捉缺陷或缺陷产生时的全屏幕,活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置,通常要求附加中文对照图。
附加必要的特殊文档和个人建议和注解
如果打开某个特殊的文档而产生的缺陷或缺陷,则必须附加该文档,从而可以迅速再现缺陷或缺陷。有时,为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现,可以附加个人的修改建议或注解。
12) 检查拼写和语法缺陷
在提交每条缺陷或缺陷之前,检查拼写和语法,确保内容正确,正确的描述缺陷。
13) 尽量使用短语和短句,避免复杂句型句式
软件缺陷管理数据库的目的是便于定位缺陷,因此,要求客观的描述操作步骤,不需要修饰性的词汇和复杂的句型,增强可读性。
以上概括了报告测试缺陷的规范要求,随着软件的测试要求不同,测试者经过长期测试,积累了相应的测试经验,将会逐渐养成良好的专业习惯,不断补充新的规范书写要求。此外,经常阅读、学习其他测试工程师的测试缺陷报告,结合自己以前的测试缺陷报告进行对比和思考,可以不断提高技巧。
14) 缺陷描述内容
缺陷描述的内容可以包含缺陷操作步骤,实际结果和期望结果。操作步骤可以方便开发人员再现缺陷进行修正,有些开发的再现缺陷能力很差,虽然他明白你所指的缺陷,但就是无法再现特别是对系统不熟悉的新加入开发人员,介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么,期望结果可以让开发了解正确的结果应该是如何。
软件缺陷的产生原因
在软件开发的过程中,软件缺陷的产生是不可避免的。那么造成软件缺陷的主要原因有哪些?从软件本身、团队工作和技术问题等角度分析,就可以了解造成软件缺陷的主要因素。
软件缺陷的产生主要是由软件产品的特点和开发过程决定的。 1.需求不清晰,导致设计目标偏离客户的需求,从而引起功能或产品特征上的缺陷。
2.系统结构非常复杂,而又无法设计成一个很好的层次结构或组件结构,结果导致意想不到的问题或系统维护、扩充上的困难;即使设计成良好的面向对象的系统,由于对象、类太多,很难完成对各种对象、类相互作用的组合测试,而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。
3.对程序逻辑路径或数据范围的边界考虑不够周全,漏掉某些边界条件,造成容量或边界错误。
4.对一些实时应用,要进行精心设计和技术处理,保证精确的时间同步,否则容易引起时间上不协调,不一致性带来的问题。
5.没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题,从而存在系统安全性、可靠性的隐患。
6.系统运行环境的复杂,不仅用户使用的计算机环境千变万化,包括用户的各种操作方式或各种不同的输入数据,容易引起一些特定用户环境下的问题;在系统实际应用中,数据量很大。从而会引起强度或负载问题。
7.由于通信端口多、存取和加密手段的矛盾性等,会造成系统的安全性或适用性等问题。
8.新技术的采用,可能涉及技术或系统兼容的问题,事先没有考虑到。 1.系统需求分析时对客户的需求理解不清楚,或者和用户的沟通存在一些困难。
2.不同阶段的开发人员相互理解不一致。例如,软件设计人员对需求分析的理解有偏差,编程人员对系统设计规格说明书某些内容重视不够,或存在误解。
3.对于设计或编程上的一些假定或依赖性,相关人员没有充分沟通。
4.项目组成员技术水平参差不齐,新员工较多,或培训不够等原因也容易引起问题。 1.算法错误:在给定条件下没能给出正确或准确的结果。
2.语法错误:对于编译性语言程序,编译器可以发现这类问题;但对于解释性语言程序,只能在测试运行时发现。
3.计算和精度问题:计算的结果没有满足所需要的精度。
4.系统结构不合理、算法选择不科学,造成系统性能低下。
5.接口参数传递不匹配,导致模块集成出现问题。 1.缺乏质量文化,不重视质量计划,对质量、资源、任务、成本等的平衡性把握不好,容易挤掉需求分析、评审、测试、等时间,遗留的缺陷会比较多。
2.系统分析时对客户的需求不是十分清楚,或者和用户的沟通存在一些困难。
3.开发周期短,需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进行,工作不够充分,结果也就不完整、不准确,错误较多;周期短,还给各类开发人员造成太大的压力,引起一些人为的错误。
4.开发流程不够完善,存在太多的随机性和缺乏严谨的内审或评审机制,容易产生问题。
5.文档不完善,风险估计不足等。
转载请注明出处51数据库 » 严重的软件缺陷的 软件缺陷的严重性和优先级是什么