最近接触到契约测试，个人感觉还是挺有用的，不知道大家有没有在实际工作中使用？
可行性和适用性怎么样
可以先统计下，发现的缺陷里有多少是可以通过这个契约测试发现的？
每个团队不大一样，关键还是看自己是否适用。我之前所在团队由于契约都是封装成 rpc 调用，每次升级只新增，不改旧的，确保向下兼容，所以不大需要专门做契约测试。
研究过，还没落地，契约测试本身难度不高，更多的是流程规范问题，谁来维护这个契约，什么时候使用
cool
回复
When all you have is a hammer everything looks like a nail... 官网说的
Elsie
回复
就是服务间调用都是封装成 rpc ，provider 把接口以独立 api 包形式提供给 consumer，consumer 引入后直接调用 api 包里提供的函数方法。可以参考下 dubbo 。
个人理解，系统间契约，基本就是客户端 - 服务端、服务端 - 服务端、内部系统 - 外部第三方三种场景。
第一种基本上会从设计层面确保向下兼容（客户端多版本并存特性决定必须这么做），比如只增不删不改。
第三种依赖第三方，一般上线后除非第三方变化，否则也不怎么会动
第二种数量最多，也最容易出现契约测试里提到的问题（一个接口 n 个服务调用，怎么确保调整后不影响其他服务）。但通过 rpc 调用，隐藏实际报文细节，再加上类似第一种的设计方式，也基本能保障不会因为某次改动影响其他服务，即使影响，只要大家更新 api 包，编译时就会发现和修正，也不用特意去测试。
所以说实话，个人没太想到契约测试在实际项目中能解决什么问题。不过这个只是我自己接触项目的情况，建议你可以结合你们实际项目中发现的问题，分析下有哪类问题是契约测试可以提前发现并解决的，如果发现有不少，也是可以去尝试落地的。
