使用场景

前端客户端团队和后端服务端团队往往节奏是不一致的。前端很多情况下需要等待后台的api开发完成后才能进行开发联调和测试，这种前后端不对称就造成了前后端团队节奏不一致，从而造成整个项目/产品交付/发布延期。

有一种解决方案的思路是前后端先约定好后端提供的api接口的细节，前端人员自行先模拟出这些后端的实现，当然这些实现是假的，不过前端可以去调用这些假的实现，而且能拿到返回，这样一来前端就不需要等待后端开发完成才开始工作了。

但是这样还是会有问题，前端实现的假的api没办法迅速反映出后端的变化。简单来说就是后端可能在约定好的api接口上进行了些许修改，而没有知会前端人员，这样前端的假的api实现并没有相应更新，在正式联调时就会出现问题。

像这种假的api实现，不管是前端实现的还是后端去实现的，我们可以称之为mock server。

• mock表示这个api返回的数据是假的，仅作为测试用的
• server表示需要启动服务，说到底这是一个服务程序

契约测试

由于前后端往往有一些信息不对称，导致约定的api可能在前后端都会发生变化，所以保证前后端的一致性就成了一个挑战。

这时候有人提出了契约测试，大致思想是前后端共用一份契约，约定了api的细节，前后端的任何变化都需要先修改契约，然后通过契约去通知前后端团队，统一更新实现。这也是契约精神的表现。

如果为契约测试设置一种测试工具的话，我会规划下面一些特性

• 契约的描述工具：也就是契约长什么样子，用什么工具去定义才能让前后端团队秒懂

• 通过契约自动生成mock server实现，这样前端团队就可以拿来即用了，如果契约修改了，那么前端团队也很容易感知到

• 通过契约自动生成接口测试用例，这样通过持续运行这些接口测试用例，后端团队就可以第一时间发现契约的修改