织雀教育软件缺陷管理.doc

上传人:m**** 文档编号:561836428 上传时间:2023-08-21 格式:DOC 页数:6 大小:67.51KB
返回 下载 相关 举报
织雀教育软件缺陷管理.doc_第1页
第1页 / 共6页
织雀教育软件缺陷管理.doc_第2页
第2页 / 共6页
织雀教育软件缺陷管理.doc_第3页
第3页 / 共6页
织雀教育软件缺陷管理.doc_第4页
第4页 / 共6页
织雀教育软件缺陷管理.doc_第5页
第5页 / 共6页
点击查看更多>>
资源描述

《织雀教育软件缺陷管理.doc》由会员分享,可在线阅读,更多相关《织雀教育软件缺陷管理.doc(6页珍藏版)》请在金锄头文库上搜索。

1、软件缺陷管理想获取更多测试资料,请访问织雀教育官网。认识软件缺陷,首先要了解软件缺陷的概念,其次是了解软件缺陷的详细特征,最后就是它的属性了,再高一个层次就是学习利用管理软件缺陷的工具了。1、首先介绍软件缺陷的概念软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。2、软件缺陷的详细特征a、单一准确b、可以再现(要求软件缺陷具有精确的步骤)c、完整统一d、短小简练e、特定条件f、补充完整g、不做评价3、软件缺陷的属性软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。下面详细介绍一下以上这些属性:a、缺陷标识:

2、是标记某个缺陷的唯一标识,可以用数字序号表示;b、缺陷类型:功能、用户界面、文档、软件包、性能、系统模块接口 功能:影响了各种系统功能、逻辑的缺陷; 用户界面:影响了用户界面、人机交互特性,包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷; 文档:影响发布和维护,包括注释、用户手册、设计文档; 软件包:由于软件配置库、变更管理或版本控制引起的错误; 性能:不满足系统可测量的属性值,如执行时间、事务处理速率等; 系统模块接口:与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。c、缺陷严重程度:致命(Fatal)、严重(Ceritical)、一般(Major)、较小(

3、Minor) 致命:系统任何一个主要功能完全丧失,用户数据受到破坏,系统崩溃、悬挂、死机或者危机人身安全; 严重:系统的主要功能部分丧失,数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显的影响; 一般:系统的次要功能没有完全实现,但不影响用户的正常使用。例如:提示信息不太准确或用户界面差、操作时间长等一些问题; 较小:使操作者不方便或遇到麻烦,但它不影响功能过的操作和执行,如个别不影响产品理解的错别字、文字排列不整齐等一些小问题d、缺陷产生可能性:总是、通常、有时、很少 总是:总是产生这个软件缺陷,其产生的频率是100; 通常:按照测试用例,通常情况下会产生这个软件缺陷,其

4、产生的频率大概是8090; 有时:按照测试用例,有时候产生这个软件缺陷,其产生的频率大概是3050; 很少:按照测试用例,很少产生这个软件缺陷,其产生的频率大概是15.e、缺陷的优先级:立即解决、高优先级、正常排队、低优先级 立即解决:缺陷导致系统几乎不能使用或者测试不能继续,需立即修复; 高优先级:缺陷严重,影响测试,需要优先考虑; 正常排队:缺陷需要正常排队等待修复; 低优先级:缺陷可以再开发人员有时间的时候被纠正。f、缺陷状态:激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息 激活或打开:问题还没有解决,存在源代码中,确认”提交的缺陷”,等待处理,如新

5、报的缺陷; 已修正或修复:已被开发人员检查、修复过的缺陷,通过单元测试,认为已经解决但还没有被测试人员验证; 关闭或非激活:测试人员验证后,确认缺陷不存在之后的状态; 重新打开:测试人员验证后,确认缺陷不存在之后的状态; 推迟:这个软件缺陷可以在下一个版本中解决; 保留:由于技术原因或第三者软件的缺陷,开发人员不能修复的缺陷; 不能重现:开发不能再现这个软件缺陷,需要测试人员检查缺陷再现的步骤; 需要更多信息:开发能再现这个软件缺陷,但开发人员需要一些信息,例如缺陷的日志文件、图片等。g、软件缺陷的起源:需求、构架、设计、编码、测试、用户 在团建生命周期中软件缺陷占的比例:需求和构架设计阶段占

6、54、设计阶段占25、编码阶段占15、其他占6.h、软件缺陷的来源:需求说明书、设计文档、系统集成接口、数据流(库)、程序代码 需求说明书:需求说明书的错误或不清楚引起的问题; 设计文档:设计文档描述不准确。和需求说明书不一致的问题; 系统集成接口:系统个模块参数不匹配、开发组之间缺乏协调引起的缺陷; 数据流(库):由于数据字典、数据库中的错误引起的缺陷; 程序代码:纯粹在编码中的问题所引起的缺陷。i、缺陷根源:测试策略,过程、工具和方法,团队人,缺乏组织和通讯,硬件,软件,工作环境 测试策略:错误的测试范围,误解测试目标,超越测试能力等; 过程、工具和方法:无效的需求收集过程,果实的风险管理

7、过程,不使用的项目管理方法,没有估算规程,无效的变更控制过程等; 团队人:项目团队职责交叉,缺乏培训。没有经验的项目团队,缺乏士气和动机不纯等; 缺乏组织和通讯:缺乏用户参与,职责不明确、管理失败等; 硬件:硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失,内存溢出等; 软件:软件设置不对、缺乏,或操作系统错误导致无法释放资源,工具软件的错误,编译器的错误,千年虫问题等; 工作环境:组织机构调整,预算改变,工作环境恶劣,如噪音过大。4、学会利用管理缺陷的工具例如TD、bugfree、bugzille等软件缺陷(software defect)是对软件产品预期属性的偏离现象。它包括检测缺陷和残留

8、缺陷。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。一、软件缺陷(software defect)分类标准 1.1 缺陷属性 属性名称描述缺陷标识(Identifier)缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识缺陷类型 (Type)缺陷类型是根据缺陷的自然属性划分的缺陷种类。缺陷严重程度 (Severity)缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。缺陷优先级(Priority)缺陷的优先级指缺陷必须被修复的紧急程度。缺陷状态(Status)缺陷状态指缺陷通过一个跟踪修复过程的进展情况。缺陷起源(Origin)缺陷来源指

9、缺陷引起的故障或事件第一次被检测到的阶段。缺陷来源(Source)缺陷来源指引起缺陷的起因。缺陷根源(Root Cause)缺陷根源指发生错误的根本因素。 1.2 缺陷类型(Type) 缺陷类型编号缺陷类型描述10F- Function影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑,指针,循环,递归,功能等缺陷。20A- Assignment需要修改少量代码,如初始化或控制块。如声明、重复命名,范围、限定等缺陷。30I- Interface与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。40C- Checking提

10、示的错误信息,不适当的数据验证等缺陷。50B Build/package/merge由于配置库、变更管理或版本控制引起的错误。60D- Documentation影响发布和维护,包括注释。70G- Algorithm算法错误。80U-User Interface人机交互特性:屏幕格式,确认用户输入,功能有效性,页面排版等方面的缺陷。90P-Performance不满足系统可测量的属性值,如:执行时间,事务处理速率等。100N-Norms不符合各种标准的要求,如编码标准、设计符号等。 1.3 缺陷严重程度(Severity) 1.3.1 软件测试错误严重程度 #缺陷严重等级描述1Critical

11、不能执行正常工作功能或重要功能。或者危及人身安全。2Major严重地影响系统要求或基本功能的实现,且没有办法更正。(重新安装或重新启动该软件不属于更正办法)3Minor严重地影响系统要求或基本功能的实现,但存在合理的更正办法。(重新安装或重新启动该软件不属于更正办法)4Cosmetic使操作者不方便或遇到麻烦,但它不影响执行工作功能或重要功能。5Other其它错误。 1.3.2 同行评审错误严重程度 #缺陷严重等级描述 Major主要的,较大的缺陷 Minor次要的,小的缺陷 1.4 缺陷优先级(Priority) #缺陷优先级描述1Resolve Immediately缺陷必须被立即解决。2

12、Normal Queue缺陷需要正常排队等待修复或列入软件发布清单。3Not Urgent缺陷可以在方便时被纠正。 1.5 缺陷状态(Status) 缺陷状态描述Submitted已提交的缺陷Open确认“提交的缺陷”,等待处理Rejected拒绝“提交的缺陷”,不需要修复或不是缺陷Resolved缺陷被修复Closed确认被修复的缺陷,将其关闭 1.6 缺陷起源(Origin) 缺陷起源描述Requirement在需求阶段发现的缺陷 Architecture在构架阶段发现的缺陷 Design在设计阶段发现的缺陷 Code在编码阶段发现的缺陷 Test在测试阶段发现的缺陷 1.7 缺陷来源(S

13、ource) 缺陷来源描述Requirement由于需求的问题引起的缺陷 Architecture由于构架的问题引起的缺陷 Design由于设计的问题引起的缺陷 Code由于编码的问题引起的缺陷 Test由于测试的问题引起的缺陷 Integration由于集成的问题引起的缺陷 1.8 缺陷根源(Root Cause) 软件缺陷(software defect)管理指南 1、如何收集缺陷 缺陷既指程序中存在的错误,例如语法错误、拼写错误或者是一个正确的程序语句,缺陷也指可能出现在设计中,甚至在需求、规格说明或其他的文档中的种种错误。为了对缺陷进行管理,首先应对缺陷进行分类,通过对缺陷进行分类,可

14、以迅速找出哪一类缺陷的问题最大,然后集中精力预防和排除这一类缺陷。而这正是缺陷管理的关键,一旦这几类缺陷得到控制,再进一步找到新的容易引起问题的几类缺陷上。 11 缺陷类型缺陷类型编号缺陷类型描述10F-功能如逻辑,指针,循环,递归,功能等缺陷20G-语法拼写、标点符号、打字30A-赋值如声明、重复命名,作用域40I-接口与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷50B-联编打包由于配置库、变更管理或版本控制引起的错误60D-文档需求、设计类文档70U-用户接口人机交互特性:屏幕格式,确认用户输入,功能有效性80P-性能不满足系统可测量的属性值,如:执行时间,事务处理速率等90N-标准不符合各种标准的要求,如编码标准、设计符号等100E-环境设计、编译、其他支持系统问题 12 了解缺陷 缺陷管理的第一步是了解缺陷,为此,必须首先收集缺陷数据,然后才能了解这些缺陷,并且找出如何预防它们,同时也能领会到如何更好地发现,修复甚至预防仍在引入的缺陷。可以按照以下步骤收集关于缺陷的数据: 为测试和同行评

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 生活休闲 > 社会民生

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号