质量管理体系软件测试缺陷管理.ppt

Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,*,Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,*,单击此处编辑母版标题样式,质量管理体系软件测试缺陷管理课件,（优选）质量管理体系软件测试缺陷管理课件,缺陷管理概念及目的3,缺陷管理目的：,对各阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到标准。主要实现以下目标：,及时了解并跟踪每个被发现的缺陷；,确保每个被发现的缺陷都能被处理；,收集缺陷数据并根据缺陷趋势曲线识别测试过程阶段；,收集缺陷数据并在其上进行数据分析，作为组织过程的财富。,什么是缺陷管理？,缺陷管理是在软件生命周期中识别、管理、沟通任何缺陷的过程（从缺陷的识别到缺陷的解决关闭），确保缺陷被跟踪管理而不丢失。,缺陷管理,4,软件测试中经常使用各种术语来描述软件出现的问题,如下一些通用的术语,:,软件错误,(Software Error),软件缺陷,(Software Defect),软件故障,(Software fault),软件失效,(Software failure),区分这些术语很重要，它关系到测试工程师对软件失效现象与机理的深刻理解,.,由于软件内部逻辑复杂,运行环境动态变化,且不同的软件差异可能很大,因而软件失效的机理可能也有不同的表现形式,但总的来说,软件失效的机理可描述为,:,软件错误,-,软件缺陷,-,软件故障,-,软件失效,不符合各种标准的要求，如编码标准、设计符号等缺陷。,与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。,缺陷在哪个版本发现(Detected in Version),负责报告系统缺陷记录，且协助项目人员进行缺陷定位；,“已挂起”的缺陷开始处理，开发人员将缺陷置为“重新打开”状态,软件故障(Software fault),软件故障:软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态.,由于需求问题引起的缺陷,缺陷发现时间（Detected on Date）,描叙缺陷是由谁发现提出的。,管理所有缺陷关闭情况；,缺陷被修改的时间（Modified）,描叙缺陷是由谁发现提出的。,其结果是软件运行于某一特定条件时出现软件故障,这时称软件被激活.,测试人员看到缺陷处于“已修复”状态，经验证失败后，将缺陷置为“重新打开”状态；,缺陷管理,5,软件错误,:,在可以遇见的时期内,软件将有人来开发,.,在整个生存期的各个阶段,都贯穿 着人的直接或间接的干预,.,然而人难免犯错误,这必然给软件留下不良的痕迹,.,软件错误是指在软件生存期内的不希望或不可接受的人为错误,其结果是导致软件缺陷的产生,.,可见,软件错误是一种人为过程,相对于软件本身,是一种外部行为,.,软件缺陷,:,软件缺陷是存在于软件,(,文档,数据,程序,),之中的那些不希望或不可接受的偏差,.,其结果是软件运行于某一特定条件时出现软件故障,这时称软件被激活,.,软件故障,:,软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态,.,比如,:,软件处于执行一个多余循还过程时,我们可以软件出现故障,.,若此时没有适当的措施,(容错,),加以处理,便产生软件失效,.,软件故障是一种动态行为,.,软件失效,:,软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果,.,质量管理体系软件测试缺陷管理课件,比如:软件处于执行一个多余循还过程时,我们可以软件出现故障.,由于软件内部逻辑复杂,运行环境动态变化,且不同的软件差异可能很大,因而软件失效的机理可能也有不同的表现形式,但总的来说,软件失效的机理可描述为:,项目相关开发人员（DE）,单一准确每个报告只针对一个软件缺陷。,负责接收各自的缺陷记录，并且修改；,不做评价在软件缺陷描述不要带有个人观点，对开发人员进行评价。,软件错误是指在软件生存期内的不希望或不可接受的人为错误,其结果是导致软件缺陷的产生.,短小简练通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产生缺陷的现象。,软件故障(Software fault),确保每个被发现的缺陷都能被处理；,描述缺陷实际修复所花的时间,缺陷所属于的模块（subject）,缺陷管理怎样专业的描述缺陷,与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。,缺陷管理,6,综上所述,软件错误是一种人为错误,.,一个软件错误必定产生一个或多个软件缺陷,.,当一个软件缺陷被激活时,便产生一个软件故障,;,同一个软件缺陷在不同条件下被激活,可能产生不同的软件故障,.,软件故障如果没有及时容错措施加以处理,便不可避免地导致软件失效,.,缺陷原因分布图,7,缺陷管理,人员职责,8,参与缺陷管理过程人员角色职责,:,项目经理（,PM,）,负责指派缺陷给相关责任人,.,项目测试经理（,TM,）,:,决定缺陷管理方式和工具，拟定决策评审计划；,管理所有缺陷关闭情况；,审核测试人员提交的缺陷；,对测试人员的工作质量进行跟踪与评价。,测试人员（,TE,）,负责报告系统缺陷记录，且协助项目人员进行缺陷定位；,负责验证缺陷修复情况，且填写缺陷记录中相应信息；,负责执行系统回归测试；,提交缺陷报告；,负责被测软件进行质量数据和分析。,项目相关开发人员（,DE,）,修改测试发现的缺陷，并提交成果物做再测试；,负责接收各自的缺陷记录，并且修改；,负责提供缺陷记录跟踪中其它相应信息。,质量保证人员（,QA,）,监控项目组缺陷管理规程执行情况。,测试管理流程,9,缺陷状态,10,缺陷状态,状态描述,新建,测试或评审人员记录缺陷后的状态,已分配,开发经理接受测试人员提交的缺陷是缺陷后，将其分配给对应的开发人员，并将状态置为“已分配”状态,已拒绝,开发经理或者开发人员看到分配给自己的缺陷不是缺陷，将缺陷置为“已拒绝”状态,已修复,开发人员在开发环境对一个缺陷已经修复完，开发人员置为“已修复”状态,重新打开,测试人员看到缺陷处于“已修复”状态，经验证失败后，将缺陷置为“重新打开”状态；“已挂起”的缺陷开始处理，开发人员将缺陷置为“重新打开”状态,已拒绝已关闭,表示缺陷被开发经理拒绝并已通过测试人员的认可,已挂起,开发经理判断缺陷为推迟修改的，将状态置为“已挂起”状态；开发人员判断缺陷为推迟修改的，将状态置为“已挂起”状态,已关闭,测试人员看到缺陷处于“已修复”状态，经验证通过后，将缺陷置为“已关闭”状态,缺陷管理相关属性,11,缺陷属性,描述,缺陷描叙（,Summary,）,简单描述缺陷，主要是什么缺陷,缺陷发现提交者（,Detected By,）,描叙缺陷是由谁发现提出的。,缺陷发现时间（,Detected on Date,）,描叙缺陷发现提出时间。,缺陷严重性（,Severity描述缺陷的严重性。,缺陷分给谁（,Assigned to,）,指缺陷分派给谁。,缺陷在哪个版本发现,(Detected in Version),描叙缺陷发现的版本,缺陷被修改的时间（,Modified,）,描叙缺陷被修改的时间。,计划修复时间（,Plan fixed Data,）,描叙缺陷计划完成修复的时间。,缺陷优先级（,priority,）,描述缺陷的优先级。,缺陷所属项目（,Project,）,描述缺陷所属的工程。,是否是重现缺陷,(Reproducible),描述缺陷是否是重现缺陷。,缺陷的状态,(Status),描述缺陷的状态,缺陷所属于的模块（,subject,）,描述缺陷所属的模块。,缺陷详细描述（,Description,）,缺陷详细描述，包括缺陷产生的步骤，缺陷的实际结果，缺陷的理想结果，建议等。,缺陷实际关闭的版本（,Closed in Version,）,描述缺陷实际关闭的版本。,缺陷实际修复所花的时间（,Actual Fixed Time,）,描述缺陷实际修复所花的时间,缺陷修复完成时间（,Closing Date,）,描述缺陷实际关闭的时间。,注释,(Comments),描叙对缺陷的注释。,附件（,Attachments,）,添加缺陷附件。,由于其他问题引起的缺陷,软件故障(Software fault),描述缺陷实际修复所花的时间,软件缺陷:软件缺陷是存在于软件(文档,数据,程序)之中的那些不希望或不可接受的偏差.,影响发布和维护，包括注释等缺陷。,缺陷描叙（Summary）,软件失效(Software failure),不做评价在软件缺陷描述不要带有个人观点，对开发人员进行评价。,决定缺陷管理方式和工具，拟定决策评审计划；,描叙缺陷是由谁发现提出的。,一个软件错误必定产生一个或多个软件缺陷.,由于编码问题引起的缺陷,缺陷发现时间（Detected on Date）,描述缺陷实际关闭的时间。,一个软件错误必定产生一个或多个软件缺陷.,缺陷优先级,12,缺陷的优先级是根据用户对缺陷修改的时间要求划分的，具体如下：,序号,优先等级,紧急程度描述,1,P1,立即解决,缺陷导致系统几乎不能使用或测试不能继续，需立即修复,2,P2,高优先级,缺陷严重影响测试需要优先考虑,3,P3,正常排队,缺陷需要正常排队等待修复,4,P4,低优先级,缺陷可以在开发人员有时间的时候再被纠正,缺陷严重等级定义,13,序号,严重程度,缺陷性质,定义标准,优先级,1,A,类,致命缺陷,直接影响测试继续执行的错误。必须在最短时间内修复，否则测试无法继续进行。包含但不限于：,1.,正常的用户操作导致浏览器崩溃或无响应,2.,产品核心功能没有实现或无法使用,3.,程序实现与需求严重不符,4.,其他导致无法测试的错误,5.,严重的数值计算错误,6.,存在致命的安全漏洞,7.Bug,被重开,3,次及以上,立即解决,2,B,类,严重缺陷,影响其他测试案例的继续执行或与功能规格严重不符的错误，以及有可能给银行造成损失和风险的错误。包含但不限于：,1.,产品功能实现不正确,2.,主业务流程对应的功能未实现，阻碍测试继续进行,3.,严重的兼容性问题和页面样式问题，如：页面样式严重错乱，导致页面控件无法正常定,位；,4.,正常的用户操作导致浏览器出现偶发类崩溃（偶发概率,20%,以上）,5.,程序实现与需求功能上不符,6.,其他导致部分模块无法测试的错误,7.,主要数值计算错误,8.,严重的功能逻辑错误,9.Bug,被重开,2,次,高优先级,3,C,类,一般缺陷影响客户服务的错误。对系统功能影响比较小的错误,在测试结束前必须修复。,如报表格式不完全正确，提示信息不对，画面布局文字有错误等,正常排队,4,D,类,微小缺陷,如提示信息不准确，画面布局位置不合理,低优先级,5,E,类,建议,对系统功能提出自己的见解或意见，具使其具备一定的改革和改良的条件，使其向着更加良好的、积极的方面去完善和发展。,低优先级,缺陷管理,缺陷来源,14,序号,缺陷起源,描述,1,需求,由于需求问题引起的缺陷,2,设计,由于设计问题引起的缺陷,3,编码,由于编码问题引起的缺陷,4,集成,由于集成问题引起的缺陷,5,其他,由于其他问题引起的缺陷,缺陷管理,缺陷分类,15,序号缺陷类型,描述,子类型名称,1,功能问题,影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如指针，循环，递归，功能等缺陷。,功能错误,功能缺失,功能超越,设计二义性,算法错误,2,接口问题,与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。,模块间接口,模块内接口,公共数据使用,3,逻辑问题,需要进行逻辑分析，进行代码修改，如循环条件等,分支不正确,重复的逻辑,忽略极端条件,不必要的功能,误解,条件测试错误,循环不正确,错误的变量检查,计算顺序错误,逻辑顺序错误,4,计算问题,等式、符号、操作符或操作书错误，精度不够、不适当的数据验证等缺陷。,等式错误,缺少运算符,错误的操作数,括号用法不正确,精度不够,舍入错误,符号错误,缺陷管理,缺陷分类,16,序号,缺陷类型,描述,子类型名称,5,数据问题,需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。,初始化错误,存取错误,引用错误的变量,数组引用越界,不一致的子程序参数,数据单位不正确,数据维数不正确,变量类型不正确,数据范围不正确,操作符数据错误,变量定位错误,数据覆盖,外部数据错误,输出数据错误,输入数据错误,数据检验错误,6,用户界面问题,人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷。,界面风格不统一,屏幕上的信息不可用,屏幕上的错误信息,界面功能布局和操作不合常规,7,文档问题,影响发布和维护，包括注释等缺陷。,描述含糊,项描述不完整,项描述不正确,项缺少或多余,项不能验证,项不能完成,不符合标准,与需求不一致,文字排版错误,文档信息错误,注释缺陷,缺陷管理,缺陷分类,17,通过对缺陷进行分类，可以迅速找出哪一类缺陷的问题最大，然后集中精力预防和排除这一类缺陷。,序号,缺陷类型,描述,子类型名称,8,性能问题,不满足系统可测量的属性值，如：执行时间，事务处理速率等缺陷。,9,配置问题,由于配置库、变更管理或版本控制引起的错误。,配置管理问题,编译打包缺陷,变更缺陷,纠错缺陷,10,标准问题,不符合各种标准的要求，如编码标准、设计符号等缺陷。,不符合编码标准,不符合软件标准,不符合行业标准,11,环境问题,由于设计、编译和运行环境引发的问题。,设计、编译环境,运行环境,12,其他问题,以上问题所不包含的其他问题。,缺陷管理,怎样专业的描述缺陷,18,软件缺陷的有效描述规则，主要是：,1.,单一准确,每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。,2.,可以再现,提供缺陷的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷，通常情况下，开发人员只有再现了缺陷，才能正确地修复缺陷。,3.,完整统一,提供完整、前后统一的软件缺陷的步骤和信息，例如：图片信息，,Log,文件等。,4.,短小简练,通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。,5.,特定条件,许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如“搜索功能在没有找到结果返回时跳转页面不对”。,6.,补充完善,从发现,bug,那一刻起，测试人员的责任就是保证它被正确的报告，并且得到应有的重视，继续监视其修复的全过程。,7.,不做评价,在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。,