流量录制回放是什么？
流量录制
在不影响用户正常使用的前提下，获取线上用户的真实请求和服务响应结果，将其保存或者转发到目标应用。
采用不同的流量录制手段，可以采集不同传输阶段的流量。
流量复制方式
① 基于应用层的复制：
优点：实现简单；可以实现应用内部方法级的流量录制；
缺点：拓展性差，一般支持某种协议；复制从应用层开始，穿过整个协议栈，通常要占用底层的资源；
与应用耦合一起，容易对应用造成影响，比如超时；会出现丢包的情况。
② 基于数据包的复制
缺点：复杂，难度大。
优点：不需要穿过整个协议栈，对资源的占用相对较低；理论上支持此协议上的所有应用层协议录制。
流量回放方式
- 在线方式：将复制的流量实时地转发到目标服务上。
- 离线方式：将复制的流量先保存到数据库或文件中，再将处理或筛选后的流量回放到目标服务。
流量录制回放的几点思考：
1、流量录制回放与传统接口自动化测试的区别？
流量录制回放提供了一种新的接口自动化测试方法。与传统接口自动化测试相比，流量回放最大的优势是降低了测试数据和用例编写的成本。利用流量即用例的思想，我们可以直接将线上流量转化成接口测试用例，从而避免了繁琐的测试数据准备和脚本编写工作。
同时，线上流量覆盖更全面、数据更真实，使用线上流量作为测试数据，与人工构造测试数据相比，能够更真实、更全面地覆盖业务场景，提升用例发现问题的能力。
但是由于录制流量的独立性，流量回放主要用于单接口测试。对于需要多个接口组合才能覆盖的测试场景，流量回放无法支持，需要采用传统的接口自动化测试方法。
2、读接口回放和写接口回放有什么区别？
在流量回放中，读接口和写接口回放的方式有很大不同。事实上，这不只是流量回放的特点。即使是传统接口自动化测试，读接口和写接口的测试策略也是有很大不同的。
读接口和写接口的不同，在于读接口没有副作用(side effect)，而写接口有副作用。写接口的副作用通常体现在会对被测系统产生脏数据上。为了避免副作用，写接口的测试有两种实现方式：
(1) 使用Mock对中间件/外部依赖进行隔离。
(2) 使用多接口测试策略(例如，写数据->查数据->删数据)。注意到，两种方式成本都不低。前者需要搭建Mock服务、编写Mock规则，后者需要编写多接口用例、准备和清洗测试数据。
在流量回放中，由于读接口没有副作用，因此可以直接回放。对于写接口回放，则必须通过Mock方式对中间件进行隔离、避免脏数据产生。由于在录制流量的时候，我们可以同时录制所有子调用，进而利用录制的子调用自动生成Mock，因此是可以一定程度上降低Mock成本的。
3、Mock回放与非Mock回放的区别？
首先要澄清一点的是，是否Mock回放与接口是否读写没有必然联系。读接口可以非Mock回放，也可以Mock回放；写接口可以Mock回放，也可以非Mock回放(例如，写入影子表)。
Mock回放与非Mock回放的根本区别在于：Mock回放是白盒测试，而非Mock回放是黑盒测试。在非Mock回放中，用例只依赖接口的输入输出定义，不依赖接口内部代码实现；在Mock回放中，用例不仅依赖接口的输入输出定义，还依赖接口的内部实现，即接口对中间件、第三方等的调用详情。
4、Mock回放的挑战在哪里？
对于Mock回放来说，其白盒测试固有性质除了会带来测试覆盖度降低(中间件变更无法被用例覆盖，存在漏测风险)之外，其最大挑战在于回放失败率上升及回放失败的排查成本高。
用例失败概率上升：非Mock回放，接口的输出不符合预期，用例就会失败；而Mock回放中，任何一个Mock子调用失败，都会导致用例失败。尤其当子调用数量多、链路易变的情况下，Mock回放用例失败概率会很高。
用例排错门槛高：子调用失败的排错，需要懂被测接口的内部代码实现才能做。
5、如何降低流量回放的排错成本？
① 区分Mock回放与非Mock回放。Mock回放需要懂代码实现，如果让测试去定位Mock回放失败的问题，将是一件成本极高的事情(需要花相当长时间去学习代码)。如果让开发去定位，则成本要低得多。
② 制定灵活的回放结果对比策略。抛开Mock而言，流量回放失败一般都是由对比失败造成。而对比失败的概率或排错成本，实际上取决于对比策略。对比策略本质上是断言策略，是测试策略。同样的，这是接口测试的共性问题。试想，我们在编写接口用例时，如果一个接口的响应体里有100个参数，我们会添加100条断言规则(可能还不够)对每个参数都进行校验吗？
要知道，断言规则越多，用例失败概率就越高。如果我们对所有接口都采用全量数据对比策略，流量回放的失败率必然高、稳定性必然弱。因此，我们还是要制定合理的对比策略，根据场景的不同，灵活采用关键字段对比、结构对比等策略，而不必局限于全量对比。
③ 注意测试环境的影响。流量回放本质上是对比测试，而对比的数据是依赖于测试环境的。我们对比的数据应该来自同一套数据源或使用Mock，否则是没有办法进行对比的(因为没有可比性)。
6、流量录制回放的机会在哪里？
① 流量筛选：流量录制回放提供了一种非常低成本的用例生成方法。然而，我们需要的不是一个随机的用例，而是能够增加测试覆盖的用例。如何从线上流量中去粗取精，挑选能够增加测试覆盖的流量进行回放，是流量筛选需要解决的关键问题。
② 精准回放：精准测试，即根据代码变更挑选受影响的回归测试用例进行执行，在流量回放领域同样是适用的。如何根据代码变更去挑选可能受影响的流量进行回放，是精准回放需要解决的问题。
③ 精准断言：流量回放的默认全局对比断言策略，是造成回放容易失败的重要因素之一。要降低回放失败率，需要提升断言的精准度。如何从录制的海量流量中自动挖掘和推荐适用于每个接口的断言规则，是精准断言需要解决的问题。
④ Fuzz回放：符合语法和模型约束的场景是正常测试场景，能验证接口的正常功能。不符合语法或模型约束的场景是异常测试场景，能验证接口的可靠性和异常处理能力。利用Fuzz技术，对流量数据的语法或模型进行变异，可以构造结构丰富的测试输入，从而实现异常场景的测试覆盖。