集成测试010的课件知识_第1页
集成测试010的课件知识_第2页
集成测试010的课件知识_第3页
集成测试010的课件知识_第4页
集成测试010的课件知识_第5页
已阅读5页,还剩46页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

第三章集成测试3.1基本概念3.2集成测试目的3.3集成测试层次3.4集成测试方法3.5集成静态测试3.6集成策略3.7集成测试流程3.8案例分析13.1基本概念定义集成测试又称组装测试、联合测试、子系统测试或部件测试。集成测试是在单元测试的基础上,将所有模块按照设计要求(如根据结构图)组装成子系统或系统进行的测试活动。单元测试完成后便进入集成测试阶段。23.1.1集成测试与单元测试的区别测试对象有所区别;集成测试关注的是模块间的接口,接口之间的数据传递关系,单元组合后是否实现预计的功能。集成测试组装的对象比单元测试的对象级别要高。33.1.2集成测试与系统测试的区别系统测试对象是整个系统以及与系统交互的硬件和软件平台。系统测试更多程度上是站在用户的角度上对系统做功能性的验证,同时还对系统进行一些非功能性的验证,包括系统测试测试、压力测试、安全性测试、恢复性测试等。系统测试的依据来自用户的需求规格说明书和行业的已成文的或事实上的标准。集成测试所测试的对象是模块间的接口,其目的是要找出在模块接口上面,包括整体体系结构上的问题。其测试的依据来自系统的高层设计(架构设计或概要设计)。软件的集成测试工作最好由不属于该软件开发组的软件设计人员承担,以提高集成测试的效果。43.2集成测试目的在把各个模块连接起来的时侯,穿越模块接口的数据是否会丢失;一个模块的功能是否会对另一个模块的功能产生不利的影响;各个子功能组合起来,能否达到预期要求的父功能;全局数据结构是否有问题;单个模块的误差累积起来,是否会放大,从而达到不能接受的程度。在单元测试的同时可进行集成测试,发现并排除在模块连接中可能出现的问题,最终构成要求的软件系统。53.3集成测试的层次子系统内集成测试(模块)子系统间集成测试(可执行程序)63.3集成测试的层次模块与子系统的区别例子配用电监测与管理系统由很多个子系统组成,如通讯子系统、数据采集子系统、报警服务子系统、前置机应用子系统等。而每个子系统又由多个功能模块组成,如数据采集子系统由档案参数模块、任务处理模块、规约解析模块等组成73.3集成测试的层次83.4集成测试方法静态测试概要设计的测试动态测试黑盒测试,但有时候需了解内部细节并结合白盒测试,所以更多的资料将黑盒和白盒相结合的测试称为灰盒测试。集成测试的依据是需求规格说明书、概要设计及详细设计说明书。93.5集成静态测试测试内容主要测试概要设计同需求的一致性,以及概要设计的合理性。测试方法采用同行评审的形式是审查或小组评审概要设计是将软件需求转换为软件的系统体系结构、程序界面和数据结构的过程,及开发语言和工具的选择。因此概要设计的测试主要从这几个方面进行。103.5.1系统体系结构设计测试体系结构的“4+1”视图描述用例视图:用例视图定义系统的外部行为,是最终用户、分析人员和测试人员所关注的。用例视图定义了系统的功能,是描述系统设计和构建的其它视图的基础,即用例驱动。逻辑视图:逻辑视图描述逻辑结构,该逻辑结构支持用例视图描述的功能,它描述了问题空间中的概念以及实现系统功能的机制,如类(抽象类)、包、子系统等,因而是编程人员最关心的。实现视图:实现描述用于组建系统的物理组件,如可执行文件、DLL、.java文件、.cpp文件代码和数据库等系统程序员所看到的软件产物,是和配置管理以及系统集成相关的信息。进程视图:进程视图描述将系统分解为过程和任务,以及这些并发元素之间的通信与同步。部署视图:描述系统的物理网络布局及程序分布,是系统工程师和网络工程师所感兴趣的。113.5.2数据结构设计测试数据结构设计确定软件涉及的文件系统的结构以及数据库的模式、子模式,进行数据完整性和安全性的设计。它包括:确定输入、输出文件的详细的数据结构;结合算法设计,确定算法所必须的逻辑数据结构及操作;内部模块之间的接口数据格式设计数据库设计合理性。具体数据库设计合理性见数据库相关专业书籍。数据结构设计测试主要依据以上标准。123.5.3程序界面设计测试目前流行的界面风格有三种方式:多窗体、单窗体以及资源管理器风格,无论那种风格,以下规则是应该被重视的。规则133.5.4开发语言和工具选择与当前主流技术一致性;与公司目前掌握技术一致性;对客户业务满足性14概要设计检查单例子153.6集成策略集成策略就是在测试对象分析的基础上,描述软件模块集成(组装)的方式、方法。集成的基本策略比较多,分类比较复杂,但不管怎样分,所以分类分类方法都可以归结为非增值式和增值式两大类,其余的很多方法都是在此基础上的细分。163.6.1非增值式策略先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序。优点:一是方法简单,二是允许多个测试人员并行工作,对人力、物力资源利用率较高。缺点:必须为每个模块准备相应的驱动模块和辅助桩模块,故测试成本较高;其次,一旦集成后的系统包含多种错误,难以对错误定位和纠正。173.6.2增值式策略这种集成方式又称渐增式组装。首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统,在组装的过程中边连接边测试,以发现连接过程中产生的问题。通过增值逐步组装成为要求的软件系统。相对非增值式策略,可以较早发现模块间的接口错误;发现问题也易于定位。它的缺点是测试周期比较长,可以同时投入的人力物力受限。183.6.2增值式策略增值方式有两种方式:自顶向下(TopDownTesting)自底向上(BottomUpTesting)19自顶向下(TopDownTesting)从主控模块(“主程序”)开始,沿着软件的控制层次向下移动,从而逐渐把各个模块结合起来。这种测试方法不需要驱动模块。在组装过程中,可以使用深度优先的策略,或宽度优先的策略。20自顶向下(TopDownTesting)

—深度优先AS1S2S3ABS2S3S4ABS2S3EABCS3ES5ABCDES5ABCDEF测试A加入B加入E加入C加入D加入F21自顶向下(TopDownTesting)

—宽度优先AS1S2S3ABS2S3S4ABCS3S4ABCDS4S5ABCDES5ABCDEF测试A加入B加入C加入D加入E加入F22自顶向下(TopDownTesting)步骤:对主控模块进行测试,测试时用存根程序代替所有直接附属于主控模块的模块根据选定的结合策略(深度优先或宽度优先),每次用一个实际模块代替一个存根程序(新结合进来的模块往往又需要新的存根程序)在结合下一个模块的同时进行测试为了保证加入模块没有引进新的错误,可能需要进行回归测试(即,全部或部分地重复以前做过的测试)从第2步开始不断地重复进行上述过程,直至完成。23自底向上(BottomUpTesting)这种组装的方式是从程序模块结构的最底层的模块开始组装和测试。24自底向上(BottomUpTesting)具体策略是:把低层模块组合成实现某个特定的软件子功能的族。写一个驱动程序(用于测试的控制程序),协调测试数据的输入和输出。对由模块组成的子功能族进行测试。去掉驱动程序,沿软件结构自下向上移动,把子功能族组合起来形成更大的子功能族。循环(2)-(4)步253.6.2增值式策略自顶向下和自底向上法的比较“自顶向下”法的主要优点:不需要测试驱动程序,能够在测试阶段的早期实现并验证系统的主要功能,而且能在早期发现上层模块的接口错误。“自顶向下”法的主要缺点:需要存根程序,可能遇到与此相联系的测试困难,低层关键模块中的错误发现较晚,而且用这种方法在早期不能充分展开人力。“自底向上”法的优缺点与“自顶向下”法刚好相反。263.6.3混合增值式策略对软件结构中较上层,使用的是“自顶向下”法;对软件结构中较下层,使用的是“自底向上”法,两者相结合273.6.4基于事件(消息)集成策略从验证消息路径的正确性出发,渐增式把系统集成在一起,从而验证系统的稳定性。,面向对象系统中,每个功能路径对应于一系列事件,可以将对应于系统的一个输入或者是事件所需要的类集成到一起,然后分别进行测试。测试的步骤如下:从系统的外部看,分析系统可能输入消息集。选取一条消息,根据序列图或协作图中的事件交互关系,将相关类集成在一起进行测试。选取下一条消息,根据序列图或协作图中的事件交互关系,将相关类集成在一起进行测试。直到所有类都被集成到系统中。主要测试依据是序列图或协作图283.6.5基于使用集成策略针对面向对象系统,通过类之间的使用关系来集成系统,从而验证系统的稳定性。在一个面向对象系统中,存在一些独立的类和一些相互耦合的类。基于使用的集成从分析类之间的依赖关系或包含关系出发,通过最小依赖关系/包含关系的类开始集成,逐步扩大有相互关系的类,最后集成到整个系统。通过该集成方法,可以验证类之间接口的正确性。测试步骤如下:划分类之间耦合关系;测试独立的类;逐步增加具有依赖或包含关系的类(既使用独立类的类),直到构造完整个系统。主要测试依据是类关系图。293.6.6分层集成策略分层模型在通信系统中是很常见的。分层集成就是针对这个特点使用的一种集成策略。系统的层次划分可以通过逻辑的或物理的手段进行。在逻辑上,一般通过功能把系统划分成不同层次的功能单元,功能单元内部具有较高的耦合性,相互之间的关系具有线性层次关系。层次集成可能是自顶向下或自底向上的。一个自顶向下的方法采用下列步骤:首先单独测试每一层。对于顶层而言,需要构造桩;对于底层,需要构造驱动;对于中间层,需要构造驱动和桩。执行层次的自顶向下集成。结果测试包/驱动器应该被设计为可复用/可重运行于随后的集成。在接下来的一层中使用自顶向下的方法。去掉第二层的桩并实现接口。扩充控制测试包以达到所有新实现的构件再运行测试。每层的接口通过以后,去掉所有桩并实现到下一层的接口。303.7集成测试流程集成测试计划集成测试分析与设计集成测试实现集成测试执行集成测试评估软件体系结构初步分析集成测试对象分析集成测试工具开发建立集成测试环境集成测试数据分析关键特性分析集成策略选择集成测试代码开发执行集成测试集成测试评估工作量估计集成测试工具选择和设计集成测试用例开发测试结果记录资源安排集成测试代码设计进度安排集成测试用例设计313.7.1制定集成测试计划集成测试计划应在概要设计阶段完成,一般情况下,概要设计结束并完成评审后一个星期,集成测试计划应完成。集成测试计划的输入有(制定依据):需求规格说明书;概要设计说明书;产品开发计划书323.7.1制定集成测试计划集成测试计划的内容有:确定集成测试对象和测试范围;确定集成测试阶段性时间进度;确定测试角色和分工;考虑外部技术支援的力度和深度,以及相关培训安排;初步考虑测试环境和所需资源;集成测试活动风险分析和应对;定义测试完成标准;333.7.2集成测试分析和设计集成测试分析和设计的主要目的是制定测试大纲(测试方案)。集成测试大纲规定了今后的集成测试内容、测试方法以及可测性接口,以后所有集成测试均在该大纲的框架下进行,所有,制定一份完善的集成测试大纲非常重要。343.7.2集成测试分析和设计具体工作内容:确定测试需求确定集成策略评估测试风险确定测试优先级确定测试方法集成代码设计集成测试用例设计集成测试工具和资源353.7.2.1测试需求体系结构分析363.7.2.1测试需求确定集成测试层次373.7.2.1测试需求测试对象分析即集成测试模块的划分明显输入输出被集成的几个模块关系紧密,能够完成某种或某部分功能。外围模块便于屏蔽,外围模块与集成模块之间没有太多、太频繁的调用关系,如果实在无法避免,将不得不考虑编写桩程序,以代替被屏蔽部分的功能。模拟外围模块发往被集成模块的消息容易构造,修改。外围模块发往被测试模块的消息能够模拟大部分实际情况。

383.7.2.1测试需求集成测试接口的确定接口的划分。接口的划分是以概要设计为基础的,其方法与相关的结构设计技术类似。一般可以通过下面几个步骤来完成:确定系统的边界、子系统(进程)边界和模块的边界;确定模块内部的边界;确定子系统内模块间接口;确定子系统(进程)间接口;确定系统与操作系统的接口;确定系统与硬件的接口;确定系统与第三方软件的接口。393.7.2.1测试需求集成测试接口的确定(续)接口的分类。主要包括以下几种:函数接口。通过函数的调用和别调用关系来确定。关于函数接口的集成测试比较成熟。类接口。在面向对象的系统中,类接口是最基本的接口。类接口一般可以通过继承、参数类、不同类方法调用等策略来实现。组件接口。这类组件主要通过ORB(对象请求代理)来相互交换信息。ORB是一种中间件技术,负责管理和支持分布式对象或组件之间的通信。ORB有三个主要的标准:a)OMGCORBA标准;b)JavaRMI和RMI-IIOP;c)MicrosoftCOM/DCOM/COM+。Webservice:子系统(进程)间的接口。这类接口主要有:a)中间文件;b)数据库;c)socketd)消息队列;e)管道;f)信号;g)信号量;h)共享内存;i)远程过程调用等。403.7.2.2确定集成策略主要依据软件体系结构分析来选择合适的集成策略。一个好的集成策略应该具有以下特点:使被测对象能够得到比较充分的测试,尤其是其包含的关键特性。能够使模块与接口的划分清晰明了,尽可能减少后继操作难度,同时使需要做的辅助工作量最小;整体工作量对于投入测试的资源来说大致相当,参加测试的人力、环境、时间等资源能够得到充分利用。413.7.2.2确定集成策略对于面向对象设计技术的程序,选择策略的大体思路是:第一种称为基于序列图的测试,将对应系统的一个功能的一个输入或者是事件所需要的类集成在一起,然后分别测试;第二种称为基于使用的测试,首先测试那些独立类,然后将那些与独立类的依赖类集成进来测试一直到构造整个系统。在这个测试过程中尽量使用真实代码完成操作而不是使用测试代码来替代真实操作。423.7.2.2

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论