搜索
1第三章集成测试3.1基本概念3.2集成测试目的3.3集成测试层次3.4集成测试方法3.5集成静态测试3.6集成策略3.7集成测试流程3.8案例分析23.1基本概念定义集成测试又称组装测试、联合测试、子系统测试或部件测试。集成测试是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成子系统或系统进行的测试活动。单元测试完成后便进入集成测试阶段。33.1.1集成测试与单元测试的区别测试对象有所区别;集成测试关注的是模块间的接口，接口之间的数据传递关系，单元组合后是否实现预计的功能。集成测试组装的对象比单元测试的对象级别要高。43.1.2集成测试与系统测试的区别系统测试对象是整个系统以及与系统交互的硬件和软件平台。系统测试更多程度上是站在用户的角度上对系统做功能性的验证，同时还对系统进行一些非功能性的验证，包括系统测试测试、压力测试、安全性测试、恢复性测试等。系统测试的依据来自用户的需求规格说明书和行业的已成文的或事实上的标准。集成测试所测试的对象是模块间的接口，其目的是要找出在模块接口上面，包括整体体系结构上的问题。其测试的依据来自系统的高层设计（架构设计或概要设计）。软件的集成测试工作最好由不属于该软件开发组的软件设计人员承担，以提高集成测试的效果。53.2集成测试目的在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失；一个模块的功能是否会对另一个模块的功能产生不利的影响；各个子功能组合起来，能否达到预期要求的父功能；全局数据结构是否有问题；单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。63.3集成测试的层次子系统内集成测试(模块)子系统间集成测试(可执行程序)73.3集成测试的层次模块与子系统的区别例子配用电监测与管理系统由很多个子系统组成，如通讯子系统、数据采集子系统、报警服务子系统、前置机应用子系统等。而每个子系统又由多个功能模块组成，如数据采集子系统由档案参数模块、任务处理模块、规约解析模块等组成83.3集成测试的层次档案参数模块TCP通讯模块规约过滤模块任务处理模块规约解析模块数据库输出模块数据库接口通讯日志,文件输出93.4集成测试方法静态测试概要设计的测试动态测试黑盒测试，但有时候需了解内部细节并结合白盒测试，所以更多的资料将黑盒和白盒相结合的测试称为灰盒测试。集成测试的依据是需求规格说明书、概要设计及详细设计说明书。103.5集成静态测试测试内容主要测试概要设计同需求的一致性，以及概要设计的合理性。测试方法采用同行评审的形式是审查或小组评审概要设计是将软件需求转换为软件的系统体系结构、程序界面和数据结构的过程，及开发语言和工具的选择。因此概要设计的测试主要从这几个方面进行。113.5.1系统体系结构设计测试体系结构的“4+1”视图描述用例视图:用例视图定义系统的外部行为，是最终用户、分析人员和测试人员所关注的。用例视图定义了系统的功能，是描述系统设计和构建的其它视图的基础，即用例驱动。逻辑视图:逻辑视图描述逻辑结构，该逻辑结构支持用例视图描述的功能，它描述了问题空间中的概念以及实现系统功能的机制，如类（抽象类）、包、子系统等，因而是编程人员最关心的。实现视图:实现描述用于组建系统的物理组件，如可执行文件、DLL、.java文件、.cpp文件代码和数据库等系统程序员所看到的软件产物，是和配置管理以及系统集成相关的信息。进程视图:进程视图描述将系统分解为过程和任务，以及这些并发元素之间的通信与同步。部署视图:描述系统的物理网络布局及程序分布，是系统工程师和网络工程师所感兴趣的。123.5.2数据结构设计测试数据结构设计确定软件涉及的文件系统的结构以及数据库的模式、子模式，进行数据完整性和安全性的设计。它包括：确定输入、输出文件的详细的数据结构；结合算法设计，确定算法所必须的逻辑数据结构及操作；内部模块之间的接口数据格式设计数据库设计合理性。具体数据库设计合理性见数据库相关专业书籍。数据结构设计测试主要依据以上标准。133.5.3程序界面设计测试目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。规则143.5.4开发语言和工具选择与当前主流技术一致性；与公司目前掌握技术一致性；对客户业务满足性15概要设计检查单例子163.6集成策略集成策略就是在测试对象分析的基础上，描述软件模块集成（组装）的方式、方法。集成的基本策略比较多，分类比较复杂，但不管怎样分，所以分类分类方法都可以归结为非增值式和增值式两大类，其余的很多方法都是在此基础上的细分。173.6.1非增值式策略先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序。优点：一是方法简单，二是允许多个测试人员并行工作，对人力、物力资源利用率较高。缺点：必须为每个模块准备相应的驱动模块和辅助桩模块，故测试成本较高；其次，一旦集成后的系统包含多种错误，难以对错误定位和纠正。183.6.2增值式策略这种集成方式又称渐增式组装。首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。通过增值逐步组装成为要求的软件系统。相对非增值式策略，可以较早发现模块间的接口错误；发现问题也易于定位。它的缺点是测试周期比较长，可以同时投入的人力物力受限。193.6.2增值式策略增值方式有两种方式：自顶向下（TopDownTesting）自底向上（BottomUpTesting）20自顶向下（TopDownTesting）从主控模块（“主程序”）开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合起来。这种测试方法不需要驱动模块。在组装过程中，可以使用深度优先的策略，或宽度优先的策略。21自顶向下（TopDownTesting）—深度优先AS1S2S3ABS2S3S4ABS2S3EABCS3ES5ABCDES5ABCDEF测试A加入B加入E加入C加入D加入F22自顶向下（TopDownTesting）—宽度优先AS1S2S3ABS2S3S4ABCS3S4ABCDS4S5ABCDES5ABCDEF测试A加入B加入C加入D加入E加入F23自顶向下（TopDownTesting）步骤：对主控模块进行测试，测试时用存根程序代替所有直接附属于主控模块的模块根据选定的结合策略（深度优先或宽度优先），每次用一个实际模块代替一个存根程序（新结合进来的模块往往又需要新的存根程序）在结合下一个模块的同时进行测试为了保证加入模块没有引进新的错误，可能需要进行回归测试（即，全部或部分地重复以前做过的测试）从第2步开始不断地重复进行上述过程，直至完成。24自底向上（BottomUpTesting）这种组装的方式是从程序模块结构的最底层的模块开始组装和测试。25自底向上（BottomUpTesting）具体策略是：把低层模块组合成实现某个特定的软件子功能的族。写一个驱动程序（用于测试的控制程序），协调测试数据的输入和输出。对由模块组成的子功能族进行测试。去掉驱动程序，沿软件结构自下向上移动，把子功能族组合起来形成更大的子功能族。循环(2)-(4)步263.6.2增值式策略自顶向下和自底向上法的比较“自顶向下”法的主要优点：不需要测试驱动程序，能够在测试阶段的早期实现并验证系统的主要功能，而且能在早期发现上层模块的接口错误。“自顶向下”法的主要缺点：需要存根程序，可能遇到与此相联系的测试困难，低层关键模块中的错误发现较晚，而且用这种方法在早期不能充分展开人力。“自底向上”法的优缺点与“自顶向下”法刚好相反。273.6.3混合增值式策略对软件结构中较上层，使用的是“自顶向下”法；对软件结构中较下层，使用的是“自底向上”法，两者相结合283.6.4基于事件（消息）集成策略从验证消息路径的正确性出发，渐增式把系统集成在一起，从而验证系统的稳定性。，面向对象系统中，每个功能路径对应于一系列事件，可以将对应于系统的一个输入或者是事件所需要的类集成到一起，然后分别进行测试。测试的步骤如下：从系统的外部看，分析系统可能输入消息集。选取一条消息，根据序列图或协作图中的事件交互关系，将相关类集成在一起进行测试。选取下一条消息，根据序列图或协作图中的事件交互关系，将相关类集成在一起进行测试。直到所有类都被集成到系统中。主要测试依据是序列图或协作图293.6.5基于使用集成策略针对面向对象系统，通过类之间的使用关系来集成系统，从而验证系统的稳定性。在一个面向对象系统中，存在一些独立的类和一些相互耦合的类。基于使用的集成从分析类之间的依赖关系或包含关系出发，通过最小依赖关系/包含关系的类开始集成，逐步扩大有相互关系的类，最后集成到整个系统。通过该集成方法，可以验证类之间接口的正确性。测试步骤如下：划分类之间耦合关系；测试独立的类；逐步增加具有依赖或包含关系的类（既使用独立类的类），直到构造完整个系统。主要测试依据是类关系图。303.6.6分层集成策略分层模型在通信系统中是很常见的。分层集成就是针对这个特点使用的一种集成策略。系统的层次划分可以通过逻辑的或物理的手段进行。在逻辑上，一般通过功能把系统划分成不同层次的功能单元，功能单元内部具有较高的耦合性，相互之间的关系具有线性层次关系。层次集成可能是自顶向下或自底向上的。一个自顶向下的方法采用下列步骤：首先单独测试每一层。对于顶层而言，需要构造桩；对于底层，需要构造驱动；对于中间层，需要构造驱动和桩。执行层次的自顶向下集成。结果测试包/驱动器应该被设计为可复用/可重运行于随后的集成。在接下来的一层中使用自顶向下的方法。去掉第二层的桩并实现接口。扩充控制测试包以达到所有新实现的构件再运行测试。每层的接口通过以后，去掉所有桩并实现到下一层的接口。313.7集成测试流程集成测试计划集成测试分析与设计集成测试实现集成测试执行集成测试评估软件体系结构初步分析集成测试对象分析集成测试工具开发建立集成测试环境集成测试数据分析关键特性分析集成策略选择集成测试代码开发执行集成测试集成测试评估工作量估计集成测试工具选择和设计集成测试用例开发测试结果记录资源安排集成测试代码设计进度安排集成测试用例设计323.7.1制定集成测试计划集成测试计划应在概要设计阶段完成，一般情况下，概要设计结束并完成评审后一个星期，集成测试计划应完成。集成测试计划的输入有（制定依据）：需求规格说明书；概要设计说明书；产品开发计划书333.7.1制定集成测试计划集成测试计划的内容有：确定集成测试对象和测试范围；确定集成测试阶段性时间进度；确定测试角色和分工；考虑外部技术支援的力度和深度，以及相关培训安排；初步考虑测试环境和所需资源；集成测试活动风险分析和应对；定义测试完成标准；343.7.2集成测试分析和设计集成测试分析和设计的主要目的是制定测试大纲（测试方案）。集成测试大纲规定了今后的集成测试内容、测试方法以及可测性接口，以后所有集成测试均在该大纲的框架下进行，所有，制定一份完善的集成测试大纲非常重要。353.7.2集成测试分析和设计具体工作内容：确定测试需求确定集成策略评估测试风险确定测试优先级确定测试方法集成代码设计集成测试用例设计集成测试工具和资源363.7.2.1测试需求体系结构分析373.7.2.1测试需求确定集成测试层次383.7.2.1测试需求测试对象分析即集成测试模块的划分明显输入输出被集成的几个模块关系紧密，能够完成某种或某部分功能。外围模块便于屏蔽，外围模块与集成模块之间没有太多、太频繁的调用关系，如果实在无法避免，将不得不考虑编写桩程序，以代替被屏蔽部分的功能。模拟外围模块发往被集成模块的消息容易构