对于集成测试，初学者往往比较模糊，到底怎么测？是不是把两个模块连在一起，然后采用单元测试的技术，测试这个更大的模块？
我们都知道，集成测试关注的是模块之间的接口。那么可以将“接口”作为切入点。纵观模块之间的接口，我们可以归纳为以下几种类型，下面一一介绍一下。
1、通信协议：两个模块之间通信采用的是标准的或者自定义的（网络）协议；
协议中即包含数据部分，又包含控制部分；有些实现将数据与控制分离，如FTP；而大部分实现将数据与控制通过一条链路来传递，往往通过不同的消息包进行分离。
2、调用关系：模块A调用模块B，实际上是由模块A向模块B发出了一条控制指令，这里数据传递体现的不是很明显，往往体现为参数与返回值，它们可以认为是控制的副本。
3、文件、数据库、队列、第三方中间件等：表现的主要是数据的传递，其中的控制体现的不明显。
4、共享资源：比如共享一段“存储区域”，其中涉及的关键资源主要是“锁”了；这样的两个模块在运行时往往分布到不同的进程或者线程中，表现为对资源的竞争，以及数据的共享。
5、同步：一个模块的运行需要另外一个模块的触发，双方往往存在“信号”等通知机制，也可以理解为一种特殊的控制方式。
OK，现在切入点有了，我们可以将被测系统归类（以上的分类），找出其中的数据接口与控制接口。
接下来的做法与一般的测试思路没有什么不同。
首先，将数据接口与控制接口分解——需要传递哪些数据？存在哪些控制指令？
然后，找出数据与指令中的变数所在；如数据（协议包）中的字段的取值，指令的参数变化等；
接下来，将变数划分等价类，找出每类的代表，就是我们的测试数据了——我们的目标是：让每类数据流与控制流均通过接口一次，从而实现接口测试的完全性；
最后，就是考虑如何生成这些测试数据了。往往需要对应到集成后“大模块”的输入与输出。
谈了很多，上面的内容更多的关注了实现。下面我们要考虑另外一个侧面——业务。
模块之间的联系（接口）往往是为了体现业务上的关联。大家都知道，关联本身也是有很多属性的。如关联点（每个模块）都存在一个角色，关联有多重性（multiplicity）——即模块A在运行时可能对应多个模块B的实例。
我们找到了测试的另外一个切入点，模块的集成能否准确体现业务上的关联？各个模块是否具备其角色的全部属性和接口，模块之间的关联关系如何打破？关联的多重性是否有效？
当然，集成测试不会太关心业务或者需求，那是系统测试的事了。但此时想想，往往能够得到意外的收获。
太多的关注功能，往往忽略其他。有时我们不得不考虑接口的性能，尤其对于系统关键接口。接口的性能测试越早进行越好。如果等到系统测试时做，可能接口外面封装了太多的代码，影响性能问题的精确定位。
集成测试单元测试的逻辑扩展。它的最简单的形式是：两个已经测试通过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部门，方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。
集成测试识别组合单元时出现的问题。通过使用要求在组合单元钱测试每个单元并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。
可以以多种方式进行集成测试，而下面是三种常见的类别：
由上而下的集成测试方法要求首先测试和集成最高级别的模块。这种高级别的逻辑和数据流可以在过程的早期阶段测试。有助于最大限度地减少对驱动程序的需求。但是，对存根（stub）的需求使测试管理变得复杂，低级别的使用工具在开发周期中相对较晚的阶段测试。由上而下的集成测试的另一个缺点是必能很好的支持有限功能的早期发布。
由下而上的方法要求首先测试和集成最低级别的单元。这些单元常被称为使用工具模块。通过使用这种方法，使用工具模块在开发过程的早期阶段测试，最大限度第减少了对存根（stub）的需求。但是，不利的方面是对却动程序的需求使测试管理变得复杂，高级别的逻辑和数据流在晚期测试。与由上而下的方法一样，有下而上的方法也不能很好地支持有限功能的早期开发。
第三种方法（有时也称为伞状方法）要求测试沿功能性测试和控制流路径进行。首先，函数的输入以上面的讨论的由下而上的模式集成。然后，每个函数的输入以由上而下的方式集成。这种方法的主要优点是对有限公能的早期发布的支持程度。它也有助于最大限度地减少对存根（stub）和驱动程序的需求。但是，这种方法的潜在缺点非常明显，因为它的系统性可能比其他两种方法，会导致对回归测试的更大需求。
