针对混乱的调用关系，思路是：我的被测服务就是服务 A，那么我不用管服务 B 是不是好用，只要保障服务 A 能够走完流程，就可以完成接口测试任务了。循着这个思路，只要用 Mock 服务伪装成服务 B 就万事大吉了，我也不用再关心服务 B 到底调用了多少服务。
应该怎么选择 Mock 服务框架呢？
首先，你要基于自己和团队的技术栈来做选择
其次，你要让写好的 Mock 服务容易修改和维护
如果你的团队技术基础很好，开发能力很强，那么我建议你用对应语言的 Mock 框架，例如 Java 语言的Mockito 框架（https://github.com/mockito/mockito）和 Python 语言的mock 框架（mock · PyPI）。
如果你的团队技术基础相对比较薄弱，那么我推荐你看看moco，这个框架在开发 Mock 服务的时候，提供了一种不需要任何编程语言的方式，你可以通过撰写它约束的 Json 建立服务，并通过命令启动对应的服务，这就可以快速开发和启动运行你需要的 Mock 服务。
Mock 服务设计经验
首先，简单是第一要素。无论原服务 B 处理了多么复杂的业务流程，你在设计服务 B 的 Mock 服务时，只要关心服务 B 可以处理几种类型的参数组合，对应的服务都会返回什么样的参数就可以了。这样你就能快速抓住 Mock 服务 B 的设计核心，也能快速完成 Mock 服务 B 的开发。
其次，处理速度比完美的 Mock 服务更重要。一个 Mock 服务要能按照原服务正确又快速地返回参数，你不需要把大量的时间都浪费在 Mock 服务的调用上，它只是用来辅助你完成接口测试的一个手段。
最后，你的 Mock 服务要能轻量化启动，并且容易销毁。你要时刻注意，Mock 服务只是一个辅助服务，因此，任何一个团队都不希望启动一个 Mock 服务需要等待 5 分钟，或者需要 100M 的内存。它要能快速启动、容易修改并且方便迁移。既然 Mock 服务的定位是轻量化的辅助服务，那么它也要容易销毁，以便你在完成测试后，可以快速且便捷地释放它所占据的资源。