软件测试基础 (二): 集成测试

Hello！大家好，我是BugBear，一个专注于分享软件测试干货的测试开发。上一篇文章我们讲了单元测试相关知识，今天我们来聊聊集成测试的相关内容。

一、什么是集成测试？

我们通过工厂组装手机的例子明白了单元测试，每个电子元件或者零部件就是一个单元测试，那么将这些电子元件或者零部件组装起来形成一个功能模块组件，例如喇叭，听筒，麦克，FPC，按键板，摄像头，LCD等。针对这些功能模块组件进行测试，就类比于我们所知的集成测试。

集成测试的定义如下：

集成测试也叫组装测试、联合测试、子系统测试或部件测试。集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统。

集成测试的含义非常简单，就是将单元测试模块逐个集成/组合，并将行为测试为组合单元。该测试的主要功能或目标是测试单元/模块之间的接口。我们通常在单元测试之后进行集成测试。一旦创建并测试了所有单个单元，我们就开始组合这些“单元测试”模块并开始进行集成测试。首先单独测试各个模块。模块经过单元测试后，逐个集成，直到所有模块都集成在一起，检查组合行为，验证需求是否正确实现。在这里我们应该理解，集成测试不会在周期结束时发生，而是与开发同时进行，基于开发实现不断在原来的基础上逐步融入新的子模块进行集成测试。

二、为什么要做集成测试？

有人可能会提出疑问，我们把每个单元测试都测试完毕了，每个单元都按照要求实现了对应功能，为什么还需要将单元组合起来进行集成测试？

各单元实现逻辑不同：在现实世界中，当开发应用程序时，它被分解为更小的模块，并且为每个开发人员分配1个模块。每个开发人员实现的逻辑完全不同，因此检查开发人员实现的逻辑是否符合预期并根据规定的标准呈现正确的值变得很重要。
数据流转校验：很多时候，当数据从一个模块移动到另一个模块时，数据的面或结构会发生变化。附加或删除某些值，这会导致后续模块出现问题。
数据交互校验：模块还与某些第三方工具或API进行交互，这些工具或API也需要进行测试，以确保该API /工具接受的数据是正确的，并且生成的响应也是预期的。
单元频繁变更：需求频繁变更导致单元代码迭代更新，但是多数时候开发人员在没有单元测试的情况下部署更改，此时集成测试就非常重要。

我们知道集成测试的重要性，那么集成测试会给我们带来什么好处呢？

此测试可确保集成模块/组件正常工作。
一旦要测试的模块可用，就可以开始集成测试。它不需要完成其他模块以进行测试，因为Stubs和Drivers可以用于相同的操作。
它检测与接口相关的错误。

三、集成测试层次

集成测试层次如下：

模块内集成测试：软件模块1、软件模块2、软件模块3、软件模块4、软件模块5
子系统内集成测试：软件模块1+软件模块2、软件模块3+软件模块4+软件模块5
子系统间集成测试：子系统1+子系统2

四、集成测试类型

集成测试基于不同的测试策略衍生出不同类型的测试方式，下面将介绍主要的集成测试的类型。

1、大爆炸集成类型

大爆炸集成类型（俗称Big bang）一次性集成了所有模块，即它不会逐个集成模块。它会在集成后验证系统是否按预期工作。如果在完全集成的模块中检测到任何问题，则很难找出导致该问题的模块。

- 优点：

对于小型系统来说可以迅速完成集成测试，井且只要极少数的驱动和桩模块设计。它需要的测试用例也是最少的;
该方法比较简单;
多个测试人员可以并行工作，对人力，物力资源利用率较高

- 缺点：

大爆炸集成类型是一个耗时的过程，找到一个自身有缺陷的模块会耗费大量时间与精力，因为他是一次性集成了所有模块，我们无法明确知道具体是哪个模块出了问题，必须要进行逐一排查来定位问题模块。修复完毕问题模块后若继续出现问题，我们没法判断是由于修复代码时造成了其他缺陷还是其他模块本身存在的缺陷导致，为了定位问题又需要花费时间排查。

- 适用范围：

一个维护型项目（或功能增强型项目），其以前的产品已经很稳定；
被测系统比较小，并且它的每个函数都经过了充分的单元测试；
新增的项目只有少数几个组件被增加或修改，一旦集成测试出现问题，能够快速排查问题所在；

2、自上而下集成策略类型

自上而下集成策略分为 深度优先集成 与 广度优先集成 两种策略。我们先来看看深度优先集成策略。

- 深度优先集成策略

从上图可以看出深度优先集成策略以纵向为基础不断向下集成模块组件进行集成测试，给A加一个驱动调用A，先给A加一个B，其他的虚拟数据（使用Stub桩程序），然后才给B加入E(替换S4)，以此类推。。观察各单元的功能是否正常。深度优先集成策略的核心是先保证一条流程先走下来。

- 广度优先集成策略

从上图可以看出广度优先集成策略以横向为基础不断横向集成模块组件进行集成测试，给A加一个驱动调用A，先给A加一个B，其他的虚拟数据（使用Stub桩程序），然后才给B加入E(替换S2)，以此类推。。观察各单元的功能是否正常。广度优先集成策略的核心是先保证同一级的单元先集成。

- 自上而下集成策略优点：

自顶向下的集成方式在测试过程中较早地验证了主要的控制和判断点；如果选用按深度方向组装的方式，可以首先实现和验证个完整的软件功能；
功能可行性较早得到证实，还能够给开发者和用户带来成功的信心；
最多只需一个驱动（Driver程序），减少了驱动器开发的费用；
支持故障隔离。

- 自上而下集成策略缺点：

桩（Stub）的开发和维护是本策略的最大成本；
底层组件行为的验证被推迟了;
随着底层组件的不断增加，整个系统越来越复杂，导致底层组件的测试不充分，尤其是那些被重用的组件。

- 自上而下集成策略适用范围：

产品控制结构比较清晰和稳定;
产品的高层接口变化比较小;
产品的底层接口未定义或经常可能被修改;
产品的控制组件具有较大的技术风险，需要尽早被验证;

3、自下而上集成策略类型

自下而上集成策略是先对程序结构最底层的代码进行集成与测试，然后不断融入上级模块或代码再次进行扩展测试。

组件是自底向上进行组装，对于一个给定层次的组件，它的子组件(包括子组件的所有下属组件)已经组装并测试完成，所以不再需要桩程序。

通过上图可以看到，从程序结构最底层从下往上进行组装与测试，先测试E，然后E+B，以此类推。其他分支按照同样的方式进行组装测试，最后将所有分支与上级模块A组装进行测试。

- 自下而上集成策略优点：

允许对底层组件行为的早期验证。可以在任何一个叶子节点已经就绪的情况下进行集成测试;
在工作的最初可能会并行进行集成，在这一点上比使用自顶向下的策略效率高;
减少了桩的工作量，毕竟在集成测试中，桩的工作量远比驱动的工作量要大得多。但是为了模拟一些中断或异常，可能还是需要设计桩程序;
该方法也支持故障隔离。

- 自下而上集成策略缺点：

驱动的开发工作量也是很庞大的，每次组装后都需要设定一个驱动程序来模拟上层模块程序;
对高层的验证被推迟到了最后，设计上的错误不能被及时发现，尤其对于那些控制结构在整个体系中非常关键的产品。

- 自下而上集成策略适用范围：

底层接口比较稳定、变动较少的产品;
高层接口变化比较频繁的产品;
底层组件较早被完成的产品。

4、三明治集成策略类型

通过上面的学习我们不难发现，自上而下集成策略与自下而上集成策略都有各自的优点与缺点，那么我们能不能发展两者所长，避其两者所短呢？答案是当然的，这就出现了三明治集成策略！

三明治集成策略相当于将自下而上集成策略和自上而下集成策略结合起来

三明治集成就是这样一种方法，它把系统划分成三层，中间一层为目标层。
测试的时候，对目标层上面的一层使用自上而下的集成策略，对目标层下面的一层使用自下而上的集成策略，最后测试在目标层会合。

- 优点：集合了自下而上集成策略和自上而下集成策略，发展两者所长，避其两者所短

- 缺点：中间层在被集成前测试不充分

- 适用范围：大部分软件开发项目都可以使用这种集成策略

BugBear软件测试，专注于分享测试干货，在分享的过程中提升自己，欢迎关注，交流成长。