我们往往将软件测试可以分为单元测试、集成测试、系统测试和验收测试。而集成测试界于单元测试和系统测试之间，起到"桥梁作用"，一般由开发小组采用白盒加黑盒的方式来测试，既验证"设计"，又验证"需求"。 主要用来测试模块与模块之间的接口，同时还要测试一些主要业务功能。集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合为程序的更大部分。方法是测试片段的组合，并终扩展成进程，将模块与其他组的模块一起测试。后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有集成测试进程。
　　Web 集成测试
　　在很多时候，我们的 Web 应用程序往往会成为项目的瓶颈，以至于影响整个项目的按时发布。那么我们不禁要问，为什么会出现这样的情况？是什么在阻碍着项目的进度？在我们深入探讨这个问题之前，让我们先回忆一下一个典型的 Web 项目开发所经历的过程，从而寻找出问题的根源。
　　从开发的流程上看，它与其他的产品开发没有本质的区别，无外乎立项、审核、开发、集成、测试、维护这些具体的过程。每个步骤参与的人员和行为也都大同小异，然而您会发现往往很多的 Web 项目总是在集成测试环节出现这样或者那样的问题？（当然集成测试符合普氏原理，其他的产品开发也会遇到这样棘手的问题，只是 Web 显得更加的明显和突出罢了）其实这和具体的 Web 项目没有多大的关系，有点绕？哦，这句话的意思是，我们需要将思维跳出具体的项目本身，从整个产品的角度来看待问题，这样很容易找到痛点。那么让我们换个角度来看这个问题：
　　客户–〉Web/客户端–〉系统基础软件
　　从上面的关系中我们可以看到，作为"食物链"顶端的 Web 项目往往起着一个"中间人"的角色，在它之下是系统软件（如操作系统本身或者其上的中间件），而在它之上往往直接面对客户。在软件开发的经典教程里，总是将这种处于中间衔接层的软件设计称为--鲁棒性。也是说它需要的是某种颠覆性的 OUTPUT，将具体的需求转化为实际的可以操作的架构设计，这样的一个"中间人"往往在一个产品的生命周期中扮演者举足轻重的角色。
　　Web 集成测试的痛点
　　而 Web 项目区别于其他项目的本质原因在于，它直接面对需求的提出者--客户，而这部分的需求变动也是为活跃的。也是因为这样，往往很多时候我们对于 web 的开发要求的是，快速！但这样的观点仅于在 UI 或者 Web 编程方面，对于与底层系统的集成往往素手无策？因为底层系统一般来说是公司产品的核心内容，也遵循着典型的产品开发模式，在需求变更方面也显得很谨慎而小心。面对突入其来的的需求变动，底层系统往往很难跟的上节奏，而且很多时候 Web 的开发和底层系统的开发是分开的，或者分属于不同的开发部门，即使是一个方法级别的调用，会浪费掉大家很多的沟通成本，接口的变更或者是 API 的向下兼容这些都是翻来覆去争论的话题。由于大家所处的开发领域不同，工作的方式，方法的不同，甚至是编程语言的差别，这些问题终会暴露在集成测试这里，从而影响整体项目的开发进度。
　　这里有一个真实的案例。在 Web 开发中，我们遇到了大数据显示的问题，分页显示无疑是合适，也很容易想到的解决方案。但由于其他的因素，底层系统无法在既定的项目期限内给予 API 方面的支持，在经过深入的沟通和相互理解之后发现，这样的功能在系统层面这个角度来说，属于优先级较低的功能。而且在他们开来，客户往往更习惯于使用命令行查看结果，并没有提出这样的需求，当然这样的争论是没有意义的，大家看待问题的角度不同，我们也不能一概而论，毕竟还是还有一些客户并不属于"专业级"用户，或者由于其他的原因的限制，他们不得不选择使用浏览器查看执行结果，面对这样的情况，摆在 Web 开发人员面前的问题是如何在既定的情况下修改已有的结构，从而支持数据分页并且保证足够的可扩展性，以保证在未来底层系统可能支持的情况下，将代码修改的成本降低到小？
　　解决思路和方案
　　问题已经暴露出来，让我们畅想一下期望的开发模式是什么，可能更容易让我们审核目前的问题，并找到佳的解决方案。让我们畅想一下，如果我们在 Web 开发阶段没有这么多的顾虑而专注于功能本身，或者说我们总是假定底层系统足够的强大，并支持所有可能的的需求变更，是不是没有这样的问题了？那么是否真的有这样的一个框架开始关注于这些问题，从而将 Web 开发人员解放出来，使其更加关注于自身领域的的需求呢？换句话说我们需要一个"模拟"的底层系统，它返回所有我们希望的结果，从而让我们将所有的注意力放在 Web 这个层面，对，这是要介绍的 Moco！
　　Moco 是什么
　　作者是这样描述 Moco 的：
　　Moco是一个简单搭建模拟服务器的程序库/工具，这个基于 Java 开发的开源项目已经在 Github 上获得了不少的关注。该项目的简介是这样描述自己的：Moco 是一个简单搭建 stub 的框架，主要用于测试和集成。这个框架的开发灵感来自 Mock 框架，如 Mockito 和 Playframework。
　　为什么要开发这个框架？
　　集成，尤其是基于 HTTP 协议的集成——web service、REST 等，在我们的项目开发中被广泛应用。以前，我们每次都要往 Jetty 或 Tomcat 等应用服务器上部署一个新的 WAR。大家都知道，开发部署一个 WAR 的过程是很枯燥的，即使在嵌入式服务器上也是如此。而且，每次我们做一点改动，整个 WAR 都要重新组装。
　　Moco 的出现，正是为了解决这些问题。开发团队只要根据自己的需要进行相应的配置，会很方便得到一个模拟服务器。而且，由于 Moco 本身的灵活性，其用途已经不再局限于初的集成测试，比如，Moco 可以用于移动开发，模拟尚未开发的服务；Moco 还可以用于前端开发，模拟一个完整的 Web 服务器，等等。