软件缺陷的分类标准
1.缺陷标识(Identifier): 缺陷标识是标记某个缺陷的一组符号。
每个缺陷必须有一个唯一的标识。
2.缺陷类型 (Type): 缺陷类型是根据缺陷的自然属性划分的缺陷种类。
3.缺陷严重程度 (Severity) :缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
4.缺陷优先级(Priority): 缺陷的优先级指缺陷必须被修复的紧急程度。
5.缺陷状态(Status) :缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
6.缺陷起源(Origin) :缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。
7.缺陷来源(Source): 缺陷来源指引起缺陷的起因。
8.缺陷根源(Root Cause): 缺陷根源指发生错误的根本因素。
F- Function :影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。
并且设计文档需要正式的变更。
如逻辑,指针,循环,递归,功能等缺陷。
A- Assignment: 需要修改少量代码,如初始化或控制块。
如声明、重复命名,范围、限定等缺陷。
I- Interface: 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
C- Checking: 提示的错误信息,不适当的数据验证等缺陷。
B Build/package/merge :由于配置库、变更管理或版本控制引起的错误。
D- Documentation: 影响发布和维护,包括注释。
G- Algorithm :算法错误。
U-User Interface:人机交互特性:屏幕格式,确认用户输入,功能有效性,页面排版等方面的缺陷。
P-Performance:不满足系统可测量的属性值,如:执行时间,事务处理速率等。
N-Norms:不符合各种标准的要求,如编码标准、设计符号等。
软件测试错误严重程度1.Critical:不能执行正常工作功能或重要功能。
或者危及人身安全。
2.Major:严重地影响系统要求或基本功能的实现,且没有办法更正。
(重新安装或重新启动该软件不属于更正办法)3.Minor:严重地影响系统要求或基本功能的实现,但存在合理的更正办法。
(重新安装或重新启动该软件不属于更正办法)4.Cosmetic:使操作者不方便或遇到麻烦,但它不影响执行工作功能或重要功能。
5.Other:其它错误。
同行评审错误严重程度1.Major:主要的,较大的缺陷2.Minor:次要的,小的缺陷 1.Resolve Immediately:缺陷必须被立即解决。
2.Normal Queue:缺陷需要正常排队等待修复或列入软件发布清单。
3.Not Urgent:缺陷可以在方便时被纠正。
1.Submitted: 已提交的缺陷2.Open :确认“提交的缺陷”,等待处理3.Rejected: 拒绝“提交的缺陷”,不需要修复或不是缺陷4.Resolved :缺陷被修复5.Closed :确认被修复的缺陷,将其关闭 1.Requirement:在需求阶段发现的缺陷2.Architecture:在构架阶段发现的缺陷3.Design:在设计阶段发现的缺陷4.Code:在编码阶段发现的缺陷5.Test:在测试阶段发现的缺陷 1.Requirement: 由于需求的问题引起的缺陷2.Architecture: 由于构架的问题引起的缺陷3.Design: 由于设计的问题引起的缺陷4.Code: 由于编码的问题引起的缺陷5.Test: 由于测试的问题引起的缺陷6.Integration: 由于集成的问题引起的缺陷
软件缺陷的优先级
严重性和优先级是表征软件测试缺陷的两个重要因素,它影响软件缺陷的统计结果和修正缺陷的优先顺序,特别在软件测试的后期,将影响软件是否能够按期发布与否。
对于软件测试初学者而言,或者没有软件开发经验的测试工程师,对于这两个概念的理解,对于它们的作用和处理方式往往理解的不彻底,实际测试工作中不能正确表示缺陷的严重性和优先级。
这将影响软件缺陷报告的质量,不利于尽早处理严重的软件缺陷,可能影响软件缺陷的处理时机。
什么是缺陷的严重性和优先级严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度,即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。
在软件测试中,软件缺陷的严重性的判断应该从软件最终用户的观点做出判断,即判断缺陷的严重性要为用户考虑,考虑缺陷对用户使用造成的恶劣后果的严重性。
优先级是表示处理和修正软件缺陷的先后顺序的指标,即哪些缺陷需要优先修正,哪些缺陷可以稍后修正。
确定软件缺陷优先级,更多的是站在软件开发工程师的角度考虑问题,因为缺陷的修正顺序是个复杂的过程,有些不是纯粹技术问题,而且开发人员更熟悉软件代码,能够比测试工程师更清楚修正缺陷的难度和风险。
缺陷的严重性和优先级的关系缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。
它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。
一般地,严重性程度高的软件缺陷具有较高的优先级。
严重性高说明缺陷对软件造成的质量危害性大,需要优先处理,而严重性低的缺陷可能只是软件不太尽善尽美,可以稍后处理。
但是,严重性和优先级并不总是一一对应。
有时候严重性高的软件缺陷,优先级不一定高,甚至不需要处理,而一些严重性低的缺陷却需要及时处理,具有较高的优先级。
修正软件缺陷不是一件纯技术问题,有时需要综合考虑市场发布和质量风险等问题。
例如,如果某个严重的软件缺陷只在非常极端的条件下产生,则没有必要马上解决。
另外,如果修正一个软件缺陷,需要重新修改软件的整体架构,可能会产生更多潜在的缺陷,而且软件由于市场的压力必须尽快发布,此时即使缺陷的严重性很高,是否需要修正,需要全盘考虑。
另一方面,如果软件缺陷的严重性很低,例如,界面单词拼写错误,但是如果是软件名称或公司名称的拼写错误,则必须尽快修正,因为这关系到软件和公司的市场形象。
处理缺陷的严重性和优先级的常见错误正确处理缺陷的严重性和优先级不是件非常容易的事情,对于经验不是很丰富的测试和开发人员而言,经常犯的错误有以下几种情形:第一,将比较轻微的缺陷报告成较高级别的缺陷和高优先级,夸大缺陷的严重程度,经常给人“狼来了”的错觉,将影响软件质量的正确评估,也耗费开发人员辨别和处理缺陷的时间。
第二,将很严重的缺陷报告成轻微缺陷和低优先级,这样可能掩盖了很多严重的缺陷。
如果在项目发布前,发现还有很多由于不正确分配优先级造成的严重缺陷,将需要投入很多人力和时间进行修正,影响软件的正常发布。
或者这些严重的缺陷成了“漏网之鱼”,随软件一起发布出去,影响软件的质量和用户的使用信心。
因此,正确处理和区分缺陷的严重性和优先级,是软件测试人员和开发人员,以及全体项目组人员的一件大事。
处理严重性和优先级,既是一种经验技术,也是保证软件质量的重要环节,应该引起足够的重视。
如何表示缺陷的严重性和优先级缺陷的严重性和优先级通常按照级别划分,各个公司和不同项目的具体表示方式有所不同。
为了尽量准确的表示缺陷信息,通常将缺陷的严重性和优先级分成4级。
如果分级超过4级,则造成分类和判断尺度的复杂程度,而少于4级,精确性有时不能保证。
具体的表示方法机可以使用数字表示,也可以使用文字表示,还可以数字和文字综合表示。
使用数字表示通常按照从高到底或从低到高的顺序,需要软件测试前达成一致。
例如,使用数字1,2,3,4分别表示轻微、一般、较严重和非常严重的严重性。
对于优先级而言,1,2,3,4可以分标表示低优先级、一般、较高优先级和最高优先级。
如何确定缺陷的严重性和优先级通常由软件测试人员确定缺陷的严重性,由软件开发人员确定优先级较为适当。
但是,实际测试中,通常都是由软件测试人员在缺陷报告中同时确定严重性和优先级。
确定缺陷的严重性和优先级要全面了解和深刻体会缺陷的特征,从用户和开发人员以及市场的因素综合考虑。
通常功能性的缺陷较为严重,具有较高的优先级,而软件界面类缺陷的严重性一般较低,优先级也较低。
对于缺陷的严重性,如果分为4级,则可以参考下面的方法确定:1 – 非常严重的缺陷,例如,软件的意外退出甚至操作系统崩溃,造成数据丢失。
2 – 较严重的缺陷,例如,软件的某个菜单不起作用或者产生错误的结果; 3 - 软件一般缺陷,例如,本地化软件的某些字符没有翻译或者翻译不准确; 4 -软件界面的细微缺陷,例如,某个控件没有对齐,某个标点符号丢失等;对于缺陷的优先性,如果分为4级,则可以参考下面的方法确定:1 –最高优先级,例如,...
一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量...
缺陷管理的作用在于,一是记录以便以后满足统计分析等需要,二是有助于重现问题以便定位及解决问题。
从这个角度出发,缺陷报告自然是能够记录越多的细节越好,包括测试环境、软件版本、所用工具及版本号、测试用例的信息、出错前所执行的操作步骤、出错时相关信息和日志,等等很多。
但是要真正做到捕获的都是有用的信息是非常困难的,因为我们只能从故障现象入手去记录相关信息,而问题的根源可能与之相隔甚远,来回折腾其实是非常耗时、耗资源的。
最好的办法就是发现问题之后马上debug,开发测试在一块来解决问题,这是最经济实惠的办法。
我个人非常喜欢敏捷软件开发的方式,开发测试在同一个团队里面。
发现缺陷后可以即刻查看、定位、调试修复问题。
而后在不得已的时候,例如短时间内无法解决此问题,再进行记录。
软件缺陷怎么描述
认识软件缺陷,首先要了解软件缺陷的概念,其次是了解软件缺陷的详细特征,最后就是它的属性了,再高一个层次就是学习利用管理软件缺陷的工具了。
1、首先介绍软件缺陷的概念 软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。
2、软件缺陷的详细特征 a、单一准确 b、可以再现(要求软件缺陷具有精确的步骤) c、完整统一 d、短小简练 e、特定条件 f、补充完整 g、不做评价 3、软件缺陷的属性 软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。
下面详细介绍一下以上这些属性: a、缺陷标识:是标记某个缺陷的唯一标识,可以用数字序号表示; b、缺陷类型:功能、用户界面、文档、软件包、性能、系统\模块接口 功能:影响了各种系统功能、逻辑的缺陷; 用户界面:影响了用户界面、人机交互特性,包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷; 文档:影响发布和维护,包括注释、用户手册、设计文档; 软件包:由于软件配置库、变更管理或版本控制引起的错误; 性能:不满足系统可测量的属性值,如执行时间、事务处理速率等; 系统\模块接口:与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。
c、缺陷严重程度:致命(Fatal)、严重(Ceritical)、一般(Major)、较小(Minor) 致命:系统任何一个主要功能完全丧失,用户数据受到破坏,系统崩溃、悬挂、死机或者危机人身安全; 严重:系统的主要功能部分丧失,数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显的影响; 一般:系统的次要功能没有完全实现,但不影响用户的正常使用。
例如:提示信息不太准确或用户界面差、操作时间长等一些问题; 较小:使操作者不方便或遇到麻烦,但它不影响功能过的操作和执行,如个别不影响产品理解的错别字、文字排列不整齐等一些小问题 d、缺陷产生可能性:总是、通常、有时、很少 总是:总是产生这个软件缺陷,其产生的频率是100%; 通常:按照测试用例,通常情况下会产生这个软件缺陷,其产生的频率大概是80%—90%; 有时:按照测试用例,有时候产生这个软件缺陷,其产生的频率大概是30%—50%;
转载请注明出处51数据库 » 严重的软件缺陷的产生主要源自