《软件测试与维护》PPT课件.ppt

上传人:xin****828 文档编号:15500239 上传时间:2020-08-13 格式:PPT 页数:58 大小:233.50KB
返回 下载 相关 举报
《软件测试与维护》PPT课件.ppt_第1页
第1页 / 共58页
《软件测试与维护》PPT课件.ppt_第2页
第2页 / 共58页
《软件测试与维护》PPT课件.ppt_第3页
第3页 / 共58页
点击查看更多>>
资源描述
软件测试,软件测试的基本概念 软件测试过程 软件测试用例设计 面向对象测试 软件调试 自动测试工具 软件可靠性评估,软件测试目标,软件测试的目标就是发现软件中隐藏的错误。 由于对软件测试的目标存在一些错误认识和做法,G.Myers给出了关于软件测试目标的一些规则说明: (1) 测试是程序的执行过程,目的在于发现错误; (2) 一个好的测试用例在于能发现至今未发现的错误; (3) 一个成功的测试是发现了至今未发现的错误的测试。 组织专门的测试小组时,程序的编写者不适合对自己编写的程序进行确认测试(程序调试除外)。,软件测试是贯穿于软件开发过程始终的一个活动,由测试计划、单元测试、集成测试、系统测试、验收测试组成。 一、测试计划:作为软件项目计划的子计划,在项目启动初期就开始进行规划,在项目进行的各阶段可以同步进行相应的测试计划的编制。 需求分析阶段开始编制系统测试和验收测试的计划 系统设计阶段编制集成测试计划 编码的同时编制单元测试计划 二、单元测试:依据详细设计说明书,测试某个模块是否满足规定的功能,是整个软件测试过程中最基本的活动。多采用白盒测试技术。,软件测试过程,单元测试的主要任务: 模块接口测试 局部数据结构测试 路径测试 错误处理测试 边界测试 单元测试方法:单元测试通常在编码阶段进行,使用一些辅助模块去模拟与被测模块相联系的其它模块。辅助模块主要有驱动模块和桩模块。 (1)驱动模块:相当于调用被测模块的主程序。 (2)桩模块:用来代替被测模块需要调用的子模块。,三、集成测试:在单元测试的基础上,承担对系统进行组装与检测的双重任务,是软件测试活动中最重要的部分。主要有非渐增组装测试和渐增组装测试两种方法。 具体测试任务 连接各模块时,穿越模块接口的数据是否会丢失。 一个模块的功能是否对另一个模块的功能产生不利影响。 各子模块组合起来,能否达到预期的协作功能。 全局数据结构是否有问题。 单个模块的计算误差积累起来,是否会放大进而达到不能接受的程度。,非渐增组装测试:先完成单元模块的确认测试,然后将所有模块按设计要求组合成系统,再进行测试。 测试过程中发现的问题断定出错的位置和出错的原因。 渐增组装测试:把所有需要集成到系统中的模块按照一定的次序,逐个集成到系统中去,并在进行模块间协作性测试的同时对模块的功能进行确认测试。 渐增组装测试的优点: 利用已测试过的模块作为部分测试软件,减少测试工作量。 能够较早发现模块间的接口错误。 发生的错误往往和最近加进来的模块有关,便于错误诊断与定位。 先加入系统的模块不断在新的条件下受到新的检测,对程序的测试更彻底。,渐增组装测试的方法:自顶向下、自底向上。 自顶向下渐增组装测试:从主控模块开始,沿着软件的控制层次向下移动,从而逐个地把各个模块集成到系统中来。在这种方法中不需要“驱动模块”,需要“桩模块”。 自底向上渐增组装测试:从软件结构的最底层模块开始组装。在这种方法中不需要“桩模块”,需要“驱动模块” 集成测试结束标准: 成功执行了测试计划中规定的所有集成测试 修正了所发现的错误,并成功地进行了再次测试。 所有集成测试文档齐全。 测试结果通过了专门小组的评审。,四、确认测试 确认测试又叫有效性测试或验收测试。任务是按照软件需求规格说明书的要求,验证软件的功能、性能以及其它特性等是否与用户的要求保持一致,并得到用户确认。,1、有效性测试:用黑盒测试法确定软件是否满足需求规格说明书的要求。 2、软件配置复查:保证软件配置的所有成分齐全,并已编排好分类的目录。 3、Alpha测试:在开发环境下由用户进行测试,并作出全面的评价,开发者在场。 4、Beta测试:由用户在软件实际使用环境下进行测试,开发者不在场。 5、测试结果确认,交付相应文档。,五、测试方法 软件测试最基本的方法是黑盒测试法和白盒测试法。 1、黑盒测试法:是基于程序外部功能规格而进行的测试,又叫功能测试法。将待测试的模块当作一个黑盒子,只对模块接口处的输入输出数据进行测试。 黑盒测试一般以程序模块为单位进行,适合于对程序模块的确认测试,系统集成测试和用户验收测试。,2、白盒测试法:是基于程序的内部结构与处理过程而进行的测试,又叫结构测试。白盒测试的内容是程序的内部算法细节。 3、测试中的信息流:,软件测试用例设计,一、白盒测试用例设计 白盒测试用例设计主要采用的是逻辑覆盖,以程序内部逻辑结构为依据的用例设计方法。包括语句覆盖、判断覆盖、条件覆盖、判断条件覆盖、条件组合覆盖、路径覆盖等。,1、语句覆盖:被测程序中每个语句至少执行一次。 测试用例:a=2,b=0,x=4 执行路径:1-2-3-4-5-6-7 2、判定覆盖:不仅被测程序中每个语句至少执行一次,而且每个判定的每种可能的结果至少执行一次。 测试用例: a=3,b=0,x=4 执行路径:1-2-3-4-5-6-7 判断式:T,F a=2,b=1,x=1 执行路径:1-2-4-6-7 判断式:F,T,3、条件覆盖:不仅被测程序中每个语句至少执行一次,而且判定表达式中的每个条件都取到各种可能的结果。 用例: a=2,b=0,x=4 执行路径:1-2-3-4-5-6-7 条件式:T,T,T,T a=1,b=1,x=1 执行路径:1-2-4-5-6-7 条件式:F,F,F,F,二、黑盒测试用例设计 1、等价类划分:把所有可能的输入数据划分出若干个等价类,每个等价类中的一个典型值在测试过程中与该等价类中所有的其它值的作用相同。 如输入百分制的成绩,输出等级制成绩。 录入数据100 测试结果:无效成绩 录入数据0 测试结果:无效成绩 0=录入数据60 测试结果:不及格 60=录入数据70 测试结果:及格 70=录入数据80 测试结果:中 80=录入数据90 测试结果:良 90=录入数据100 测试结果:优 测试用例:102,10,30,65,74,86,93,2、边界类分析:在边界处设计专门的测试用例,用于验证程序运行在边界时是否发生错误。 如根据上例可设计测试用例为: 1,0,59,60,69,70,79,80,89,90,100,101 3、错误推测:测试人员凭借测试经验和直觉,例举出程序中可能有的错误和容易发生错误的特殊情况来选择测试用例。,面向对象测试,1、面向对象单元测试 此时的“单元”不再是程序模块的概念,而是以类为单位,把操作作为类的一部分进行测试 2、面向对象集成测试 (1)基于线程的测试:把响应系统的一个事件所需要的一组类集成为一个线程,分别集成并测试每个线程,同时进行回归测试。 (2)基于使用的测试:先测试独立类,再按层次测试依赖类,直到构造出整个系统。 3、面向对象确认测试 测试的主要内容是用户可见的动作和用户可识别的输出,不需考虑类的构造及类之间的联系。,软件调试,软件调试也叫排错,涉及两个步骤: 1、诊断:确定错误的位置和性质。 2、排错:修改程序,改正错误。 一、调试方法 1、输出存储器内容。 2、在程序中插入输入输出语句。 3、使用自动调试工具。 二、调试策略 1、试探法:猜测故障可能的大致位置进行试探,以获得程序错误的准确定位。 2、回溯法:确定最先发现错误的位置,沿程序控制流程往回追踪源程序代码,找出程序错误的准确位置。 3、对分查找法:与二分查找排序算法一致。 4、归纳法:以程序的错误征兆为线索,分析这些线索之间的关系,找出故障。 5、演绎法:先列出所有可能成立的原因或假设,逐个排除。,自动测试工具,常见的自动测试工具: 1、测试数据生成程序 2、动态分析程序 3、静态分析程序 4、模块测试程序 5、集成环境测试,软件可靠性评估,一、可靠性概念 1、软件可靠性:在给定的时间间隔内,程序按照规格说明书成功运行的概率。 2、软件可用性:在给定的时间点,程序按照规格说明书成功运行的概率。 一般使用稳态可用性对系统进行评估: Ass=MTTF/(MTTF+MTTR) MTTF为系统平均无故障时间, MTTR为系统平均维修时间。 估算系统平均无故障时间及系统故障总数略。,软件维护,软件维护的概念 软件可维护性 软件维护的实施 对老化系统的维护 逆向工程与再工程 软件配置管理,软件维护的概念,软件维护的定义 影响维护工作量的因素 结构化维护与非结构化维护 维护成本,软件维护的定义,在软件运行维护阶段对软件产品进行的修改就是所谓的维护。 维护的类型有三种: 改正性维护 适应性维护 完善性维护,改正性维护,在软件交付使用后,因开发时测试的不彻底、不完全,必然会有部分隐藏的错误遗留到运行阶段。 这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。 为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用,应当进行的诊断和改正错误的过程就叫做改正性维护。,适应性维护,在使用过程中, 外部环境(新的硬、软件配置) 数据环境(数据库、数据格式、数据输入/输出方式、数据存储介质) 可能发生变化。 为使软件适应这种变化,而去修改软件的过程就叫做适应性维护。,完善性维护,在软件的使用过程中,用户往往会对软件提出新的功能与性能要求。 为了满足这些要求,需要修改或再开发软件,以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。 这种情况下进行的维护活动叫做完善性维护。,实践表明,在几种维护活动中,完善性维护所占的比重最大。即大部分维护工作是改变和加强软件,而不是纠错。 完善性维护不一定是救火式的紧急维修,而可以是有计划、有预谋的一种再开发活动。 事实证明,来自用户要求扩充、加强软件功能、性能的维护活动约占整个维护工作的50。,在整个软件维护阶段所花费的全部工作量中,完善性维护占了几乎一半的工作量。 软件维护活动所花费的工作占整个生存期工作量的70%以上,这是由于在漫长的软件运行过程中需要不断对软件进行修改,以改正新发现的错误、适应新的环境和用户新的要求,这些修改需要花费很多精力和时间,而且有时会引入新的错误。,影响维护工作量的因素,在软件的维护过程中,需要花费大量的工作量,从而直接影响了软件维护的成本。 应当考虑有哪些因素影响软件维护的工作量,相应应该采取什么维护策略,才能有效地维护软件并控制维护的成本。,系统大小:系统越大,理解掌握起来越困难。系统越大,所执行功能越复杂。因而需要更多的维护工作量。 程序设计语言:使用强功能的程序设计语言可以控制程序的规模。语言的功能越强,生成程序的模块化和结构化程度越高,所需的指令数就越少,程序的可读性越好。,系统年龄: 老系统随着不断的修改,结构越来越乱; 维护人员经常更换,程序又变得越来越难于理解。 许多老系统在当初并未按照软件工程的要求进行开发,因而没有文档,或文档太少。 在长期的维护过程中文档在许多地方与程序实现变得不一致,在维护时就会遇到很大困难。,数据库技术的应用:使用数据库,可以简单而有效地管理和存储用户程序中的数据,还可以减少生成用户报表应用软件的维护工作量。 先进的软件开发技术:在软件开发时,若使用能使软件结构比较稳定的分析与设计技术,及程序设计技术,如面向对象技术、复用技术等,可减少大量的工作量。,其它: 应用的类型 数学模型 任务的难度 开关与标记、IF嵌套深度、索引或下标数等 对维护工作量都有影响。 许多软件在开发时并未考虑将来的修改,为软件的维护带来许多问题。,结构化维护与非结构化维护,非结构化维护非结构化维护往往与早期的软件开发非工程化有关,是软件开发过程中没有按照软件工程原则实施软件开发留下的后遗症。 结构化维护 结构化维护是一种依靠完整的软件配置而进行的维护,其中的软件配置包括源程序清单、维护计划以及软件工程过程各阶段产生的文档。,维护成本,有形的软件维护成本是花费了多少钱,无形的维护成本有更大的影响。 一些合理的修复或修改请求不能及时安排,使得客户不满意; 变更的结果引入新的故障,使得软件整体质量下降; 把软件人员抽调到维护工作中,干扰了软件开发工作。,软件维护的代价是降低了生产率,在做老程序的维护时非常明显。 例如,开发每一行源代码耗资25美元,维护每一行源代码需要耗资1000美元。 维护工作量包括生产性活动(如分析和评价、设计修改和实现)和非生产性活动(如试图理解代码在做什么、试图判明数据结构、接口特性、性能界限等)。,维护工作量的模型,M是维护中消耗的总工作量 p是上面描述的生产性工作量 K是一个经验常数 c是因缺乏好的设计和文档而导致复杂性的度量 d是对软件熟悉程度的度量。,软件可维护性,软件可维护性是指纠正软件系统出现的错误和缺陷,以及为满足新的要求进行修改、扩充或压缩的难易程度。 可维护性、可使用性、可靠性是衡量软件质量的主要质量特性,也是用户十分关心的几个方面。 软件的可维护性是软件开发阶段各个时期的关键目标。,目前广泛使用的是用如下的七个特性来衡量程序的可维护性。 可理解性:阅读源程序和相关文档的难易程度。 可使用性:指对用户而言,程序的方便、实用和易于使用的程度。 可测试性:诊断程序错误的难易程度 可移植性:程序转移到新的环境的可能性的大小。 可修改性:程序修改的难易程度。 运行效率:执行预定功能而不浪费机器资源的程度。 可靠性:在给定的时间段内正确运行的概率。,在各类维护中的侧重点,软件维护的实施,为了有效地进行软件维护,应事先就开始做组织工作。 首先建立维护的机构 申明提出维护申请报告的过程及评价的过程 为每一个维护申请规定标准的处理步骤 建立维护活动的登记制度以及规定评价和评审的标准。,维护机构,除了较大的软件开发公司外,通常在软件维护工作方面,并不保持一个正式的组织机构。 虽然不要求建立一个正式的维护机构,但是在开发部门确立一个非正式的维护机构则是非常必要的。,软件维护的机构,软件维护申请报告,维护申请报告或称软件问题报告,由申请维护的用户填写。 用户必须完整地说明产生错误的情况,包括输入数据、错误清单以及其它有关材料。 如果申请的是适应性维护或完善性维护,用户必须提出一份修改说明书,列出所有希望的修改。,维护申请报告将由维护管理员和系统监督员来研究处理。 他们应相应地做出软件修改报告,指明: 所需修改变动的性质; 申请修改的优先级; 为满足某个维护申请报告,所需的工作量; 预计修改后的状况.,软件维护工作流程,维护档案记录,程序名称 源程序语句条数 机器代码指令条数 所用的程序设计语言 程序安装的日期 程序安装后的运行次数 与程序安装后运行次数有关的处理故障次数,程序改变的层次及名称 修改程序增加的源程序语句条数 修改程序减少的源程序语句条数 每次修改所付出的“人时”数 修改程序的日期 软件维护人员的姓名 维护申请报告的名称、维护类型 维护开始时间和维护结束时间、 花费在维护上的累计“人时”数 维护工作的净收益等。,维护评价,评价维护活动比较困难,因为缺乏可靠的数据。 如果维护的档案记录做得比较好,可以得出一些维护“性能”方面的度量值。 每次程序运行时的平均出错次数; 花费在每类维护上的总“人时”数;,每个程序、每种语言、每种维护类型的程序平均修改次数; 因为维护,增加或删除每个源程序语句所花费的平均“人时”数; 用于每种语言的平均“人时”数; 维护申请报告的平均处理时间; 各类维护申请的百分比。 据此可对开发技术、语言选择、维护工作计划、资源分配、以及其它许多方面做出判定。,对老化系统的维护,老化系统是指使用早期程序设计语言(FORTRAN, COBOL)开发的系统,结构差,文档不完整,没有保存之前的修改记录。 对于老化的系统,维护非常困难,Yourdon提出以下建议。 研究程序使用环境和有关资料,得到更多背景信息。 熟悉程序所有的控制流程。 评价现有文档的可用性。 充分利用交叉引用表、符号表提供的交叉引用信息。,必须非常谨慎地对程序进行修改。 确认不再使用的代码才可以删除。 不要共享程序已有的临时变量或工作区。 保持详细的维护活动和维护结果记录。 如果程序结构混乱,可抛弃程序重新编写。 插入出错检验。,逆向工程与再生工程,逆向工程:由源程序导出系统高层模型的过程。与软件开发的过程相反。 再生工程:用于重新构造或重新生成老化系统的逆向工程。,软件配置管理,软件配置管理是一组针对软件产品的追踪和控制活动,贯穿于软件生命周期的始终。 软件配置管理由以下几个部分组成: 计算机程序 数据结构 描述计算机程序的文档,软件配置管理的任务,一、配置标识 为了方便对软件配置的各个片段进行控制和管理,不致造成混乱,首先应给它们命名。通常需要标识的对象:基本对象和复合对象。每个对象可用一组信息来唯一地标识它,这组信息包括名字、描述、资源、实现等内容。 基本对象:是由软件工程师在分析、设计、编码和测试时所建立的文本单元。 复合对象:是基本对象或其它复合对象的一个收集。,二、变更控制 软件工程过程中某一阶段的变更,均要引起软件配置的变更,这种变更必须严格加以控制和管理,保持修改信息。 变更控制包括建立控制点和建立报告与审查制度。 软件变更有两类不同情况: 为改正小错误需要的变更。 为了增加或者删掉某些功能、或者为了改变完成某个功能的方法而需要的变更。,三、版本控制 版本控制是SCM的基础,它管理并保护开发者的软件资源。 版本控制管理在软件工程过程中建立起配置对象的不同版本。 使用演变图来表示系统的不同版本。,
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 图纸专区 > 课件教案


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!