别再加端到端集成测试了，快换契约测试吧

发布时间：2025-11-05 06:00:19 来源：码上建站 作者：数据库

正如大家所知，别再最初QA都是加端集成手动执行测试用例，开发人员每修改一个版本，到端QA就要手动测试一遍，测试测试随着功能的快换不断增加，手动测试重复的契约工作量越来越大。为了解脱QA重复性劳动，别再提高工作效率，加端集成重复执行的到端测试用例被自动化了。自动化测试让QA的测试测试工作前进了一大步。

本文讲的快换端到端集成测试(简称集成测试)是指系统集成后的自动化测试，是契约系统或模块真实组装后运行的测试。很多团队用UI端到端来测系统集成后的别再行为，这类工具很多，加端集成比如有Selenium webdriver等。到端端到端的集成测试反馈与修复的周期比较长、运行速度慢，测试运行不稳定，有时随机失败，维护成本也很高。它不像单元测试，源码库单元测试测具体一个方法或API，定位准确，采用Mock机制，运行速度非常快(毫秒级)，又是开发人员在本地执行，反馈修复及时，成本较低。

于是，我们把绝大部分能在单元测试里覆盖的用例都放在单元测试覆盖，只有单元测试测不了的(比如模块或API之间连通性)，才会通过端到端的集成测试来覆盖。此时，测试又前进了一大步。

但是，随着业务的不断拓展、产品功能不断增加，系统架构越来越复杂，端对端集成测试的成本越来越高，测试用例也越增越多，集成测试又成了快速验证的阻塞区。在当今持续集成的开发模式中，开发团队会频繁集成，每次集成都会通过流水线(Pipeline)快速验证、b2b信息网准备部署包、进而发布。然而，集成测试的这些问题会严重影响或阻碍产品快速发布。

那么问题来了，怎么解决集成测试的现有问题，让测试再前进一大步?

其实，早在几年前，著名的敏捷和TDD专家JB Rainsberger就提到了。

JB Rainsberger认为你写的2-5%的集成测试和单元测试有重复，或者和其它地方的集成测试存在重复，而且当集成测试失败时，你也不知道发生了什么，不能及时准确定位问题。

JB Rainsberger认为应该让契约测试来替代集成测试，那么，什么是契约测试?它是否能解决集成测试的这些问题?

契约测试

契约测试是验证服务的Provider是亿华云否按照期望的方式与服务的Consumer进行交互，简单的说是Consumer与Provider两者之间的集成。

而Contract即合同、契约，就是Provider与Consumer的交互方式。

契约测试通常是基于Consumer驱动的(Consumer Driven Contracts，基于Consumer驱动的契约测试工具有PACT)。基于Consumer驱动的契约测试分两个阶段：

第一阶段：Consumer生成契约

第二阶段：Provider验证契约

如何用PACT编写契约测试，这里就不赘述了，实例详情请参见PACT an example。

集成测试的特点：

契约测试的特点：

由此可见，开篇谈到的端到端集成测试运行慢、不稳定、修复反馈周期长等等问题，都能通过契约测试得到解决或改进。

举例说明

假如某社交聊天产品(简称TWChat)的架构是这样的：服务端、客户端、邮件通知服务三部分组成。

架构图

通常的测试策略：底层绝大部分的单元测试+少量上层端到端集成测试。

用TWChat注册场景来举例说明吧。注册一个帐号的工作流是：客户端把注册帐号信息提交给服务端，服务端处理帐号时，会去调用邮件通知服务发通知，并完成注册。

底层单元测试用例

单元测试

上层端到端集成测试用例

集成测试

一条注册连通性的Happy path测试用例, 输入所有必填项提交，验证注册成功，收到成功通知邮件。

以上的集成测试，必填项输入其实是与单元测试重复，邮件通知发送功能与单元测试也有重复;再者，这条集成测试跑失败，我们并不能定位是客户端的问题、服务端问题、还是通知服务的问题。加上集成测试是把所有子模块(服务端、客户端、通知微服务)真实产品安装包部署以后才能运行的测试，反馈、修改周期长，不稳定容易随机失败等等。

集成测试换成契约测试用例

契约测试

契约测试与单元测试以及其它测试之间没有重复，它是单纯验证Provider与Consumer之间按预期的方式交互，定位准确;不需要部署真实的系统环境、Mock机制、没有真实API调用，运行非常快、反馈及时、修复周期短、成本低，在这种情况下，自动化测试流水线运行更快了，产品流水线出产品安装包也更快。因此，显然契约测试才是真正对的选择。

微服务架构下契约测试的重要性

例如，随着TWChat业务的扩大，TWChat钱包，TWChat安卓端，TWChat iOS端，以及其它的服务方与Consumer方接入TWChat服务器。

当其中TWChat安卓端修改后，如果还按照之前的集成测试方式，就得把服务端与所有的客户端真实的集成到一起测试，确保都没有被影响才能生成产品安装包并发布，这里的集成测试成了流水线(pipeline)的一个聚集地，也成为了产品发布的阻塞区。

集成测试流水线

假如，换成契约测试，我们把契约测试放在各自的流水线(pipeline)上，每次代码提交触发相应产品流水线上的契约测试，当TWChat安卓客户端Consumer API修改，在安卓客户端的流水线(pipeline)上运行安卓客户端为Consumer与服务端为Provider的契约测试，测试通过，生成产品安装包;如果契约测试失败，服务端需要相应修改，则本次TWChat安卓端的安装包需要在TWChat服务端修改后，方可生成安卓客户端的产品安装包。

契约测试解耦后

由此可见，并不是每一次TWChat安卓端的修改都要全部Consumer端与服务端集成后验证才出包，而是各自可以独立出包，产品解耦，大大节省时间，提高出包频率。

并非所有端到端集成测试都适合换成契约测试

契约测试相比端到端集成测试有很多优势，但并不是所有场景都适合契约而非集成测试。

比如：

所以，把端到端集成测试要换成契约测试也不是绝对的，视情况而定。

总的来说，当你追加端到端集成测试的时候，如非特殊，快换契约测试吧。

【本文是专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】

戳这里，看该作者更多好文

相关文章