软件集成测试培训教材

软件集成测试培训课程目标了解集成测试的概念掌握集成测试的基本思路和方法课程内容集成测试介绍集成测试分析集成测试策略集成测试过程集成测试环境什么是集成测试集成测试（IntegrationTesting），也叫组装测试、联合测试、子系统测试或部件测试。集成测试是在单元测试的基础上，将所有模块按照概要设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。也就是说，在集成测试之前，单元测试已经完成，并且集成测试所使用的对象应当是已经经过单元测试保证了的单元，如果不经过单元测试，那么集成测试的效果将受到影响，并且会付出更大的代价，单元测试和集成测试所关注的范围是不同的，因此，它们在发现问题的集合上包含有不相交的区域，你不能使用单元测试来替代集成测试，反之也是一样。集成测试和系统测试的区别系统测试所测试的对象是整个系统以及与系统交互的硬件和软件平台。系统测试更多程度上是站在用户的角度上对系统做功能性的验证，同时还对系统进行一些非功能性的验证，包括性能测试、压力测试、容量测试、安全性测试、恢复性测试等等。系统测试的依据来自于用户的需求规格说明书和行业的已成文的或事实上的标准。集成测试所测试的对象是模块间的接口，其目的是要找出在模块接口上面，包括整体体系结构上的问题。其测试的依据来自于系统的高层设计（构架设计）。集成测试关注的重点实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。因此集成测试应当考虑以下问题：在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失。各个子功能组合起来，能否达到预期要求的父功能。一个模块的功能是否会对另一个模块的功能产生不利的影响。全局数据结构是否有问题，会不会被异常修改。单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。因此，单元测试后，有必要进行集成测试，发现并排除在模块连接中可能发生的上述问题，最终构成要求的软件子系统或系统。集成测试和开发的关系集成测试是与软件开发的概要设计阶段相对应的，软件概要设计中关于整个系统的体系结构是集成测试的输入基础。体系结构是把一个大的系统组织成为可以管理的和可实现的组件或子系统的结构。它服务于很多目标，包括风险管理，进度和验证。Booch认为集成是面向对象开发中最关键的活动。其实即使在结构化设计中，集成也是同样重要的。集成测试与构架设计之间具有相互的依赖性。如果构架设计不明确，集成测试设计将无法很好的完成。同样集成测试可以用来发现构架设计中的错误、遗漏和二义性问题，包括前期的验证活动和后期的确认测试。集成测试的层次一个产品的开发过程包括了一个分层的设计和逐步细化的过程，从最初的产品到最小的单元。该层次大致可以通过下图表示出来。A产品子系统1子系统2硬件子系统1硬件子系统2软件子系统1软件子系统2软件子系统3系统结构图软件子系统1软件子系统2软件模块1软件模块2软件模块2软件模块3软件模块4软件结构图课程内容集成测试介绍集成测试分析集成测试策略集成测试过程集成测试环境集成测试分析要做好集成测试，必须加强集成测试的分析工作。类似于概要设计对详细设计的作用，集成测试分析直接指导了集成测试用例的设计，并且在整个集成测试过程中占据了最关键的地位。体系结构分析体系结构的分析需要从两个角度出发，首先从需求的跟踪实现出发，划分出系统实现上的结构层次图形。结构图对集成的层次考虑是由帮助的。其次需要划分系统组件之间的依赖关系图，如下图所示。通过该图的分析，需要划分出集成测试的粒度，即基础模块的大小。集成测试模块的划分是一件头疼的事，模块划分到底要多大？需不需要设计驱动和桩？该模块的划分是不是可以有效降低消息接口的复杂性？接口是否充分等？模块划分的好，可以极大提高集成测试的效率，反之则会降低集成测试的质量。关于模块的划分请参考下一节。体系结构的分析还为集成测试策略的选择提供了思路。系统依赖关系示意图子系统模块子系统子系统模块模块模块模块模块模块模块单元函数接口，箭头表示方向消息接口，箭头表示方向系统依赖关系示意图模块分析模块分析是集成测试分析最重要的工作之一。模块划分的好坏直接影响了集成测试的工作量、进度以及质量。因此需要慎重对待模块的分析。一般模块划分可以从下面几个角度出发进行考虑：本次测试主要是希望测试哪个模块；这个模块与哪几个模块有最密切关系，可以一、二、三、四按照密切程度排队；把该模块与关系最密切的模块首先集成在一起；这时再考虑这样划分后的外围模块，这些模块与被集成模块之间的消息流是否容易模拟，是否方便控制。模块分析一个合理的集成模块划分应该满足以下几点：被集成的几个子模块关系紧密；外围模块便于屏蔽，外围模块与集成模块之间没有太多、太频繁的调用关系，被集成模块没有采用类似POST_MESSAGE等调用函数的方式调用外围模块的情况。如果实在无法避免，你不得不考虑编写桩函数或桩模块，以代替被屏蔽部分的功能。模拟外围模块发往被集成模块的消息便于构造、修改；外围模块发往被测试模块的消息能够模拟大部分实际环境的情况；模块分析的2/8原则在软件工程中有一条事实上的原则，即2/8原则，该原则对测试同样起作用。从测试的实践发现，测试中发现的错误中的80%很可能起源于程序模块中的20%【6】。并且经验也告诉我们，很多错误报告常常可以在同一个模块中被追踪到，并且统计数据表明一段程序中已经发现的错误数目往往和尚未发现的错误数成正比。例如，在IBMOS/370操作系统中，用户发现的全部错误的47%只与该系统中4%的模块有关。对这样的一些模块，我们称之为易错模块或高危模块。一般我们可以把系统中的模块划分成三个等级：高危模块（这是集成测试需要关注的关键模块），一般模块低危模块（如果时间不允许的话，往往会减少或忽略这部分模块的集成，同时可能会对这类模块直接采用大爆炸式集成策略）。所以，划分集成测试对象模块时，首先应该判断系统中哪些是关键的模块。关键模块的特性和多个软件需求有关，或与关键功能相关；处于程序控制结构的顶层；本身是复杂的或者是容易出错的；含有确定性的性能需求；被频繁使用的模块（这部分模块不一定会出错，但可能会是性能的瓶颈，并且这类模块一旦出错，影响会比较大）；分析关键模块的思路尽可能和开发人员多讨论讨论，听听他们的意见，一般开发人员对哪些模块是关键模块，心理比较清楚；通过使用静态分析工具来分析系统各模块，寻找高内聚的模块、被频繁调用的模块或处于控制顶层的模块；根据需求跟踪表来分析关键模块，一般与关键功能或关键接口相关的模块都是比较关键的。同时与一些特殊需求相关的模块也需要特别关注；对于一个维护型的项目，可以根据以往的历史经验来判定，这包括产品历史缺陷的分析；对于一个新的产品，可以根据开发过程前期包括文档的检视、代码的走读、单元测试发现的问题进行分析，并因此确定可能风险最大的模块。函数质量度量分析函数调用关系分析系统质量度量分析接口分析集成测试的重点就是要测试接口的功能性、接口的可靠性、接口的安全性、接口的完整性、接口的稳定性等多个方面。因此我们必须对被测对象的接口进行详细的分析。这些分析包括接口的划分，接口的分类和穿越接口的数据分析。接口的划分接口的划分是以概要设计为基础的，其方法与相关的结构设计技术类似。一般可以通过下面几个步骤来完成：确定系统的边界、子系统的边界和模块的边界。确定模块内部的接口；确定子系统内模块间接口；确定子系统间接口；确定系统与操作系统的接口；确定系统与硬件的接口；确定系统与第三方软件的接口；接口的分类系统内接口：系统内部各模块交互的接口，这是集成测试的重点；系统外接口：外部系统（包括人、硬件和软件）对系统交互的接口，这类测试一般会延续到系统测试阶段来完成。系统内接口函数接口：通过函数的调用和被调用关系来确定。关于函数接口的集成测试比较成熟，提到的大部分集成策略都可以应用到这类接口上。消息接口：消息接口在面向对象系统和嵌入式系统中是很普遍的。在这种接口下，软件模块间并不直接发生联系，而是通过消息包（遵循接口协议）发生关系，常见的例子是整个系统共用一个或多个消息包队列，由操作系统进行消息包调度，取出位于消息队列头的消息并调用该消息的处理模块的处理函数。该处理模块，其核心通常是一个被动的有限状态机模型，根据消息内容和自身状态做出反应，通常是完成状态迁移并将发往另一个模块的消息放到消息队列中去。对于这种接口的测试我们往往采用工具来模拟，在集成策略上可以使用7.2中支持有限状态机模型的集成策略。其它接口：其它类型接口包括全局变量、配置表、注册信息、中断等。这类接口具有一定的隐蔽性，往往测试人员会忽略这部分接口。这类接口经常是测试不充分的。这类接口的测试需要借助一定的自动化工具。接口数据分析对于函数接口，我们需要关注穿越函数接口的参数个数、参数属性（参数类型，输入输出属性）、参数的顺序、参数的等价类情况、参数的边界值情况等。如果需要的话还要考虑他们的组合情况。关于消息接口，我们需要分析消息的类型、消息的域、域的顺序、域的属性、域的取值范围、可能的异常值等。如果需要的话，也要考虑它们的组合情况。关于类接口，我们需要对类的属性进行分析，一般重点在于对公共属性和保护属性进行分析。必要的时候会对部分私有属性进行分析。分析的方法包括等价类划分和边界值分析。对于其它类接口的分析，我们需要分析其读写属性、并发性、等价类和边界值。特别对于配置文件这类接口，其涉及到的数据变化量是及其庞大的，在分析这类数据的时候，可能需要结合一定的约束条件，尽可能减少用例的数量。集成测试的风险技术风险如测试人员对集成测试技术掌握比较薄弱或没有类似产品的集成测试经验；产品缺乏相关技术文档尤其是对接口描述稳定的缺乏；测试人员缺乏产品背景知识；测试人员对相关集成测试工具使用不了解等等；人员风险如人员变动频繁，人员到位不及时，缺乏有经验的老员工等；物料仪器测试环境如电脑、单板或其他硬件风险；物料仪器申购风险；测试工具无法及时到位风险等；管理风险版本计划更改风险；人员、时间计划变更风险；缺乏有效配置管理；过程失控；开发进度延迟等；市场风险市场需求更改；市场供货时间更改等；可测试性分析系统的可测试性分析应当在项目开始的时候作为一项需求提出来，并设计到系统中去。在集成测试阶段，我们分析可测试性主要是为了平衡随着集成范围的增加而导致的可测试性下降。对于一个接口不可测的系统，集成测试的实现是相当困难的，这会导致大量测试代码的添加或接口测试工具的开发。尽可能早的分析接口的可测试性，提前为测试的实现做好准常见的集成测试故障配置/版本控制错误；遗漏、重叠或冲突的函数；文件或数据库使用不正确的或不一致的数据结构；文件或数据库使用冲突的数据视图/用法；破坏全局存储或数据库数据的完整性；由于编码错误或未预料到的运行时绑定导致的错误方法调用；客户发送违反服务器前提条件的消息；客户发送违反服务器顺序约束的消息；错误的对象和消息的绑定（多态中经常发生）；错误参数或不正确的参数值；由不正确的内存管理分配/收回引起的失败；不正确的使用虚拟机、ORB或OS服务；IUT试图使用目标环境的服务，而该服务对目标环境的指定版本是已经过时或不向上兼容的；IUT试图使用目标环境的新服务，而该目标环境当前的版本不支持该服务；组件之间的冲突，例如当进程Y运行时，线程X就会崩溃；资源竞争：目标环境不能分配象征性装载所需要的资源集成测试用例设计思路集成测试是界于白盒测试和黑盒测试之间的灰盒测试，因此在该测试的用例设计方法中会综合使用两类测试中的测试分析方法。一般经过集成测试分析之后，测试用例的大致轮廓已经确定，集成测试用例设计的基本要求就是要充分保证其正确性，保证其能无误的完成测试项既定的测试目标。在这里我们根据单元测试用例设计的思路，来分析集成测试的用例设计