随着公司业务架构的越来越复杂，系统架构根据业务进行了拆分，各业务之间通过 RESTful API 规范进行调用。在测试环节，大家各自做好各业务的测试，然后再进行集成测试，但是在实践过程中会发现由于各业务之间的 API 变更频繁，无法及时通知其它被调用方，导致在各自的 Unit 测试环节没有问题，但是集成测试时，就会出现各种问题。线上的业务监控也反馈出同样的问题。更多的时候是因为组件间的测试不充分或者沟通不到位，引发线上问题，然后各组件间相互推诿，产品质量反而下降。针对这种情况，大家有什么好的测试方案来解决呢。欢迎大家一起来讨论。
目前有个 Contract 集成测试（契约测试）的方案，但这个是从开发者的角度发出来解决的。从测试的角度来说，有什么好的方案呢
各业务之间的 API 变更频繁，无法及时通知其它被调用方，导致在各自的 Unit 测试环节没有问题，但是集成测试时，就会出现各种问题
把各业务间的 API 封装成一些契约包，api 变更后契约包也自动改变，避免用了已废弃的契约却不自知。当然，api 变更的通知也得做好。
这个问题通过测试把关不是不行（例如一直维护着一份针对当前 api 的全量接口测试脚本，api 变更后脚本率先发现），但个人觉得效率不高，从开发底层上做效率会更高。
至于每个组件只管自己，不从全局考虑，这个就要靠测试去推动了，例如开始进入测试阶段的标准是全流程冒烟通过，而不仅仅是其中各组件独立跑通。
契约测试还没有尝试过，同意你的观点，由测试来维护全量的 API，监听变更效率不高，而且没法通知到被调用方。
全流程冒烟测试有再做，但是出问题的往往都是细节，冒烟测试无法覆盖到
之前呆过的两个公司有两种做法：
1、设立联调组。从需求确定的时候开始，就确定一个需求是否需要联调，如果需要，各方系统测试完成后，联调组组织端到端的联调测试。这个是传统公司的做法，一般上线周期 3 到 4 周
2、设立联调环境。每个模块/项目，都要提供稳定的预发布的包。供各方在日常测试中测试。这种一般是约定 2-3 天的联调环境预发布。联调环境没有问题了，才可以上线。
我觉得还有第三条路，开发一个测试工具，监控对外提供的 api 方法跟参数列表变化（比如制定哪几个代码文件，所有的对外 api 都在这这定义），有变化自动通知订阅方。