课件01-软件测试-成果

软件测评技术

第一部分测试成果及管理测试成果及管理—提要认识软件测试失效及其管理缺陷及其管理认识—测试的定义由人工或自动方法来执行或评价系统或系统部件的过程，以验证它是否满足规定的需求；或识别出期望的结果和实际结果之间有无差别。认识—测试的对象软件被广泛应用，承担许多关键与核心任务软件是被开发或设计的，包括维护阶段软件是逻辑产品，可视性低软件是复杂的，输入空间无限大，可执行路径特别多大多数软件是定制的，可选标准构件少既可能运行在芯片上，也可能运行于大型系统中认识—测试的发展历程时间区间标志性活动~1956面向调试的阶段1957~1978面向证实的阶段1979~1982面向缺陷的阶段1983~1987面向评价的阶段1988~面向预防的阶段认识—测试的目的发现软件中隐藏的缺陷或其征兆；验证软件是否满足其规格说明的规定和要求；为软件产品质量的评价提供依据，为软件开发过程的改进提供支持。认识—测试的焦点开发过程中的工作产品软件需求规格说明软件设计文档软件源代码软件产品软件目标代码用户文档认识—测试的独立性开发人员的测试专职测试人员的测试专职测试团队的测试独立机构的测试用户的测试认识—测试与调试测试不是调试，调试也不是测试，实际工作中人们却常将测试与调试混为一谈主要区别：测试是一种检验，调试是推理过程测试从已知条件开始，使用预先定义的规程并且有可预知的结果；调试的开始条件可能不可知，结果不可预见测试经常由非程序设计人员完成，调试必须由程序设计者完成认识—验证与确认验证(Verification)与确认(Validation)是广泛认可的质量保证方法和手段验证是指对开发过程中某项规定活动进行检查的过程，以确保该活动实现了规定能力确认是指审查已建立的软件产品是否符合客户需要的过程V&VVerification:

Arewebuildingtheproductright?Validation:

Arewebuildingtherightproduct?认识—验证与确认认识—测试的公理公理1不可能对程序进行完全的测试局限无法确信规格说明100%正确无法确信可以达到100%的软件测试无法保证测试环境100%满足测试要求期望证实给定的软件满足其规格说明认识—测试的公理公理2测试无法说明软件没有缺陷局限软件质量体现在多个方面，但首先要面对并必须解决的是软件缺陷，在资源制约和技术限制的条件下，无法保证找到软件中所有的缺陷期望在给定的时限内尽可能多的发现缺陷和隐患认识—测试的公理公理3发现问题越多地方,潜在的问题也更多局限不可能通过测试获得100%的质量信心无法确信测试系统(或环境)的正确性无法确信测试人员完全理解了软件没有足够的资源彻底完成软件测试期望为软件产品质量的评价提供依据认识—测试的地位软件测试是软件验证与确认的重要组成部分有效的测试对于开发可靠、安全和成功的软件是必须的测试不是“银弹(silverbullet)”，它具有有效范围，它不能替代其它软件工程方法的作用认识—与其他活动的关系软件质量软件工程方法标准与过程正式技术评审测试SCM与SQA度量与控制认识—测试的主要成果软件缺陷软件缺陷的征兆故障失效异常注：相关定义来自IEEEStd1633™-2008IEEERecommendedPracticeonSoftwareReliability认识—缺陷缺陷(Defect)存在于软件中的、不期望的或不可接受的偏差。在特定的状态下，导致软件不能完成所需的任务典型的软件缺陷数组越界使用计算表达式错误算法实现错误认识—故障故障(Fault)软件中缺陷的体现。如：软件的计算或判断与规定的不符合等一个故障如果发生，可能引起失效典型的软件故障资源泄露执行了多余的循环无限递归调用认识—失效失效(Failure)系统或系统部件不能在规定的限制内完成所需功能功能单元完成所需功能的能力被终止程序的运行偏离了其需求认识—异常观察到异常(征兆)软件失效测试失效软件缺陷(原因)测试缺陷(原因)开发人员错误测试人员错误可能造成可能表现为可能是认识—征兆与原因征兆和原因有可能在“地理上”是分离的征兆有可能会因为其他问题的解决而消失征兆有可能是间歇性的原因有可能会归结于非错误之间的组合原因有可能会归结于系统或编译器错误原因有可能会归结于每个人都相信的假设认识—失效与缺陷的关系错误(Error)在软件开发过程中软件开发人员产生隐错／缺陷(bug/defect)在软件产品中软件中存在设计者的失误(错误)→导致软件中留有错误的设计(缺陷)→导致软件错误地执行(故障)→导致软件的错误行为(失效)。故障(fault)在软件运行中缺陷被激活失效(failure)在运行阶段用户的经历认识—错误错误(Error)在软件开发过程中出现的不符合期望或不可接受的人为差错典型的错误误解或遗漏了用户需求设计没有完整的实现软件需求程序设计错误认识—软件测试发展动态国外的情况测试是开发过程的常规活动测试技术的利用趋于科学国内的情况专业机构的情况开发机构的情况评价技术的使用还较局限认识—软件测试标准进展ISO/IEC25051:2006Softwareengineering--SoftwareproductQualityRequirementsandEvaluation(SQuaRE)--RequirementsforqualityofCommercialOff-The-Shelf(COTS)softwareproductandinstructionsfortesting认识—软件测试标准进展GB/T25000.51-2010软件工程软件产品质量要求和评价(SQuaRE)商业现货(COTS)软件产品的质量要求和测试细则认识—软件测试标准进展ISO/IEC/IEEE29119:2013Softwareandsystemsengineering--Softwaretesting认识—软件测试标准进展ISO/IEC25010:2011Systemsandsoftwareengineering--SystemsandsoftwareQualityRequirementsandEvaluation(SQuaRE)--Systemandsoftwarequalitymodels认识—软件测试标准进展质量特性1特性2特性3特性n子特性1子特性2子特性n属性1属性2属性n属性1属性2属性3属性n认识—软件测试标准进展ISO/IEC25010:2011SoftwareproductqualitymodelFunctionalstabilityReliabilityPerformanceefficiencyUsabilitySecurityCompatibilityMaintainabilityPortability认识—软件测试标准进展ISO/IEC25010:2011FunctionalstabilityFunctionalcompletenessFunctionalcorrectnessFunctionalappropriateness认识—软件测试标准进展ISO/IEC25010:2011ReliabilityMaturityAvailabilityFaulttoleranceRecoverability认识—软件测试标准进展ISO/IEC25010:2011PerformanceefficiencyTimebehaviorResourceutilizationCapacity认识—软件测试标准进展ISO/IEC25010:2011UsabilityAppropriatenessrecognizabilityLearnabilityOperabilityUsererrorprotectionUserinterfaceaestheticsAccessibility认识—软件测试标准进展ISO/IEC25010:2011SecurityConfidentialityIntegrityNon-repudiationAccountabilityAuthenticity认识—软件测试标准进展ISO/IEC25010:2011CompatibilityCo-existenceInteroperability认识—软件测试标准进展ISO/IEC25010:2011MaintainabilityModularityReusabilityAnalyzabilityModifiabilityTestability认识—软件测试标准进展ISO/IEC25010:2011PortabilityAdaptabilityInstallabilityReplaceability认识—软件测试标准进展ISO/IEC25040:2011Systemsandsoftwareengineering--SystemsandsoftwareQualityRequirementsandEvaluation(SQuaRE)--Evaluation失效—失效状态考虑到相关的操作及环境条件，由一个或多个失效引起或作用的对系统的直接和后继的影响不同的失效状态对可靠性的影响具有差异失效—Therac-25事件AtomicenergyofCanadaLtd开发的Therac-25放射治疗仪1985.6~1987.1,6人治疗过量,其中3人死亡失效—Therac-25原因主循环中存在竞争条件寄存器溢出失效—Therac-25教训系统安全性分析、风险分析未包含软件Therac-25重用了T-20的软件，假设和前提发生了改变，但未受到关注失效—Ariane5事件1996年6月4日，Ariane5发射40秒后爆炸失效—Ariane5直接原因将一个64位浮点值转换为16位有符号整数值时，超出了16位整数的表示范围，而这个异常未得到正确处理失效—Ariane5经验教训作了Ariane5和Ariane4具有相同环境的假设，重用软件在新的环境下完全没有进行测试错误处理模块的处理机制不正确失效—火星探测器事件1999年，火星气象卫星(MarsClimateOrbiter)到达火星之后不久就消失1999年，火星极地登陆者(MarsPolarLander)在火星上着陆时坠毁。失效—火星探测器原因地面系统软件和飞行器上软件分别使用公制和英制两种单位。失效—火星探测器教训没有进行充分的测试；发现异常时，没有被恰当的解释。失效—其他案例7·23事件银联出租车计价器GE医疗软件因失效主动召回……失效—?列举你所见、所闻的失效失效—分级失效状态可划分为不同的等级软件失效的分级可以依据不同的前提所带来的安全风险所造成的经济损失对系统任务的影响失效—分级的作用根据软件失效的级别，通过可靠性分析，找出关键的软件部件(子系统/配置项/部件/单元/功能)，进行重点管理，降低开发风险对软件进行分级管理关键/重要/一般A/B/C/D/E根据软件失效的级别，识别关键功能，进行标识和追踪管理失效—分级举例1失效类别对服务质量的影响A基本服务中断B基本服务质量降低C使用不方便，需要立即修改D影响较小，可延期修改失效—分级举例2失效类别可能造成的经济损失(元)1>100000210000~10000031000~100004<1000失效—分级举例3失效类别对操作的影响1用户不能进行一项或多项关键操作2用户不能进行一项或多项重要操作3用户不能进行一项或多项操作，但是有补救办法4一项或多项操作中的小缺陷失效—FRACASFRACAS是“FailureReportAnalysisandCorrectiveActionSystem”的缩写，是“失效报告、分析及纠正措施系统”FRACAS通常也称为“失效信息闭环管理系统”是跟踪系统可靠性的方法是一组过程、规则和软件工具在产品生存期后端开始使用失效—FRACAS的角色工作系统视角组织机构(各方代表)人员职责分工工作的流程资源保障失效—FRACAS的角色信息系统视角与可靠性信息系统的关系信息准确与完整性及时性、正确性可追踪性失效—FRACAS的作用及时有效地处理当前故障过去发生的故障不再重现建立企业的可靠性经验失效—FRACAS的目标利用“信息反馈，闭环控制”的原理，通过一套规范化的程序，使发生的产品故障能得到及时的报告和纠正，从而实现产品可靠性的增长，达到对产品可靠性和维修性的预期要求，防止故障再现通过FRACAS建立企业问题/故障信息数据库，为软件可靠性设计和分析以及关于维修策略、保障策略和备件策略的制定提供数据支持失效—FRACAS流程记录事件分析失效模式开展纠正活动检验纠正活动识别失效趋势确定单个部件对失效产生的作用失效—FRACAS实施故障记录故障报告故障分析纠正措施闭环管理售后服务数据库FRACAS数据库外场故障厂内故障失效—FRACAS进化知识库故障故障报告根源分析纠正措施闭环验证可靠性分析产品改进①②③④⑤⑥⑦失效—FRACAS文档故障记录表故障报告表故障分析表纠正措施表闭环管理表失效—利用FRACASFRACAS数据库FMEA设计准则可靠性评估可靠性增长计划故障模式手册关键件判定和故障历史使用、故障、维修信息故障统计分析缺陷—软件的缺陷属性无法提供无缺陷的软件，缺陷已成为软件的固有属性和特征各种研究报告表明，每写1000行代码会产生30到85个缺陷大多数缺陷可通过测试捕获在大量的已完成测试的软件中，每1000行代码仍存在0.5~3缺陷软件缺陷有可能会给系统质量尤其是可靠性带来重大影响缺陷—求和的例子#include<stdio.h>intsum(i1,i2,i3){inti1;inti2;inti3;return(i1+i2+i3);}intmain(){printf(“Sumis%d\n”,sum(1,2,3));return(0)}缺陷—排序的例子#include<iostream>intmain(){inta,b,c;a=7;b=5;c=3;if(a>b>c)std::cout<<“a,b,careinorder\n”;elsestd::cout<<“a,b,caremixedup\n”;return(0);}缺陷—?列举你所见、所闻的缺陷缺陷—缺陷的影响缺陷可能导致失效同样的缺陷在不同的场景下导致的失效状态会有很大的差别，可能只是使用不便，也有可能带来灾难缺陷的复杂度与失效的严重性之间的关系是未知的最大限度的减少缺陷,可以提高软件的可靠性缺陷—基本特性变异的预期常常产生缺陷在实际项目中完全消除缺陷是不可能的，基于软件开发经济学的考虑，减少缺陷是现实的缺陷有可能非常简单，也有可能极其复杂程序设计语言与缺陷的复杂性和数量的关系是未知的不论人的能力和背景，都可能产生缺陷认识—缺陷的解决策略避错(Defectavoidance)第一次就做正确排错(defectremoval)早发现,早实施容错(Defecttolerance)有缺陷,也能正确的完成任务恢复选用最佳恢复策略,失效后继续工作缺陷—缺陷管理的目的强制按照统一的流程处理缺陷对缺陷实现全生命周期的闭环管理依据缺陷的相对和绝对重要性来修复问题有利于缺陷信息的清楚传达透明的缺陷修复进展获得更多有价值的信息为技术支持和市场部门提供支持缺陷—缺陷管理的目标确保应该修正的问题和缺陷都得到修正其它均是次要问题缺陷—避免滥用个人业绩监控开发与测试人员的弹药库缺陷—缺陷管理的任务需要了解缺陷的人员一看到报告就应该明白不会因为被相关人员遗忘而得不到修正避免个别程序员的“即兴发挥”增加交流缺陷—缺陷生命周期审阅打开分配测试关闭拒绝重新打开暂缓缺陷—分类法基于来源分类基于严重性或危害度分类基于修复优先级分类缺陷—基于来源分类功能系统过程数据杂类BorisBeizer缺陷—功能类规格功能测试缺陷—系统类内部接口硬件设备操作系统软件结构资源管理缺陷—过程类计算初始化控制或序列静态逻辑其它缺陷—数据类类型结构初始化其它缺陷—杂类代码文档标准其它重复NAP(不是一个问题)缺陷—严重性等级(1)1不能完全满足系统要求，基本功能未完全实现或危及人员安全的缺陷。2不利于完全满足系统要求或基本功能实现，并且不存在变通的解决办法的缺陷。3不利于完全满足系统要求或基本功能的实现，但却存在合理的变通解决办法的缺陷。4不影响完全满足系统要求或基本功能的实现，但有不便于操作的缺陷。5其它缺陷缺陷—严重性等级(2)轻微输出拼写错误，遗漏一些空格普通输出可能被误解或者多余反感用户需要一些窍门使用户工作烦扰拒绝处理合法事务严重事务及其处理无固定轨迹非常严重缺陷导致系统进行错误的处理极端严重缺陷频繁且随意的导致一些用户或一些事务受限不可容忍长期不可恢复的数据库讹误，必需重启系统灾难系统失败传染使其他系统变坏，导致文件丢失缺陷—危害度危害度轻微普通反感严重非常严重灾难传染缺陷类型缺陷—修复优先级立即解决高优先级正常排队低优先级缺陷—分工测试人员报告软件缺陷分析人员分析缺陷报告开发人员修复缺陷，并将修复集成到新的版本中测试人员检查新的版本缺陷—测试人员的工作负责报告缺陷监控所报告的缺陷的解决缺陷—建立管理系统使用商业缺陷跟踪与管理系统自行开发专用缺陷跟踪与管理系统创建缺陷数据库缺陷—周报每周新发现问题总结按功能区域和严重性分类每周状态报告包括对缺陷数量意外上升的解释缺陷—测试周期完成报告当所有重要问题已经解决，结束这个测试周期;报告给出总共报告了多少缺陷，修正了多少，多少被延期。缺陷—报告的作用报告新的缺陷描述缺陷相关的现有信息发现缺陷是测试的目的,缺陷报告是测试者主要的工作成果程序员工作在时间和竞争的压力下,缺陷报告是测试者向程序员推销应该花时间和精力去修复一个缺陷的手段缺陷—隔离运行测试并发现了失败,所看到的是征兆,不是潜在的缺陷继续做工作，希望证实这个缺陷:更严格更一般缺陷—报告编写指南阐述如何重现问题分析错误使得能用最少的步数描述它包括所有的步骤让报告易于理解用中立语言保持简单:每个报告一个缺陷如果测试文件是重现问题的基础,参照并附上缺陷—报告的要素1问题报告单号9能否重现17分配2报告人10严重性18状态3报告日期11优先级19解决4被测对象名称12客户影响20解决版本5发布号13问题摘要21解决人6版本标识14关键字22更改记录7配置15问题描述23注释8报告类别16修复建议缺陷—写好缺陷报告好的报告从好的测试开始立即写报告准确、完整而简练发现了什么，不是做了什么缺陷—分类管理举例正交缺陷分类(ODC，OrthogonalDefectClassification)由IBM在1990s开发定量管理缺陷的方法DefectTypeTrigger缺陷—ODCv5.11OpenerCloserDefect类型(Type)来源(Source)影响(Impact)触发(Trigger)活动(Activity)目标(Target)界定(Qualifier)年龄(Age)缺陷—活动(Activity)设计评审(DesignReview)代码审查(CodeInspection)单元测试(UnitTest)功能测试(FunctionTest)系统测试(SystemTest)缺陷—触发(Triggers)设计评审/代码审查类触发单元测试类触发功能测试类触发系统测试类触发缺陷—触发(Triggers)设计评审/代码审查类触发设计一致性(DesignConformance)逻辑/流程(Logic/Flow)向后兼容(BackwardCompatibility)内在文档(InternalDocument)横向兼容(LateralCompatibility)并发(Concurrency)语言依赖(LanguageDependency)副作用(SideEffects)特