本文说的集成测试是指系统集成后的自动化测试。（也可以说是系统端对端的集成测试）
是的，最初QA都是手动执行测试用例，开发人员每修改一个版本，测试人员就要手动测试一遍，随着功能的不断增加，重复工作量越来越大。为了解脱QA重复性劳动，提高工作效率，重复执行的测试用例被自动化了。
上述的自动化测试都是系统集成后的自动化测试，它的出现让QA的工作前进了一大步。然而，集成测试是系统或模块真实组装后的测试，反馈与修复的周期比较长、运行速度慢，测试运行不稳定，有时随机失败，维护成本也很高。它不像单元测试，单元测试测具体一个方法或API，定位准确，采用Mock机制，运行速度非常快（毫秒级），又是开发本地执行，反馈修复及时，成本较低。所以，测试分层后，把绝大部分能在单元测试里覆盖的用例都在单元测试覆盖，只有单元测试测不了的（比如模块或API之间连通性），会通过集成测试来覆盖，见下面测试分层图（有时上层UI和集成会一起测）。
自动化测试分层之后，测试又前进了一大步。但是，随业务的不断拓展、产品功能不断增加，系统架构越来越复杂，集成成本越来越高，测试用例也越增越多，集成测试又成了快速验证的阻塞区。在当今持续集成的开发模式中，开发团队会频繁集成，每次集成都会通过流水线（Pipeline）快速验证出包。然而，集成测试的这些问题会严重影响或阻碍产品快速出包。
那么，问题来了，怎么解决集成测试的现有问题，让测试再前进一大步？
其实，早在几年前，著名的敏捷和TDD专家[JB Rainsberger]就提到了。
“集成测试是个骗局”，正确的是应该用一种契约或协议测试来测试集成后的系统行为！他认为你写的2-5%的集成测试和单元测试有重复，或者和其它地方的集成测试存在重复，而且当集成测试失败时，你也不知道发生了什么，不能及时准确定位问题。
JB Rainsberger认为应该让契约测试来替代集成测试，那么，什么是契约测试？它是否能解决集成测试的这些问题？
契约测试：
契约测试是验证服务的Provider是否按照期望的方式与服务的Consumer进行交互，简单的说是Consumer与Provider两者之间的集成。而Contract即合同、契约，就是Provider与Consumer的交互方式。
契约测试通常是基于消费者驱动的契约测试（Consumer Driven Contracts，基于消费者驱动的契约测试工具有PACT）。基于消费者驱动的契约测试分两个阶段：
（1）Consumer生成契约，开发者在Consumer端写测试时Mock掉Provider，运行测试生成契约文件；
（2）Provider验证契约，开发者拿契约文件直接在Provider端运行测试进行验证。
如何用PACT编写契约测试，这里就不赘述了，实例详情请参见PACT an example。
契约测试对比系统集成测试
集成测试的特点：
(1)真实安装后测试，测试更接近真实使用情况；
(2)可见性强，容易理解。（比如：看一遍跑关键业务的集成测试，业务人员或客户会觉得很放心。也可以作为验收测试）
(3)模块或系统真实调用，测试运行慢，秒级别或分钟级别，反馈与修复的周期慢，成本高；
(4)问题定位难，由于多个子模块或子系统真实安装后，很难定位是哪个模块出的问题；
(5)真实的安装或环境搭建，不稳定，容易导致测试随机失败；
(6)沟通成本高，需要不同模块团队间的协调工作；
(7)与底层测试或集成测试会有重复，集成测试中有的路径单元测试已经覆盖。
契约测试的特点：
(1)开发人编写，采用Mock机制，开发本地就可以运行，没有真实调用，运行快，毫秒级修复反馈周期短；
(2)Provider与Consumer两两之间的验证，容易定位问题，而且与底层测试或其它契约之间没有重复；
(3)不需要部署真实的集成环境，稳定成功率高；
(4)沟通成本低；(比如一个消费端的加入导致服务端API修改，服务端开发人员不必跑去找所有其它消费端开发人员沟通确认是否会被影响，直接运行契约测试就能知道结果。）
由此可见，开篇谈到的系统集成测试运行慢、不稳定、修复反馈周期长等等问题，换成契约测试都能得以解决或改进。
举例说明
假如某社交聊天产品（简称TWChat）的架构是这样的：服务端、客户端、邮件通知服务三部分组成。
通常的测试策略：底层绝大部分的单元测试+少量上层系统集成测试。
用TWChat注册场景来举例说明吧。注册一个帐号的工作流是：客户端把注册帐号信息提交给服务端，服务端处理帐号时，会去调用邮件通知服务发通知，并完成注册。
底层单元测试用例：
(1)客户端的单元测试：验证注册表各个Field的各种输入组合、以及检验正确性等。比如：边界值、空、中英数各类组合、合法与非法输入等。
(2)服务端的单元测试：验证注册数据表的各种输入组合可以成功存放于服务端帐号DB表中，且不合法的、重复等会有相应的错误码。
(3)邮箱通知服务端的单元测试：输入合法的各类不同的邮箱确保能正常发出通知邮件并返回正确码，输入不合法的邮箱或空邮箱确保有相应的错误码。
上层集成测试用例：
(1)一条注册连通性的Happy path测试用例, 输入所有必填项提交，验证注册成功，收到成功通知邮件。
以上的集成测试，必填项输入其实是与单元测试重复，邮件通知发送功能与单元测试也有重复；再者，这条集成测试跑失败，我们并不能定位是客户端的问题、服务端问题、还是通知服务的问题。加上集成测试是把所有子模块（服务端、客户端、通知微服务）真实产品安装包部署以后，才能运行的测试，反馈、修改周期长，不稳定容易随机失败等等。
系统集成换成契约测试用例：
(1)TWChat客户端Consumer与TWChat服务端Provider加一条契约测试，确保TWChat服务端按期望提供给客户端接口(参见PACT an example)。
(2)TWChat服务端Consumer与邮件通知服务Provider之间加一条契约测试，确保邮件通知服务按照预期与TWChat服务端交互(参见PACT an example)。
契约测试与单元测试以及其它测试之间没有重复，它是单纯验证Provider与Consumer之间按预期的方式交互，定位准确；不需要部署真实的系统环境、Mock机制、没有真实API调用，运行非常快、反馈及时、修复周期短、成本低，在这种情况下，自动化测试流水线运行更快了，产品流水线出产品安装包也更快。因此，显然契约测试才是真正对的选择。
微服务架构下更显契约测试的必要性
例如，随着TWChat业务的扩大，TWChat钱包，TWChat安卓端，TWChat iOS端，以及其它的服务方与消费方接入TWChat 服务器。
当其中TWChat安卓端修改后，如果还按照之前的系统集成测试方式，就得把服务端与所有的客户端真实的集成到一起测试，确保都没有被影响才能出包发布，这里的集成测试成了流水线（pipeline)的一个聚集地，也成为了产品发布的阻塞区。
假如，换成契约测试，我们把契约测试放在各自的流水线（pipeline）上，每次代码提交触发相应产品流水线上的契约测试，当TWChat安卓消费端Api修改，在安卓消费端的流水线（pipeline）上运行安卓端与服务端的契约测试，要是测试通过，真接出包；要是契约测试失败，服务端需要相应修改，那么本次TWChat安卓端的出包需要在TWChat服务端修改出包后，才能出安卓客户端的安装包。
由此可见，并不是每一次TWChat安卓端的修改都要全部消费端与服务端集成验证才出包，而是各自可以独立出包，产品解耦，大大节省时间，提高出包频率。
契约测试能完全取代系统集成测试吗
契约测试无法实现安全或性能测试等。
契约测试采用Mock机制，所以没有集成测试更接近真实环境，也不能给业务人员做验收，可视性差。
基于不同的服务使用的协议不同，验证契约的复杂度会不同，复杂度过高时，需要权衡是否有必要加契约测试。
所以，把系统集成测试都要换成契约测试也不是绝对的，视情况而定。
总的来说，当你追加集成测试的时候，如非特殊情况， 快换契约测试吧。