a. 集成契约测试
在集成契约测试中，每个组件都需要独立调用，并且必须满足消费服务（consumer）预期的契约协议。解决这个问题的最佳方法是对double进行测试。另一方面，定期运行一组单独的测试以确认测试double没有变化至关重要。不过，一旦出现测试失败，会降低部署管道的速度并破坏IT基础架构或分布式系统的功能。处理间歇性测试失败的最佳方法之一是更新测试double，同时可能也需要更新代码，以便可以使其恢复到与外部服务一致的状态。
b. 消费者驱动（consumer-driven）契约测试
在消费者驱动的契约测试中，消费者将描述他们想要使用服务的方式。消费者契约可以在生产者和消费者之间以相互同意的语言和模式进行。服务提供商将针对各个契约的副本测试服务，然后对该特定服务进行更改，而不会影响其他服务的性质。
单服务自身的测试
系统被拆分成独立的服务，每个服务都是一个完整的小系统，此方面的测试与单一应用的测试手段基本一致，主要是保证服务自身的业务功能正确性。所采用的测试手段主要为：API接口测试、单元测试。
API接口测试
API包括对外提供的用于与其他服务之间相互通信的接口，以及对内提供用于各函数之间相互调用的接口，与单一应用不同，微服务架构依赖于进程间通信（IPC）机制来正常运行，这就是为什么必须验证服务之间的交互。测试一般会采用自动化的方式开展测试工作，以通过与外部服务和数据存储的集成来映射成功或错误的情况。
单元测试（Unit Testing）
服务细分之后从某种意义上让单元测试更加易于编写，可以借助Mock来屏蔽掉对其他服务依赖。单元测试的范围可以是一组服务，也可以是单独的一个服务。被测试的单元粒度越小，就越容易确定模块的行为，越容易在源头发现产品质量上的问题。
在针对具体项目的测试策略制定时，需要根据具体实际情况灵活调整，在后续的文章中，我们会将实践中的更多成果与大家分享。