在各个模块均进行了单元测试且通过的前提下，就能保证整个功能是可用的吗？显然是不够充分的。我们从软件研发流程的V模型前半段，可以看到需求是如何一步步拆解到方法的，那么测试时就需要反过来，一步步将零件组装起来，以保证整体是可用的。

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

  除了单个程序内部各个模块间的集成，随着微服务的流行，一个动作可能需要多个服务间相互调用才能实现，所以我认为将多个系统间接口串联组合起来进行的测试，也是集成测试。

  集成测试的方法区分，主要是在如何组合多个模块，以及组合的顺序上。主要可分为粗暴的非增量测试，及循序渐进的增量测试。

  先简单假设一个需求场景，以下均以该需求进行阐述，待测试程序的模块结构如下：

  非增量式集成测试策略也叫做大爆炸集成，是将所有的模块直接组合起来，按完整的功能进行测试，从功能层级设计测试案例，而不考虑各个模块具体的情况。

  就提到的案例而言，非增量的集成测试，就是在ABCDEF都开发完成后，再将各个组件联合起来进行测试。

  这种测试方式的优点有：

缺点也很明显：

  适用场景：对稳定系统做小范围改造的二次开发。

  增量测试是指从某一功能点开始，逐步对整个流程进行测试。又可根据测试顺序，分为自顶向下、自底向上、混合增量三种测试形式。

  与非增量测试相同，直接从整体的功能入口开始测试。不同的是，自顶向下时并不是直接将各个模块实际引用了进来，而是采取“测试桩”来替代，具体技术实现手段比如使用Mock模拟返回。这样便排除了与下游的未测试模块的依赖，而可以专注测试本模块。

  当顶上的模块确认测试通过时，逐步用实际模块替代测试桩，并新增新的测试案例，此时之前已有的案例依旧可以再次执行，进一步验证。

  结合案例，从A到E分支的测试步骤应该是这样的（其他分支以此类推）：

  自底向上的顺序与自顶向下相反，需要更多的测试案例，而不再需要测试桩。

  结合案例，测试步骤如下：

  混合集成则是将自顶向下与自底向上结合起来，选取中间点，中间点以上采用自顶向下的模式，中间点以下则是采用自底向上模式。