新的挑战
　　微服务和传统的单块应用相比，在测试策略上，会有一些不太一样的地方。简单来说，在微服务架构中，测试的层次变得更多，而且对环境的搭建要求更高。比如对单块应用，在一个机器上可以setup出所有的依赖，但是在微服务场景下，由于依赖的服务往往很多，要搭建一个完整的环境非常困难，这对团队的DevOps的能力也有比较高的要求。
　　相对于单块来说，微服务架构具有以下特点：
　　· 每个微服务在物理上分属不同进程
　　· 服务间往往通过RESTful来集成
　　· 多语言，多数据库，多运行时
　　· 网络的不可靠特性
　　· 不同的团队和交付周期
　　上述的这些微服务环境的特点，决定了在微服务场景中进行测试自然会面临的一些挑战：
　　· 服务间依赖关系复杂
　　· 需要为每个不同语言，不同数据库的服务搭建各自的环境
　　· 端到端测试时，环境准备复杂
　　· 网络的不可靠会导致测试套件的不稳定
　　· 团队之间的沟通成本
　　测试的分层
　　相比于常见的三层测试金字塔，在微服务场景下，这个层次可以被扩展为5层（如果将UI测试单独抽取出来，可以分为六层）。
　　· 单元测试
　　· 集成测试
　　· 组件测试
　　· 契约测试
　　· 端到端测试

　　和测试金字塔的基本原则相同：
　　1、越往上，越接近业务/终用户；越往下，越接近开发
　　2、越往上，测试用例越少
　　3、越往上，测试成本越高（越耗时，失败时的信息越模糊，越难跟踪）
　　单元测试
　　单元测试，即每个微服务内部，对于领域对象，领域逻辑的测试。它的隔离性比较高，无需其他依赖，执行速度较快。
　　对于业务规则：
　　1、商用软件需要License才可以使用，License有时间限制
　　2、需要License的软件在到期之前，系统需要发出告警

　　上面这个例子是一个非常典型的单元测试，它和其他组件基本上没有依赖。即使要测试的对象对其他类有依赖，我们会Stub/Mock的手段来将这些依赖消除，比如使用mockito/PowerMock。
　　集成测试
　　系统内模块（一个模块对其周边的依赖项）间的集成，系统间的集成都可以归类为集成测试。比如
　　· 数据库访问模块与数据库的集成
　　· 对外部service依赖的测试，比如对第三方支付，通知等服务的集成
　　集成测试强调模块和外部的交互的验证，在集成测试时，通常会涉及到外部的组件，比如数据库，第三方服务。这时候需要尽可能真实的去与外部组件进行交互，比如使用和真实环境相同类型的数据库，采用独立模式（Standalone）的WireMock来启动外部依赖的RESTful系统。
　　通常会用来做模拟外部依赖工具包括：
　　· WireMock
　　· mountebank
　　其中，mountbank还支持Socket级别的Mock，可以在非HTTP协议的场景中使用。