集成测试 - 增量测试与非增量测试

我们为什么需要集成测试？

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

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

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

集成测试的方法

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

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

非增量测试

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

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

  这种测试方式的优点有：

• 1.一个测试案例会直接贯穿多个模块，单个测试案例的覆盖率高，所以总测试案例数少；

缺点也很明显：

• 1.测试的颗粒度较粗，对单个模块的各种集成情况，无法测试完全；
• 2.测试过程中发现问题难以定位，不能直接确认到是哪个模块导致；
• 3.发现问题较晚，若需要为了解决问题需要改造接口，则成本较大；

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

增量测试

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

自顶向下

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

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

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

• 1.先对A模块进行测试，并编写BCD的桩模块模拟返回，确保A模块的逻辑无误；
• 2.然后实际调用B模块，替代上一步的测试桩，并编写E模块的桩模块模拟返回，以确保B模块被完全测试；
• 3.最后将E模块实际调用，替代上一步的测试桩；

自底向上

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

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

• 1.编写测试案例对E、C、F进行测试，确保功能正常；
• 2.针对B、D模块编写测试案例，并且将E、F直接引入调用，进一步测试E、F；
• 3.针对A模块编写测试案例，并且将B、C、D直接引入调用；

混合增量

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