集成测试是如何融入于敏捷测试开发的生命周期中的？

　　“集成测试”这一术语含义就是，对不同的人来说，集成测试有不同的含义。实际上，有些人在使用“集成测试”时，实际上指的是组件测试。Gerard Meszaros定义“组件测试”为这样一种测试——审核开发团队所做的架构决定。这些测试编写于定义系统行为的面向客户测试之后，审核最小单元代码的单元测试之前。与面向客户测试不同，组件测试不需要被业务专家可读，但是可以像单元测试那样在同一框架内自动化。

　　有些人在使用“集成测试”时，实际上指的是层次测试，多层包括业务逻辑、数据库存取和表示层。这与真实的单元测试形成对比，单元测试孤立运行，并拥有组件帮助其它层次进行模拟，伪造和清除痕迹。在敏捷项目实践的驱动测试开发中，程序员编写小而孤立的测试单元，然后用少量的代码促使测试单元工作，接下来再下一小部分测试单元。因为他们也需要确认不同的层之间能够恰当地进行沟通，所以他们也要编写集成测试。有些人称之为“合同”测试，因为他们要审核两个单元代码之间的合同，并确定已经交换的信息。因为这些测试通常都会比单元测试要慢得多，所以在连续不断的集成过程中，他们可能独立地运行在自动化测试套件中。

　　“集成测试”指的是端对端的测试，是从用户角度来进行测试，用户认为，集成系统的所有部分就像期望的那样都一起工作。这往往被看作是释放之前的活动，但正如Meszaros指出的那样，它实际上应该是事先做好的。然而，你也许正致力于某些自包含的应用程序中，但却需要与其它系统的高层次进行集成。曾经，我的工作团队为一个大的电信公司开发过购物网站。我们的站点包含了与其它电信公司和用户常用的应用程序的整合点。但我们自己的测试环境并不包含其它的系统，在整个集成测试环境中，我必须安排好时间。通过完成两三个产品就绪用户案例的集成后，我们找到了解决方法。然后在整个集成测试环境中，与其他团队进行一次迭代测试，然后开始另一个释放周期。这不是理想的解决方案，它需要团队里的额外人员来帮忙与其它团队进行沟通，但它却是奏效的。