为什么一定要做集成测试？

集成测试，我们都不陌生，几乎我们产品每天都在进行。但是我们真的有好好思考：为什么一定要做集成测试吗？只是为了简单的将“积木”搭起来就行，还是有什么其他的深意？

深意可能不一定会有，但是意义是肯定存在的。

如何看待集成测试？

James Bach认为，集成测试的动机是挖掘与集成相关的潜在风险，是专门为评估与整合相关的风险而设计的测试。而我认为，集成测试是检验一个产品是否初具雏形的关键。

试想一下，如果一个生产，多个部门负责生产车轮、轴承、发动机等零件，如果零件各自生产出来了，但不经过组装测试，而直接等待最终组装成整车，这会是一个多么大的风险？

为什么要集成测试？

我们先来看看整体的意义。

我们还是采用汽车生产这个比喻，很容易就能发现：对于一个产品整体来说，在某种程度上和某种程度上它由部分组成，为各部分创造一个内部环境，整体拥有部分不具有的属性。

我们分别来理解上面所说的三个观点。

整体由部分组成

例如：我们汽车由车轮、发动机、轴承、车架、方向盘等部分组成，而每个部分可能有不同的来源（不同的部门或者不同的提供者）。

各部分是为不同的目的而生产，比如车轮是为了行驶，发动机是为了提供动力来源，方向盘是为了方便使用者掌握方向。它们具有不同的属性，还有可能不是同时间周期创造，比如，车轮可能通过第三方购买，而第三方是早前存货。

整体为各部分创造一个内部环境

这个创造或割离出来的内部环境可以使各部分相互作用，相互依存，以及与外部环境的相互作用，而这个内部环境从外部是看不见的。

例如：汽车点火按钮与发动机之间的联系，这就属于一个内部环境。

整体拥有部分不具有的属性

整体依赖于部分，但又与部分不同，拥有他们不具有的属性。例如：汽车可以很方便的切速形势，但单独的车轮不行。又比如，一个简单的例子是三脚架的稳定性，它不是在它的任何一个单独的腿上，而是在所有的腿一起工作时。

由此可见，仅仅通过观察一个积分的各个部分，你可能无法分辨出你想知道的关于它的一切。这就是集成风险存在的原因。在复杂或重要的系统中，集成测试将是极其重要的，特别是在进行了更改之后。

集成测试时的启发性关注点？

既关注整体，也要关注部分

“整体”由“部分”构成，但并意味着一定先存于整体之前，或者在集成的过程中没有改变。

这意味着我们需要我们可以富有成效地思考产品的各个部分，以及它们如何与其他部分相互作用。

既关注集成，也要关注解体

“解体也会带来整合”，当你把某部分拿走，或者把产品拆开，你最终会得到一个新的整合，这个时候也会有风险存在。

举个例子：集成过程中某个组件延迟集成，对整个产品造成的风险。

要关注集成的程度和种类

“融合不是全或无——有不同的程度和种类“。

一个产品可能会意外地集成，因为它使用的是没有人意识到它拥有的部分。它可能是松散集成的，比如一只可以丢弃尾巴的壁虎，或者一个带有插件的浏览器，它可能是紧密集成的。

再举个例子：当我们从一个产品中获取代码，并将其添加到另一个产品的不同位置时，我们可以边走边编辑，它可能会保留其部件的现有接口，或违反它们，或重新设计它们，或消除它们。

特别是在集成测试时，我们往往重心在正向集成上，而忽略了解体时存在的一些风险。举例：常见来说，产品多组件安装，我们常关注安装是否成功，而容易忽略部分卸载或整体卸载时的风险。

怎么进行集成测试？

本节我们要说的是怎么拆分集成测试。

从整个产品来说，我们可以做两层或更多层的集成测试。例如：我们可以对发动机这个组件设置一个集成测试，因为放大来看，发动机也是由许多小组件构成。同样的，还可以对车轮设置一个集成测试。

而从整体来说，汽车本身也可以设置一个集成测试，因为它是一个对外交付的产品。

有的人可能就会说，到汽车应该是系统测试了！这两者的差异主要在于你的关注点是什么：

如果你关注的是组件间的接口是否合理可用，那么你可以把这个环节叫做集成测试；

如果你关注的是整车的可用性和功能性，你可以叫它系统测试。

不同的人可能会将不同的事物识别为部件、环境或产品，没关系，我们也可以自由地移动镜头，尝试不同的视角。所以说，我们集成测试设置的粒度取决于我们的关注范围，并没有一个一成不变的标准。

因此，我们可以从产品层面划分集成测试，也可以从团队层面划分集成测试。

产品层面划分

假如产品P由组件C1、C2、…、C7组成，我们可以针对单个组件设置一级集成测试。

如，ItergrationTest1、ItergrationTest2、…、ItergrationTest7，再往上，交互组件C1和C2，C3和C4、…、C7之间可以设置二级集成测试ItergrationTest12、ItergrationTest34567，直到产品级集成测试ItergrationTestP。

团队层面划分

根据不同团队划分集成测试。一个团队可能会负责多个组件，组件的集成测试交由团队考虑。因此，从团队层面考虑，我们可以划分为团队集成测试TeamItergrationTest1、TeamItergrationTest2……，以及项目级集成测试ProjectItergrationTest。

最后说一说

从上面描述我们可以看出集成测试在产品研发过程中的重要性，以及我们在设计集成测试和分层集成测试时容易忽略的一些思考点。希望能够帮助正在阅读的你有所收获~

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

 这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取