微服务体系结构为在哪里以及如何进行测试提供了更多的选项。
通过将系统分解为定义良好的小服务，暴露了以前隐藏的附加边界。这些边界在可采用的测试类型和级别方面提供了机会和灵活性。
在某些情况下，微服务可能封装具有复杂需求的中央业务流程。这个过程的关键可能需要对服务进行非常全面的测试，例如这里讨论的所有测试策略。在其他情况下，微服务可能是试验性的，从业务角度看不那么重要，或者可能生命周期很短。所需要的测试水平可能较低，因此只有一些策略是有意义的。
虽然这种决策制定过程在单片体系结构中仍然是可能的，但是添加清晰、定义良好的边界可以更容易地看到系统的组件并独立地对待它们。
测试金字塔帮助我们在不同类型的测试之间保持平衡
一般来说，测试的粒度越粗，就越脆弱，执行起来越耗时，编写和维护起来也越困难。这种额外的费用源于这样一个事实，即这种测试自然涉及更多的活动部分，而不是更细粒度的集中部分。
测试金字塔的概念是一种考虑在每个粒度上应该编写的测试的相对数量的简单方法。随着金字塔层的上升，测试的范围会增加，而应该编写的测试数量会减少。
金字塔的顶端是探索性测试，以脚本测试中没有考虑到的方式手动探索系统。探索性测试允许团队了解系统，并教育和改进他们的自动化测试。
通过遵循测试金字塔的指导方针，我们可以避免通过维护和执行成本昂贵的大型测试套件而降低测试的价值。
总之
单元测试:测试应用程序中可测试软件的最小部分，以确定它们的行为是否如预期的那样。
集成测试:验证组件之间的通信路径和交互，以检测接口缺陷。
组件测试:将被测试软件的范围限制在被测试系统的一部分，通过内部代码接口操作系统，并使用测试双精度(test double)将被测试代码与其他组件隔离开来。
契约测试:验证外部服务边界上的交互，断言它满足消费服务所期望的契约。
端到端测试:验证系统满足外部需求并实现其目标，从端到端测试整个系统。