单元测试主要由开发人员完成，所以从测试人员工作来看，集成测试可能是具体测试实施的第一个阶段，虽然开发人员也比较多地参与集成测试。集成测试相对来说是挺复杂的，而且对于不同的技术、平台和应用，差异也比较大。不过，我们还是不得不面对它，保证系统集成成功，为后来的系统测试打下基础。
集成测试简单的表现形式就是每日构建（Daily Build）, 保证Build构建成功，也就是保证软件的组件或单元能组装成一个系统。每日构建是一个很好的实践，被许多软件公司采用。
集成测试，更多是和开发环境融合在一起，在编程过程中去实现，如MS Visual Studio.NET ，Borland JBuilder IDE， Compuware OptimalJ的集成开发/测试环境。更正确的说法，集成测试发要追溯到设计阶段。当设计数据接口(DB，XML等）、组件接口、应用接口(API)之时，我们就要审查接口的规范性、一致性等，就已经开始了集成测试。
集成测试阶段，测试方法是动态变化的，从白盒测试方法向黑盒测试方法逐渐过渡。在自底向上集成的早期，白盒测试方法占较大的比例，随着集成测试的不断深入，这种比例在测试过程中将越来越少，渐渐地，黑盒测试慢慢占据着主导地位。
集成模式是软件集成测试中的策略体现，其重要性是明显的，直接关系到测试的效率、结果等，一般要根据具体的系统来决定采用哪种模式。集成测试基本可以概括为以下两种：
非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求一次全部组装起来所要的系统，然后进行整体测试。
渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个模块结合进来测试。
非渐增式测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是渐增式集成模式，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，接口的测试亦可做到完全彻底。两种模式中，渐增式测试模式虽然需要编写的Driver或Stub程序较多、发现模块间接口错误相对稍晚些，但渐增式测试模式还具有比较明显的优势。
在实际测试中，应该将两种模式有机结合起来，采用并行的自顶向下、自底向上集成方式，而形成改进的三明治方法。而更重要的是采取持续集成的策略，软件开发中各个模块不是同时完成，根据进度将完成的模块尽可能早的进行集成，有助于尽早发现缺陷，避免集成阶段大量缺陷涌现。同时自底向上集成时，先期完成的模块将是后期模块的桩程序，而自顶向下集成时，先期完成的模块将是后期模块的驱动程序，从而使后期模块的单元测试和集成测试出现了部分的交叉，不仅节省了测试代码的编写，也有力于提高工作效率。
如果不采用持续集成策略，开发人员经常需要集中开会来分析软件究竟在什么地方出了错。因为某个程序员在写自己这个模块代码时，可能会影响其它模块的代码，造成与已有程序的变量冲突、接口错误，结果导致被影响的人还不知道发生了什么，缺陷就出现了。随着时间的推移，问题会逐渐恶化。通常，在集成阶段出现的缺陷早在几周甚至几个月之前就已经存在了。结果，开发者需要在集成阶段耗费大量的时间和精力来寻找这些缺陷的根源。如果使用持续集成，这样的缺陷绝大多数都可以在引入的第一天就被发现。而且，由于一天之中发生变动的部分并不多，所以可以很快找到出错的位置。这也就是为什么进行每日构建软件包的原因所在。所以，持续集成可以提高软件开发的质量与效率。
在现实中，集成测试和单元测试所处的情形相似，测试不彻底、不充分，没有各种接口参数、各类接口数据进行充分测试。如果系统的架构的层次不清楚，这种问题会更严重。目强许多开放系统都支持API，其集成测试的内容就更多了，除了API手册的内容正确性验证之外，还要模拟用户调用API的各种Scenario，后者在编程技术、对产品的各类应用要很好掌握，才能做好测试。
版权所有，软件测试演义® ——系列讨论的目录，见：
