建设背景
测试人员回归耗时长，成本大。公司很多测试都进行手工测试，在集成测试中需要耗费一周时间进行全量测试，在各个环境(用户测试环境和预发布环境)回归测试时需要耗费三天左右。加上编写测试用例时间，理解需求时间等其他，测试人员时间紧张，无法适应两周一个迭代的敏捷交付模式，同时也无法保证各个环境充分的回归测试。
开发人员单测覆盖率低，集成环境修复耗时长。公司团队内很多外包人员，没有养成单元测试编写习惯。公司很多IT项目都有很大业务压力，大家没时间编写单元测试。这种现状导致大家在集成环境中，经常遇到各类集成问题，如自身功能主流程不同，变更接口影响到存量的业务功能等，导致团队在集成测试环境中疲于测试和修复各类集成问题，严重影响了开发进度和测试进度。
如何解决此类常见的业务痛点，行业通用解决方案是建设流量回放平台。
1.1 数据平台利用大数据智能分析、数据可视化等技术，对公司内外部经过采集、建设、管理、分析的多源异构数据进行呈现和应用，实现了数据共享、日常报表自动生成、快速和智能分析，深度挖掘数据价值，满足企业各级部门之间的数据分析应用需求。因而也具有数据量大，场景多，数据准确性要求高，查询性能要有保障等特点。
传统测试方法
1.2 基于数据平台的特点，使得我们在线下进行数据测试或者回归测试时成本比较高，难度也比较大。所以我们希望能有一种有效的手段来降低测试的成本和门槛，实现测试的标准化。一直以来我们都是通过编写自动化测试来实现的。但是传统的自动化测试其实是有很多弊端的，比如成本高，覆盖场景有限，标准化难度高等。
1.3 传统自动化的弊端1.3.1 成本高：
- 人工编写、维护自动化用例成本高
- 较低的测开比无法跟上迭代的速度
1.3.2 覆盖场景有限：
- 线下构造测试场景难度大
- 场景覆盖度有限
1.3.3 标准化难度高：
- 强依赖 QA 个人经验和能力
- 开发独立排查自动化问题难度高，推动开发自测效果差
因此我们希望利用线上的流量来搭建一个流量回放的平台，与自动化测试结合，来实现一个符合数据平台特点的自动化测试体系。
2 流量回放平台介绍，流量回放原理
流量回放的实现原理即是使用线上入口录制用户操作的真实流量，到预发环境进行回放，对比生产和预发环境录入接口的子调用、响应差异去定位代码问题，接入对象范围是只读、读写、只写接口，优点是业务代码零侵入，自动流量 diff，真实链路调用，数据可查，问题定位精准，发现问题的可能性提高，缺点是面向范围有一定局限性，操作不慎可能导致回放的接口中存在写操作的子调用产生脏数据，影响业务。
2.1 流量回放平台调研
确定之后我们便立刻展开了调研，研究对比了公司的流量回放平台，阿里的 Doom 以及 Twitty 的 Diffy，差异如下图。
2.2 数据平台业务特点
- 因为数平报表的查询特点， 导致代码中对外查询链路少，对内的维度条件业务组合多，基于这样的特点导致在使用 Pandora 平台录制线上流量时，流量录制不全，大多数场景无法完全覆盖。
- 复杂的数据平台一般都依赖大量属性配置管理、定时同步任务等，因此预发环境和生产环境配置库需要隔离，保护数据不被污染。而流量回放又依赖配置库和数据库相同，使用场景高度依赖配置数据， 导致回放落地难度大。
- 数据平台的流量回放，验证结果时往往需要对数据进行校验， 请求会对生产数据库造成一定查询压力，可能会影响生产环境稳定性。需要控制好回放速度和控制、监控和降级保护。
- 部分数据是实时的，回放结果需要计算波动率。
基于以上特点导致数据平台无法接入公司的 平台，我们也在第一时间联系公司平台负责人进行沟通和提出改进需求方案。
但问题的迫切使得我们决定先小成本的进行一些工作，一方面尽快缓解我们的痛点，一方面也要方便后期接入公司平台，减少资源浪费。以此为目的，我们在一期使用脚本采集流量， 并借助开源工具 Diffy 快速实验了一套简易的流量回放系统。同时给平台提出适应性接入需求。在二期时，将脚本采集的流量上传至平台，接入平台进行流量回放。
这样的好处是：
- 流量自主可控，可根据需要定点扩充流量，无需担心流量稀疏、录制对线上环境的影响、接口覆盖不全等问题。
- 使用日志或埋点的方式采集流量，为流量采集提供了一种流量采集的新思路
- 开源工具只有部署和熟悉的资源投入，后期接入平台后可回收资源，没有浪费资源重复造轮子
基于以上背景，进行了数据平台的流量回放实现方案。
2.3 核心原理
整体思路依然是沿着线上获取流量，分别在不同代码环境进行回放，最后对接口返回结果进行比对，以达到检测被测代码准确性的目的。这里我们将生产的流量根据时间、接口白名单和操作人等字段进行过滤，并按照窗口进行流量的去重和筛选，最后沉淀为一个稳定的流量池。任务触发后会并发的按照指定速率向预发和生产双发回放，获取接口的返回结果，经过一系列降噪操作后，根据字段对比结果统计出整体的成功率，并产出报告。下面我会从流量采集、环境策略、执行调度、比对结果四个方面来介绍整个方案。
~ 流量回放交互构架图～
2.3.1 流量采集
通过公司的流量录制方式， 接口覆盖提升难度较大， 不太适合数平对外链路少，条件组合多的特点，因此我们想通过埋点筛选的方式进行流量采集。这样的好处是完美避免了流量录制过程中流量分布不均，降低对线上服务的性能影响，同时接口的覆盖又非常的完整。实现了自主可控，定点获取流量。
在流量采集中，我们会分批次的去生产系统上根据配置的日期和数量不断地捞取流量，对每一个批次流量根据入参和请求路径进行接口去重，并根据梳理好的接口白名单、流量操作人、接口关键字、请求类型等来过滤数据，然后需要对流量中的脏数据进行筛选、对参数中的特殊字符和多余字段进行修正。最后将清洗好的干净数据保存到本地流量池中，等待任务使用。
在后期，处理后的流量会通过接口上传至流量回放回放 Pandora 平台，通过我司的平台化工具更便捷高效的管理流量和执行。
上传后即可在流量回放平台查看流量，这里也可以通过 excel 的方式手动上传，但是每批次流量数量受限。
2.3.2 环境策略
环境采用了预发和生产两套环境对比。通过配置将预发环境的数据来源指向了生产服务。并且定时同步生产的配置库到预发环境，来解决数据和配置的 Gap。
2.3.3 执行调度
调度有两种方式， 一种是配置定时触发，一种是手动调用接口触发。任务触发后，会获取流量池中的流量，并对流量的关键字和执行数据量级再次判断是否可执行。确认执行后，将流量放入线程池中开始回放。这里采用了定长线程池和速率控制器来实现高并发和灵活的请求速率配置。
在任务执行后，也可以根据实际执行情况随时修改配置来停止任务或者调整任务的发送速率，控制对线上环境的影响。
2.3.4 比对结果
拿到生产和预发的返回结果之后就是对比两端结果，发现不一致的字段和返回，介于数平的特点，噪音点会非常的多，因此引入了 AAdiff 的方式，来达到自动降噪的功能。如何降噪：
a. AAdiff ：在对比之前， 连续调用两次生产环境，获取结果后对比， 将不一致的字段剔除。即可去除不稳定或者有波动的字段
b. 指定字段忽略：跟对一些配置字段或者无意义字段进行手动配置忽略，降低噪点。
结果差异对比汇总后， 会根据字段进行分组汇总，对与 AAdiff 不通过的字段会直接置灰。点击字段即可在右侧查看字段下差异的数据。
通过点击差异详情，可进一步看到请求的 path、请求体、生产和预发的返回值等信息，帮助排查定位问题。
同时在结果报表中可以观测到流量数、回放成功率等信息。
3 业务实践
这里以智能运营系统为例，对比流量回放接入前后的效能成本差异。
通过流量回放的方式，不仅快速提升了自动化的接口覆盖，降低了迭代人力投入，更是增强了回归的可靠性。这一点通过迭代质量变化趋势也能很好的反应。
平台数据：
流量回放工具在 513 迭代初步使用， 但覆盖率和稳定性较差， 514 迭代完善，正式投入使用。
在 514 迭代工具正式投入使用后，发现遗漏 bug 比例达 25%，515 迭代质量有明显提升， 连续两个迭代线上无缺陷逃逸发生。平台质量和稳定性明显提升。
目前智能运营流量回放投入使用至今，已持续支持多个迭代的日常回归测试以及日常压测工作，读接口覆盖率达 86%，回放通过率稳定在 98%，发现回归漏测比率达 25%，大大提高了系统的稳定性和线上质量。
4 规划与展望
智能运营系统流量回放已进入维护阶段，在日常迭代中帮助测试实现冒烟、回归、压测、缓存验证等多种任务。后续将通过精准接口流量获取的方式，将少部分稀疏接口纳入覆盖。并将流量上传至流量回放平台。借助流量回放平台的能力，更加稳定、方便的执行计划和排查问题。
基于数据平台各系统以读接口为主的特点，非常适合流量回放的回归形式，后续会将各个系统按优先级陆续接入我司流量回放平台，并通过流量埋点的方式快速提升接口覆盖。
在介绍我们建设流量回放平台前，先介绍一下业务层流量录制回放的流程。
首先接入流量回放功能时，需要将agent下发到目标服务中，通过字节码增强对目标方法进行增强。录制时拦截对应的方法签名、入参、返回进行采集上报。回放时将录制的流量回放到指定的环境，通过流量返回的diff和断言比较接口业务代码逻辑是否存在问题。流量录制回放的流程图如下：
平台建设目标
流量回放算是比较先进成熟的自动化测试解决方案之一，它在集成测试和质量左移场景中可以解决很多用户痛点。
我们在进行用户访谈，了解了用户的业务活动中遇到了痛点后，结合自身的建设规划，确定了公司流量回放建设的产品定位：通过流量录制回放进行接口业务代码的测试和开发调试。对于测试人员而言，我们希望可以提供接口业务代码快速回归的能力，提升测试的回归效率和给回归的覆盖率。对于开发人员而言，我们希望提供接口业务代码的自测能力，减少集成过程出现的各类问题。
建设路线
第一阶段我们的建设目标是建设一个基础的流量录制回放工具。
在录制时，可以基于方法层录制线上接口的流量，包含入参、出参、异常抛出。用户可以人工线下分析线上的异常流量。在回放时，通过相同入参，比较线上环境和测试环境接口的出参，判断测试环境的接口代码逻辑是否异常。
第二阶段我们基于基础能力构建用户场景，满足用户场景痛点。
基于sandbox-repteater，我们搭建了流量录制、回放的基础能力，但是在没有构建场景化的解决方案前，产品价值还是很低的。
首先，用户发现录制线上的流量过程，会录制很多其他杂乱的流量，自己还需手动筛选所需流量。如我们在线上录制业务平台的某个功能模块，想要形成场景用例时，肯定伴随这其他的用户操作使用该平台，导致录制的流量混杂了其他业务场景的流量。基于此诉求，我们丰富了流量过滤策略。我们增加了基于流量体中的关键属性进行流量筛选的功能,用户可以通过流量体的中的header或body中的key值过滤流量。。比如用户在进行场景构建或者用户行文分析时，仅想录制某类用户的流量。我们可以配置IP=xx.xx.xxx.xx的流量，这样在录制时仅录制该IP产生的流量。同时我们增加了http入口流量过滤的功能，用户配置好http接口的URI时可仅录制该http的入口流量。比如我们针对新建功能想录制流量沉淀用例时，我们可以配置新建接口的URI，此时录制时仅录制该接口产生的流量，自动过滤其他业务接口操作流量。
第二，用户想要快速准确的定位问题。sandbox原生的接口是进行流量体所有属性的全局断言，但是实际的业务中有很多噪点信息导致全局断言不可行。比如一个流量体中response有很多随机数、ID、时间戳等业务随机信息，那么在出参对比时，这些属性肯定不同，导致系统误判流量对比有问题。基于这些复杂的业务场景，我们有两种解决方案，第一种是丰富降噪策略，消除噪点。用户在降噪策略中可通过正则表达式配置哪些属性为噪点，同时也可以在回放详情的流量体中手动标记哪些属于噪点属性，这样在对比过程可以忽略噪点的对比，专注于关键属性的对比。但是如果有些业务本身特性有很多噪点，会导致用户需要配置较多的降噪策略。第二种是配置断言策略，在流量对比时仅对比关键属性。比如在接口快速回归时，我们的测试就仅通过接口的code码和message进行断言。当接口下流量返回的code码为200，或者Message返回的是成功时，则认为接口没有问题。有些类似于接口测试的断言配置，只是相对比接口测试，无需构造脚本参数，可自动回放断言。
第三，用户想要屏蔽外部依赖，减少外部依赖对接口验证的影响。流量回放本身提供了丰富的方法增强和MOCK插件。比如redis插件，数据库插件等，用户启动后自动MOCK接口方法redis、数据库调用，快速验证代码本身业务逻辑。同时针对于业务本身的复杂性，可能有一些定制化的依赖，比如某些接口就是需要调用外部接口方法，这时我们仅需在MOCK策略中手动配置哪些方法的子调用需要MOCK，在回放时这些方法的子调用就不会真实执行，而是通过匹配request的入参，MOCK返回原子调用的出参。有些业务的随机数也可以进行MOCK,如在某些方法调用了雪花算法，我们可以MOCK雪花算法，返回录制时response的ID值，避免对比时出现ID对比失败导致流量对比失败的问题。
第四，用户想要构建测试场景，方便回归测试。测试人员在构造场景时需要优雅的筛选工具，方便快速筛选所需场景流量。比如筛选时间在一周内，变更服务的流量，这样既可以保证流量实时性，也可以快速测试变更服务。我们建设了流量编排功能，提供方法的筛选聚合组件，用户在流量池中可快速筛选所需流量，并进行聚合进行场景构建，方便用例的沉淀。
推广的思考
在推广任何产品时，用户场景、接口人、用户期望匹配度是三个最重要的要素，决定了产品推广的成功与否。
为什么要明确用户场景。用户当前的使用场景决定着用户对产品的接受度。比如用户处于落后的石器时代，给予他热武器，还不如给予冷兵器更能帮助到他们，超出用户认知的工具虽然便捷，但是也会因为使用不当导致还不如当前工具使用的效果。我们当时想推广给测试团队，但是发现推广效果差。
当前测试团队绝大部分都是功能测试，每次人工回归的标准是整个场景链路没有问题。他们也没有质量左移概念，没有想法去做质量左移工作，如单元测试、接口快速回归。也没有任何的测试策略，不知道哪些场景需要重点测试，哪些场景需要快速回归验证，优雅的分分配人力。
流量回放本身是单接口测试，无法覆盖全链路场景。流量回放通过接口测试可以做到接口约业务代码的快速验证，测试的质量左移(将接口代码回归无问题作为测试的准入条件)。但是当用户的使用场景是全链路测试，且没有质量左移，测试策略时，推广成本极大，既要引导用户改变测试策略，做好质量左移工作，也要引导用户接受新型的测试工具。这种推广方式对于长尾用户可以花时间逐步攻克，但是推广初期需要产品立刻产生价值，这类场景的用户明显不适合初期产品的推广对象。
一个具有话语权的接口人能够给推广带来巨大的便捷。我在做敏捷工具、devops工具、灰度发布工具、效能平台、流量回放项目的推广过程发现，内部产品的推广，最好的落地方式一定是至上而下推广。内部效能提升产品的很多都是有一定的接入成本，且价值不是立竿见影，而是使用一段时间才能感受巨大的效能提升。比如我们推广流量回放，虽然我们通过功能开发降低了很多接入成本，但是agent下发、策略配置、参数配置还是需要一定的工作量。如果不是领导层要求接入，可能大部分开发测试人员都会已业务忙、使用体验有瑕疵，推迟或者拒绝接入。
要明确用户的期望，了解产品和用户期望的匹配度，这样会减少很大的沟通成本。对于流量回放，如果用户的期望是完全替代手工测试，我会给介绍我们能解决的场景问题和带来价值，如果用户觉得不改变他的期望，建议还是把这个用户作为长尾用户，换一个用户快速推广。只有产品的功能和用户的期望匹配，用户才觉得我们产品能带来价值，才能作为金种子用户帮助我们打磨产品，否则双方可能会基于场景不匹配有很多的沟通，平台方做了再多的努力，没有达到预期，业务方也会认为产品的成熟度不够，这样的用户推广成本较大，但是收益很低。
后续的建设
一、接口的可视化编排
用户希望通过流量回放进行全链路测试和压测，减少自动化脚本编写维护成本。比如用户先测试新建订单，后续查询该订单后删除该订单复合场景是否有问题。流量回放为单接口测试，只能测试新建订单，查询订单、删除订单三个接口的代码逻辑是否有问题，但是不能测试这个场景是否有问题，比如无法判断新建的订单是否真实入库。
基于全链路场景，需要建设接口可视化编排工具。借助接口可视化编排工具编排接口好接口调用顺序，流量回放为接口提供相应入参，和出参对比，减少用户构造参数成本。后续深入建设，可以通过录制流量调用链路(比如拿到skywalking的调用traceID)，自动化生成接口的调用顺序，减少用户编排成本。
二、精准测试
代码变更后自动推荐匹配对应接口的流量回放调用链路，回放该链路下流量，提高测试效率和测试覆盖率，达到精准测试的诉求。根据线上流量的调用链路，真实评估代码链路热度、方法热度、调用热度等，建立变更风险模型，评估变更风险。
