2软件测试生命周期和测试模型PPT文件格式下载.ppt

2软件测试生命周期和测试模型PPT文件格式下载.ppt

《2软件测试生命周期和测试模型PPT文件格式下载.ppt》由会员分享，可在线阅读，更多相关《2软件测试生命周期和测试模型PPT文件格式下载.ppt（39页珍藏版）》请在冰豆网上搜索。

开的软件可靠高。

高可靠性,按时交付高性能,人,类,软,件,软件生命周期什么是软件生命周期？

软件生命周期是软件工程中非常重要的概念。

软件生命周期：

是指软件开发和测试全部过程、活动和任务的结构框架，是从可行性研究到需求分析、软件设计、编码、测试、发布后的维护的过程。

一个软件项目的生命周期和人类的生命周期的类比如图,出生可行性研究需求分析,儿童少年设计、编码、测试,青年、中年、老年软件发布维护,死亡淘汰,软件生命周期要素需求分析:

根据客户的要求，清楚了解客户需求中的产品功能、特性、性能、界面和具体规格等，然后进行分析，确定软件产品所能达到的目标。

设计:

根据需求分析的结果，考虑如何在逻辑、程序上去实现所定义的产品功能、特性等，可以分为概要设计和详细设计，也可分为数据结构设计、软件体系结构设计、应用接口设计、模块设计、界面设计等。

编程:

将设计转换成计算机可识别的指令。

测试:

对设计、编程进行验证和用户需求确认的过程维护：

维持软件运行，修改软件缺陷、增强已有功能、增加新功能、升级等。

软件开发的生命周期软件开发的生命周期，也叫软件开发流程，是指软件的开发过程中需要经过哪些环节。

软件开发的生命周期如图所示：

需求分析,概要设计,详细设计,编码,维护,软件开发过程开发人员构建产品Softwaredefect,“bug”FixedbugBugintroducedasaresultoffixinganotherbug,Coding,Lock-downTest&

Stabilize,Release,软件开发过程模型思考&

测试切入点,在软件开发的几十年实践中，人们总结了很多模型，如：

瀑布模型、快速原型模型、螺旋模型、RUP等一系列的模型；

这些模型对于软件开发过程具有很好的指导作用，但是非常遗憾的是，在这些过程方法中，并没有充分强调测试的价值，也没有给测试以足够的重视。

瀑布模型,切入点,线性模型：

1.占有重要的地位，是所有其他模型的一个基础。

2.瀑布模型每一个阶段执行一次次，按线性顺序进行的软件开发。

测试的切入点：

测试阶段处于软件实现后，必须在代码完成后留出足够的时间预留给测试活动，否则将导致测试不充分，很多问题到用户使用时才爆发。

瀑布模型,瀑布模型的优点：

开发的各个阶段比较清晰。

强调早期计划及需求调查。

适合需求稳定的产品开发。

前面未发现的错误会传递并扩散到后面的阶段，可能导致项目失败。

瀑布模型的缺点：

依赖于早期的需求调查，不适应需求的变化。

单一流程不可逆。

风险往往迟至后期才显露，失去及早纠正的机会。

测试仅是编码的一个阶段。

改良：

沿用瀑布模型的线性思想，细化了各个阶段，在某些重要关注的阶段之间掺入迭代的思想,原,型,的,表,示,原,型,的,使,用,快速原型模型快速原型模型：

在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。

第一步是建造一个快速原型，实现用户与系统的交互，用户对原型进行评价，进一步细化待开发软件的需求。

通过逐步调整原型使其满足用户的要求，开发人员可以确定用户的真正需求是什么；

第二步则在第一步的基础上开发出用户满意的软件产品。

快速分析,快速分析评价,构造运行,需求说明构造原型原型运行原型评价原型修改意见,快速原型模型,快速原型模型的优点：

较短的开发过程。

更好的满足用户的需求并减少项目失败的风险。

用户对新系统更容易、更快的理解。

快速原型的缺点：

减少对更改和增补的灵活性和适应性。

减少对非预期失败情况的准备。

不适合大型系统的开发（适合开发小型的、灵活性高的系统）,快速原型模型分类,快速原型模型又可分为增量模型、渐进模型、演化模型,增量模型：

对于需求不能很快全部明确的系统，软件开发项目难于做到一次开发成功，此时可以使用增量模型。

应尽可能明确已知的需求，完成相应的需求分析，并按瀑布模型的方法进行第一次的开发工作。

在系统集成时，通过实验找出需求中的欠缺和不足，明确那些未知的软件需求，再迭代进行部分分析和开发。

渐进模型：

此模型主要是针对部分需求尽管明确，但一时难以准确进行定义的系统设计，如用户的操作界面等。

使用此模型时，可以先做初步的需求分析，之后立即进行设计和编码，随后与系统进行第一次集成。

根据集成后反映的问题进一步做更全面的需求分析、设计、编码、测试。

演化模型：

是一种非整体开发的模型。

软件在该模型中是“逐渐”开发出来的，开发出一部分，向用展示一部分，可让用户及早看到部分软件，及早发现问题，也可以先开发一个原型软件，完成部分主要功能，展示给用户并征求用户的意见，然后逐步完善，最终获得满意的软件产品。

演化模型具有较大的灵活性，适合于软件需求不明确，设计方案有一定风险的软件。

出一个核心的系统（游戏引擎）,螺旋模型,螺旋模型将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析。

之所以叫螺旋模型，是因为这是一个迭代开发的过程，每一个迭代均由需求、设计、编码、集成等阶段组成。

实际上这个模型可看作是重复执行的多个“瀑布模型”，并在“瀑布模型”的每一个阶段之前，引入非常严格的风险控制。

直到消除风险之后，才开始下一阶段的开发工作。

很多软件公司在开发游戏软件时都采用了螺旋模型特的思想，首先开发个核心的系统（游戏引擎），然后再逐渐添加新的游戏场景，每每一次都,是一轮小的循环。

螺旋模型适合于大型软件的开发。

螺旋模型,螺旋模型将开过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，螺旋模型沿着螺旋线旋转，即在笛卡乐坐标的4个象限上分别表达了4个方面的活动，如图所示：

制定计划风险分析实施开发客户评估,螺旋模型,螺旋模型的优点：

螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

螺旋模型的缺点：

采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中,如果未能够及时标识风险，势必造成重大损失。

过多的迭代次数会增加开发成本，延迟提交时间。

RUP模型,RUP：

RationalUnifiedProcess（rational统一过程）RUP动态结构：

初识阶段细化阶段构造阶段移交阶段,思考：

XP.,XP-extremeProgramming极限编程,最简单的可能就是最有效的极限编程适合,小团队（2-10programmers）高风险,快速变化或不稳定的需求强调可测试性,格言,“沟通、简化、反馈、激励”,KentBeck,XP-eXtremeProgramming极限编程,XP注重人的因数，提倡尽量敏捷轻量级的过程。

重要过程：

测试驱动、迭代开发、持续集成构建、客户现场参与（确定迭代内的功能集，提供业务逻辑的确认，验证程序等）、只在必要时做简单设计,XP的缺点：

要求客户现场参与。

通常国内项目都是前期作需求确认，无法提供整个开,发过程的需求确认支持。

除非是分段来确认（如迭代结束时）。

测试驱动开发。

目前还很难做到，因为编写测试脚本需要花费不少精力，一般项目无法做到。

由此也无法作重构，无法保证能有灵活的设计来支持因前期不明确的需求而导致的变更。

缺少文档、设计支持。

Xp只在必要时才写文档及设计，这样可能导致xp新,手缺乏良好的设计指引，项目开发过程透明度不够，可能会失控。

XP可借鉴的地方,对整个开发过程：

迭代开发、持续集成,对特定迭代：

编码规范、保持设计灵活（允许需求改动）,设计编码过程：

测试驱动、重构（用在编码过程中，以客户端来“测试驱,动”业务逻辑层、以重构减少重复代码）,软件测试&

软件工程,软件测试与软件工程息息相关，软件测试是软件工程组成中,不可或缺的一部分。

在软件工程、项目管理、质量管理得到规范化应用的企业，软件测试也会进行得比较顺利，软件测试发挥的价值也会更大。

要关注软件工程、质量管理以及配置管理与软件测试的关系；

在不同的开发模式下，如何进行软件测试。

软件测试的生命周期刚才的软件开发流程中根本没有提及测试，那么在软件开发的每一个环节中，需要做哪能些测试工作呢？

测试生命周期如图：

测试需求,测试计划,测试设计,测试执行,测试评估,测试模型思考?

软件测试虽然较软件开发的发展时间短，但是也已经总结了很多模型了。

我们常见的有：

V模型、W模型、H模型、X模型等。

当然由于测试与开发的结合非常紧密，在这些测试模型中也都把开发过程进行了很好的总结，体现了测试与开发的融合。

那么测试的过程和软件开发的过程一样么？

是否有很多的看上去很专业，似乎很有内涵的模型呢？

V模型诞生,V模型是最具有代表意义的测试模型；

V模型最早是由PaulRook在20世纪80年代后期提出，由英国国家计算机中心文献中发布，旨在改进软件开发的效率和效果；

V模型推出的时代背景：

在V模型推出之前，人们通常把测试过程作为在需求分析、概要设计、详细设计、编码全部完成之后的一个阶段，尽管当时已经出现了测试工作会占用这个项目周期一半的时间，但是大多数人认为测试只是一个收尾工作；

V模型在这个时候推出，就是为了改进之前行业的普遍认识。

V模型本身是软件开发中，瀑布模型的变种，它反映了测试活动与分析和设计的关系。

V模型标明了测试过程中本身存在的不同阶段，从左到右，描述了开发过程和测试过程间的阶段对应关系。

V模型V模型从左至右，将开发和测试,两个大阶段分开，形成V字形。

单元测试所检测代码的开发是否符合详细设计的要求。

集成测试所检测此前测试过的各组成部分是否能完好地结合到一起。

系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。

验收测试则检测产品是否符合最终用户的需求。

用户需求规格说明书概要设计详细设计编码,验收测试系统测试集成测试单元测试,测试计划,V模型（改进）,需求分析定义,确认需求客户、市场、产品人员,测试目标,验收测试黑盒方法测试,系统、结构设计,工程师、技术人员系统测试设计和环境技术实现,系统测试灰盒方法测试,详细或程序设计,功能测试用例设计,功能测试,分析/设计复审（静态测试）,编码,单元测试,检验、动态测试,白盒方法测试,V模型优缺点,V模型的优点：

开发V模型即包含了底层测试又包含了高层测试；

底层测试：

检验源代码质量的测试，如：

单元测试；

高层测试：

检验整个系统的需要，如：

系统测试；

V模型清楚地标识出了软件开发的阶段。

它采用自顶向下逐步求精的方式把整个开发过程分成不同的阶段，每个阶段的工作都很明确，因此便于控制开发过程。

当所有的阶段都完成之后，该软件的开发过程也随之结束。

V模型的缺点：

V模型仅仅把测试过程作为在需求分析、概要设计、详细设计以及编码之后的一个阶段，容易使人误解测试是软件开发的最后一个阶段，是软件开发的从属。

V模型的另一个大缺点正是它自身的顺序性所导致的。

到了测试阶段，程序已经完成，错误已经产生，很多前期的错误一直到测试阶段才发现，甚至无法发现，往往无从修改了。

同时实际的开发过程中，在需求阶段很难把用户的需求完全明确下来，因此，当需求变更时将会导致阶段反复，而且都要重复需求、设计、编码、测试等过程，返工量非常大，