微服务架构下，测试分为三个层次：
端到端测试：覆盖整个系统，一般在用户界面机型测试。
服务测试：针对服务接口进行测试。
单元测试：针对代码单元进行测试。
三种测试从上到下实施的容易程度递增，但是测试效果递减。
端到端测试最费时费力，但是通过测试后我们对系统最有信心。
单元测试最容易实施，效率也最高，但是测试后不能保证整个系统没有问题。
由于端到端测试实施难度较大，一般只对核心功能做端到端测试。一旦端到端测试失败，则需要将其分解到单元测试：则分析失败原因，然后编写单元测试来重现这个问题，这样未来我们便可以更快地捕获同样的错误。
服务测试的难度在于服务会经常依赖一些其他服务。
这个问题可以通过Mock Server解决：
单元测试大家都很熟悉了。我们一般会编写大量的单元测试（包括回归测试）尽量覆盖所有代码。
指标接口、链路跟踪注入、日志引流、服务注册发现、路由规则等组件以及熔断、限流等功能都需要在应用服务上添加一些对接代码。如果让每个应用服务自己实现是非常耗时耗力的。基于DRY的原则，开源的世界中有很多微服务框架，将与各个组件对接的代码和另外一些公共代码抽离到框架中，所有的应用服务都统一使用这套框架进行开发。
使用微服务框架可以实现很多自定义的功能。甚至可以将程序调用堆栈信息注入到链路跟踪，实现代码级别的链路跟踪。或者输出线程池、连接池的状态信息，实时监控服务底层状态。
使用统一的微服务框架有一个比较严重的问题：
框架更新成本很高。每次框架升级，都需要所有应用服务配合升级。当然，一般会使用兼容方案，留出一段并行时间等待所有应用服务升级。但是如果应用服务非常多时，升级时间可能会非常漫长。并且有一些很稳定几乎不更新的应用服务，其负责人可能会拒绝升级……
因此，使用统一微服务框架需要完善的版本管理方法和开发管理规范。
微服务不是架构演变的终点。往细走还有 Serverless、FaaS 等方向。
另一方面也有人在唱合久必分分久必合，重新发现单体架构……
