微服务化架构下，微服务自身依赖的第三方服务、数据越来越多，给传统的测试方式带来很多困难，如被依赖的线下服务不稳定；服务无法提供期望的响应数据；缺少测试场景构造标准等。针对这些问题，一般能想到的思路是提高测试环境稳定性、自己构造测试数据和测试场景等方式，提高测试的确定性和有效性，但这些方式不能从根本上解决问题。比如，服务不稳定的情况仍然无法避免，通过更改代码注入对象等方式不仅繁杂而且非常容易出错，并且没有一定的依据，构造的测试场景不充分，心里没底。
一、流量录制回放测试
针对上述微服务测试的不足，尝试流量录制和回放解决方案，通过一定的方式将线上的真实流量录制下来，在线下进行回放。线下测试时，基于线上的回放流量可以灵活地测试服务的各自功能，还可以基于回放流量进行编辑修改，对服务依赖的第三方请求进行mock和定制，使代码开发变得简单方便，且可随改随测，解决RD开发不便、自测流程过长的问题。
录制的流量要包含服务的请求/返回流量，以及能关联上的与其对应的第三方交互流量。如果仅有服务的请求/返回流量，则只能被应用在查询类只读系统中，应用范围受限；如果第三方交互不能和请求正确关联，则无法正确应用这些流量。
要解决流量的关联难题，一个解决方案是将流量整流，使其串行化。将线上原本服务并行流量的一台机器，控制其接收到的流量，将其服务的流量降低至串行，且流量之间间隔一定的时间（以便给异步第三方请求预留时间），那么这些流量的请求/响应和其第三方交互流量就被自动地关联了起来。
如何将请求和第三方交互流量关联起来，可以基于分布式跟踪技术将请求和对第三方系统调用的流量关联起来。但这种方式难点是并非所有第三方交互流量都带有请求跟踪标识。还有一种思路是通过拦截语言层面的系统调用，将请求和对第三方系统的调用进行关联。
二、仿真环境测试
作为在线服务，为了满足灰度发布、测试等多维度的需求，一般需要支持灵活的分流策略，将流量调度到不同的环境中。为了支持精细的灰度发布策略，需要根据一定的规则将线上流量分流到小流量集群，为了支持使用真实流量进行高仿真测试，还需要根据策略规则将一定流量引到仿真环境中。
小流量分流的特点是流量发往小流量集群后，不再进行任何处理，直接等待小流量集群的返回结果，然后将该结果转发给调用侧。仿真环境分流的特点是发往仿真环境的流量只是一份“影子”流量，相当于Oneway请求（不需要应答消息），对业务处理过程没有任何影响，还是和没有仿真环境的情况下一样处理。
仿真环境支持可以在服务框架层面进行，为了实现基于请求内容的路由和转发，框架充当了一个Proxy的角色，将请求解析后再发包发送给下游环境。基于仿真流量的特点，为了不对业务产生影响，发送到下游仿真环境的超时时间可以设置得非常小，即使有一些流量超时也没有关系，同时为了在自动生成的代码框架下实现仿真环境处理后的Oneway效果，可以自定义一个传输层，这个传输层的具体实现是什么都不进行处理，直接丢弃即可。
