软件测试中的集成测试方法

我想说起集成测试来大家一定都不陌生，但是如果说起集成测试的具体测试方法大家有几个了解呢，那我来介绍一下有关集成测试的方法，希望对新手有所帮助

　　集成测试是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。
　
　　集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。
　
　　可以以多种方式进行集成测试，而下面是三种常用的类别：由上而下的集成测试方法要求首先测试和集成最高级别的模块。这使高级别的逻辑和数据流可以在过程的早期阶段测试，有助于最大限度地减少对驱动程序的需求。但是，对存根 （stub） 的需求使测试管理变得复杂，低级别的实用工具在开发周期中相对较晚的阶段测试。由上而下的集成测试的另一个缺点是不能很好地支持有限功能的早期发布。
　
　　由下而上的方法要求首先测试和集成最低级别的单元。这些单元常被称为实用工具模块。通过使用这种方法，实用工具模块在开发过程的早期阶段测试，最大限度地减少了对存根 （stub） 的需求。但是，不利的方面是对驱动程序的需求使测试管理变得复杂，高级别的逻辑和数据流在晚期测试。与由上而下的方法一样，由下而上的方法也不能很好地支持有限功能的早期发布。
　
　　第三种方法（有时也称为伞形方法）要求测试沿功能性数据和控制流路径进行。首先，函数的输入以上面讨论的由下而上的模式集成。然后，每个函数的输出以由上而下的方式集成。这种方法的主要优点是对有限功能的早期发布的支持程度。它也有助于最大限度地减少对存根 （stub） 和驱动程序的需求。但是，这种方法的潜在缺点非常明显，因为它的系统性可能比其他两种方法低，会导致对回归测试的更大需求

原文转自：http://www.ltesting.net