软件工程软件测试之——集成测试

Posted 2021-05-01 软件工程之思

1、概念

集成测试也叫组装测试、联合测试、子或部件测试。 集成测试是在的基础上，将所有模块按照概要设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。

2、集成测试的目的

1.找出模块接口以及整体体系结构上的问题； 2.确保各组件组合在一起后能够按照既定意图协作运行，并确保增量的行为正确； 3.集成测试属于； 1)验证接口是否与设计相符合； 2)发现设计和需求中存在的错误。

3、集成测试关注的重点

一些模块虽可以单独正常工作，但不能保证连接起来也能正常工作，程序在某些局部反映不出来的问题，在全局上就很有可能暴露出来，影响功能的实现。

因此，集成测试应当考虑一下两个问题：

1.模块间的接口（需要考虑的有两点）

1)在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失； 2)全局是否有问题，会不会被异常修改。

2.集成后的功能（需要考虑三点）

1)各个子功能组合起来，能否达到预期要求的父功能； 2)一个模块的功能是否会对另一个模块的功能产生不利的影响； 3)单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

4、集成测试的层次

一个产品的开发过程包括了一个分层的设计和逐步细化的过程，从最初的产品到最小的单元可以划分为：产品——>子系统——>硬件子系统、子系统——>软件模块——软件程序——>单元。

一般单元测试针对最小的单元结构，系统测试对应于产品级，而当中的所有各层测试都需要通过集成测试来完成，由于集成的力度不同，因此将集成测试划分为3个级别：

1.模块内集成测试（单元测试完成后） 2.子系统内集成测试，即模块间集成测试 3.子系统间集成测试5、集成测试策略

5、集成测试策略

集成测试策略是在测试对象分析的基础上，描述软件模块集成（组装）的方式、方法，分类如下：

1.集成（ Integration）

是属于非增值式集成（Non-Incremental Integration）的一种方法，也叫一次性组装或整体拼装。该集成把所有系统组件一次性集合到被测系统中，不考虑组件之间的相互依赖性或者可能存在的风险。应用一个系统范围内的测试包来证明系统最低限度的可操作性。

1)方法(策略) a.在这种集成方式中，首先对每个模块分别进行单元测试 b.然后再把所有单元组装在一起进行测试 c.最后得到要求的软件系统

2)目的 在最短时间内把系统组装出来，并且通过最少的测试来验证整个系统

3)优点 a.在有利的情况下，大爆炸集成可以迅速完成集成测试，并且只要极少数的驱动和桩模块设计（如果需要的话）; b.它需要的也是很少的; c.该方法比较简单； d.多个测试人员可以并行工作，对人力，物力资源利用率较高。

4)缺点 a.这种一次性组装方式试图在辅助模块的协助下，在模块单元测试的基础上，将所测模块连接起来进行测试，但是由于程序中不可避免地存在模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大; b.在发现错误的时候，其问题定位和修改都比较困难; c.即使被测系统能够被一次性集成，但还是会有很多接口错误很容易的躲过测试而进入到系统范围测试内。

5)适用范围 a.维护型项目（或功能增强型项目），其以前的产品已经很稳定，并且新增的项目只有少数几个组件被增加和修改； b.被测系统比较小，并且它的每个组件都经过了充分的单元测试； c.产品使用了严格的净室过程，并且每个开发阶段的质量和单元测试质量都非常高。

2.自顶向下的集成策略（Top-Down Integration）

采用了和设计一样的顺序对系统进行测试，在第一时间内对系统的控制接口进行了验证。

1)方法（策略） a. 以主模块为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块替换，对主模块进行测试； b.采用深度优先（Depth-First）或者宽度优先（Breath-First）的策略，用实际模块替换相应桩模块，再用桩替代它们的直接下属模块，与已测试的模块或子系统组装成新的子系统； c.进行，排除组装过程中引起的错误的可能； e.判断所有的模块是否都已组装到系统中?如果是，则结束测试，否则转到b步骤去执行。

2）目的 从顶层控制开始，采用同设计顺序一样的思路对被测系统进行测试，以验证系统的接口稳定性。

3）优点 a.自顶向下的增殖方式在测试过程中较早的验证了主要的控制和判断点; b.功能可行性较早得到证实，还能够给开发者和用户带来成功的信心; c.最多只需要一个驱动模块，减少了驱动器开发的费用； d.由于和设计顺序的一致性，可以和设计并行进行，如果目标环境可能存在改变，该方法可以灵活的适应； e.支持故障隔离。

4）缺点 a.桩的开发和维护是本策略的最大成本，随着桩数目增加，成本急剧上升; b.底层组件中一个无法预计的需求可能会导致许多顶层组件的修改，这破坏了部分先前构造的测试包; c.底层组件行为的验证被推迟； d.随着底层模块的不断增加，整个系统越来越复杂。

5）适用范围 适用于大部分采用结构化编程方法的软件产品，且产品的结构相对比较简单，对于具有以下属性的产品，可以优先考虑该策略： a.产品控制结构比较清晰和稳定； b.产品的高层接口变化比较小； c.产品底层接口未定义或经常可能被修改； d.产品控制模块具有较大的技术风险，需要尽早被验证； e.希望尽早可以看到产品的系统功能行为； f.在极端编程（Extreme Program）中使用探索式开发风格时，其集成策略可以采用自顶向下。

3.自底向上的集成策略（Bottom-Up Integration）

是从结构的最底层的模块开始组装和测试，因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块下属所有模块）已经组装并测试完成，所有不在需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。

4.三明治集成（Sandwich Integration）

也称为混合式集成，集合了自顶向下和自底向上两种策略的优点，它将系统划分为3层，中间一层为目标层，测试的时候，对目标层上面的一层使用自顶向下的集成策略，对目标层下面的一层使用自底向上的集成策略，最后测试在目标层会合。

5.基干集成（Backbone Integration）

在很多系统中，尤其是，一般划分为两个部分：内和部分（基干部分）和外围应用部分，这两部分经常被不同的项目组并行开发，该策略首先要识别应用的控制组件部分，基干部分和应用子系统部分，然后进行测试。 结合自顶向下，自底向上和大爆炸集成的元素，验证紧密耦合的子系统之间的互操作性。

6.分层集成（Layers Integration）

分层集成是针对分层模型使用的一种策略。 通过增量式集成的方法验证一个具有层次体系结构的应用系统的稳定性和可互操作性。

7.基于功能的集成（Function-Based Integration）

是从功能角度出发，按照功能的关键程度对模块的集成顺序进行组织。 采用增值的方法，尽早的验证系统关键功能。

8.基于进度的集成（Schedule-Based Integration）

考虑了项目的进度压力，兼顾进度和质量，在两者之间寻找均衡点进行测试，该集成的最基本策略是把最早可获得的代码拿来立即进行集成，必要的时候开发桩模块和驱动模块，在最大程度上保持与开发的并行性，从而缩短了项目集成的时间。

9.基于风险的集成（Risk-Based Integration）

是基于假设：系统风险最高的模块间的集成往往是错误集中的地方，因此尽早的验证这些接口有助于加速系统的稳定。所以该集成需在第一时间内验证高危模块间的接口，保证系统的稳定性。

10.基于事件（消息）的集成（Event/Message-Based Integration）

针对基于状态机的系统（工作原理是基于状态变迁，内部模块间的接口主要通过消息来完成），因此该集成是从验证消息路径的正确性角度出发，渐增式的把系统集成到一起，从而验证系统的稳定性。

11.基于使用的集成（Use-Based Integration）

针对的系统，从分析类之间的依赖关系出发，通过从最小依赖关系的类开始集成，逐步扩大，最后集成到整个系统，通过该集成方法，可以验证类之间接口的正确性。

12.分布式集成（Distributed Services Integration）

针对可以有许多并发运行、没有专门控制轨迹的组件、以及没有专门层的分布式系统。 验证松散耦合的同级组件之间交互的稳定性。

13.客户/服务器的集成（Client/Server Integration）

对于和单独的服务器组件进行松散耦合的客户端组件，可以使用客户/服务器集成来完成。 验证客户和服务器之间交互的稳定性。

14.高频集成（High-frequency Integration）

源自：cnblogs