集中式集成
下列情形可以采用集中式集成：
一当系统的中心部分对其他部分的运行必不可少时(比如操作系统的内核)。
一必须有中心部分才能进行测试，而且该部分很难由占位来代替。
●系统的体系架构是这样的：首先开发中心部分作为产品，然后发布新模块或子系统来升级系统或增加新的功能。
首先测试系统的中心部分，下一步是集成控制结构。利用自下而上或自上下策略来并行测试耦合子系统。这种方法的瓶颈在于系统中心部分的集成。有时惟一可用的集成策略是混合策略，因为中心部分的模块经常联系非常紧密。只有在核心部件经过非常充分的测试之后，这种策略才能获得成功。这种方法很突出的优点是可以采用不同集成策略的组合，而且可以为每个系统部件选择最有效的策略。
分层集成
这种策略可以用于分层式体系架构的系统。在这种架构中，各层之间仅通过接口与其上下层直接相连。每一层可以单独使用自上而下、自下而上或混合策略来进行测试，然后按照自上而下或自下而上策略来集成每一层。其优点和缺点与自上而下以及自下而上策略是一样的。这种接口的集成和分隔比较容易，因此发现缺陷的根源也变得容易了。客户，服务器集成
这种策略用于客户，服务体系架构。在客户端。可以通过自上而下、自下而上或混合策略来集成，而服务器可以用占位和驱动程序来替代。反过来在服务器端也可以采用这样的方法。最后将服务器和客户端集成到一起。
协作集成
协作是一组对象为达到共同目标而进行的合作，比如实现一个用例。由于系统必须实现多个用例，因而它支持多个协作。许多对象都是多个协作的一部分。这意味着合理选择协作就可以覆盖整个系统。协作集成只适用于面向对象的系统。只有在协作被清楚定义而且覆盖所有的部件和接口之后，才能采用这种策略。协作覆盖所有部件和接口也是一个缺点，因为在不同协作之间细微的依赖关系可能被排除在协作模型之外。因为一个协作的所有部件需要组装在一起，而且只有当该协作完成之后，集成测试才可以开始，因而这种策略某种程度上是混合方式的实现。它只需进行少数的测试，因为测试重点是端对端的功能。由于协作之间相互重叠，因而没有必要测试每一个协作。因为已经测试了一组相关的部件，因此不需要或者只需要很少一些占位和驱动程序就可以进行测试。这个矩阵的另一个用处是能提供一个简明的概览。如果有必要，更详细的信息可以用文本形式提供，比如必要的特定工具或技术的使用，可以采用给矩阵加脚注的形式。
文章来源于领测软件测试网 https://www.ltesting.net/
