你们有没有遇到过一个项目，曾易手多人，开发和QA换了一茬又一茬，短时间内无法全面熟悉内部逻辑，没有完善的自动化回归用例集，每次上线前都感觉心好慌？
我所在的易盾部门，致力于提供业内领先的安全服务解决方案，随着近几年的高速发展，安全产品线越来越丰富，目前已多达20余个。在这过程中，有些业务线出现重组优化，人员变更的情况。我现在手里就有这么一个API项目，在迭代过程中，开发换了两三个，QA换了两三个，历史的接口用例在几经易手后七零八落，没有完整的接口自动化回归用例。然而，一个API服务没有完善的自动化回归用例，这是任何一个有担当有作为的QA同学所不能忍受的。我还记得那位靠谱的开发小哥哥过来问我：“我优化了底层服务的一些逻辑，你们有没有自动化回归用例集跑一遍”，而我尴尬地说没有的时候，他失望的表情深深地刺痛了我的心。
此处插个题外话，这个项目最初的1.0版其实就是我测的，后来转手给其他QA同学，最后兜兜转转，又回到了我手里，真是天道好轮回，苍天绕过谁。
然而要从头梳理完整的接口回归用例集可不是一件容易的事情，尤其是在短时间内无法快速熟悉内部逻辑，用例设计遗漏风险是较高的。
另外，这个项目有个特殊之处，它会调用好几个外部供应商服务，而这些供应商服务是收费的，平常测试时数据量不大，费用不高，项目组也能接受，而如果频繁地进行回归，日积月累，势必是一笔不小的开支。所以如果要进行自动化回归，必须把这些供应商服务mock掉。
mock这些供应商服务可是一个不小的工作量！看了下这些供应商服务，除了常见的http服务，还有一个是web service服务（使用soap协议），两者的mock解决方案是不通用的，我得搭两套mock服务。
还要设计各种各样的mock用例，覆盖不同供应商接口的返回值，后期维护这些mock用例也是个巨大的工程。
综上所述，我大致罗列了下完善自动化回归用例目前的难点和痛点：
1.需要自己搭建mock供应商接口的服务，低效耗时；
2.设计较多mock供应商接口的用例，后期维护成本高；
3.部分固定的自动化回归用例执行过一次之后会失效，需要做一些数据清理工作；
4.短期内难以全面熟悉内部逻辑，用例设计遗漏风险较高。
这时，引流平台向我们抛出了橄榄枝。他们说：
1.我们有完善的mock机制，你说的上述mock痛点我们都能解决！
2.线上数据多种多样，数据清理工作不用做了！
3.录制线上流量在测试环境回放，可以真实模拟线上用户行为，核心业务逻辑覆盖不遗漏！
4.快速接入平台，支持录制实时回放，快速验证录制用例的有效性，快速建立回归用例！降本提效，唯快不破！
为了证（偷）明（懒）他（不）们（用）没（写）有（接）在（口）吹（用）牛（例），我决定试一试这个引流平台。
引流测试的主要原理就是将线上流量录制下来在测试环境中回放，并将线上流量的结果与测试环境回放的结果进行比对，如果两者一致，说明测试环境功能和线上是一致的，如果不一致，则需要排查测试环境是否有bug，或者是因为功能改动造成的。回放一致的流量可以沉淀成回归用例集，这部分用例可以反复使用进行回归，节省录制新流量的时间。
原理没毛病，接下来就是实践了。引流平台的小伙伴热心又负责，让我感受到了VIP客户的待遇。
第一步：环境对接，耗时：20分钟
环境对接确实很快，只需要在引流平台上执行一些基础步骤，把他们提供的脚本放在被测应用的机器上，执行脚本成功后即可。
第二步：Mock配置，耗时：若干天
Mock是引流平台的一大特性，它会将线上流量每一步的调用链路都录制下来，记录下每个中间步骤的入参和返回结果，从而实现mock。平台提供了通用的中间件mock配置，比如Redis，kafka，mybaits等，但是对于代码中一些时间戳、随机数，本地缓存等数据，还有参数校验、调用供应商等方法，需要提供具体的类名和方法名才能实现精准mock。通过这种手段，可以解决测试环境和线上环境业务数据不一致的情况。如图所示：
这一步往往需要阅读代码找出那些需要mock的类和方法，而且为了最大限度覆盖代码业务逻辑，一般是需要找到最底层的调用方法。否则把上层方法mock了，那底层的代码逻辑就覆盖不了了。但有时候会出现引流平台录制不到底层的mock方法，只能选择mock往上一层的方法。所以这一步mock配置很难一次性就能配置正确的，需要阅读代码找到mock的具体类和方法，会耗费较多时间。在一次次回放失败中不断调式定位，反复分析代码，终于补全了所有的mock方法：
第三步：录制，耗时：20-30分钟
录制，即引流操作，是将用户实际操作的流量或者测试人员手工测试的流量记录下来，录制下来的数据为作为回放的数据源。
平台支持全量接口的录制，也可以选择录制某几个接口。录制时长和录制总条数都可以手动设置，哪个条件先满足就停止录制，我一般设定的录制时长是20-30分钟。另外还要设置采样率，例如采样率10%，就是录制10%的流量。这里遇到的问题就是我们的项目需要设置mock的方法较多，导致引流平台在录制采样时链路跟踪记录过多出现线程安全问题，会丢弃某些数据，导致回放失败，所以每次录制的采样率不能设的过高，目前采样率需要控制在10%以内。而有些项目没有这方面的问题，采样率100%也是ok的。
第四步：回放，耗时：5分钟
将刚才录制下的流量，在被测应用的测试环境中进行回放，看相同的请求入口，输入相同的请求参数，在Mock了基准数据后，请求的返回是否与录制的时候一样，以此来实现功能验证。被测应用是个API服务，因此回放速度是很快的。我还尝试了下录制并实时回放功能，一边录制一边回放，录制结束的同时回放也结束了，十分高效。
第五步：查看测试结果并分析
回放结束之后，就能立马看到成功和失败的用例。如果全部成功，则说明测试环境功能正常，我们主要关注失败的用例，分析失败的原因，是bug引入or需求变动导致的。平台跟踪并记录了请求过程中调用链路上的每个环节，并提供线上环境与测试环境的比对，可以点击进入详情页查看：
第六步：沉淀回归用例集
引流平台会将回放成功的用例进行汇总统计，放进【用例统计】中，然后可以在这些用例中，自定义选取用例生成用例集合，用这个用例集合回放实现回归测试。同时提供用例去重功能，即相同接口且入参一样的用例，只保留最新的。目前已沉淀了一批用例，后续日常回归可以将这批用例全量进行回放，省去线上环境录制新流量的时间，整个流程只要几分钟就搞定了。
当然随着代码的变更迭代，用例统计中录制的历史数据在后续回放中可能会失败，可以将这些回放失败的用例一键删除，这个功能我觉得十分好用。
第七步：引流测试效果
衡量引流测试效果的指标当然是代码行覆盖率了，引流平台的未来规划是将覆盖率集成进来，通过覆盖率做自动推荐用例，但该功能还在孵化中，我只能自己手动统计了。最后统计出来代码行覆盖率达 63% ，分析了下，基本覆盖了线上用户的主要使用路径，没有覆盖的代码行主要是以下几点：
1.mock了一些参数校验方法
2.有些mock方法较上层，少了部分覆盖
3.异常逻辑覆盖，比如针对供应商返回错误码的处理，线上较少出现这种情况，没有录制到相关流量
理论上来说，随着录制量越来越多，以及不同时间段错开录制，数据会更加多样化，代码行覆盖率也会越来越高。
实践小结：
在实践引流测试之前，引流平台负责人曾和我一起展望了下预期收益率，如今回顾了下，它确实做到了当初的一些承诺：
1.弥补回归用例缺失：通过录制回放快速回归，保障项目质量
2.节约时间成本：自带mock机制，无需额外实现mock供应商的微服务
3.节约用例维护成本：回放成功的用例不断沉淀形成回归用例集，并且提供去重功能，用例维护成本低
4.降低用例遗漏风险：真实模拟线上使用情况，无需全面熟悉内部逻辑，依然可以实现主干业务逻辑的精准覆盖
当下一次开发小哥哥让我回归一下API服务时，我可以从容不迫地打开引流平台，创建回归用例集，启动录制回放任务，然后去泡一杯菊花枸杞茶 ，悠哉地喝上一口，点击查看测试报告，然后向开发小哥哥报告：回归测试通过，可以上线啦~
当然还有一些问题：
没有完美的测试工具，此次引流测试实践也遗留了一些问题。
1.代码行覆盖率的提升
根据我们测试团队的实践经验，一个API服务的代码行覆盖率是可以达到 70% 以上的，目前我们核心业务自动化回归测试的代码行覆盖率均在70%以上。引流测试实现主干业务逻辑的精准覆盖，然而因为mock原因以及线上流量缺少异常逻辑覆盖，导致代码行覆盖率无法进一步提升，这些未覆盖的代码还是需要额外手段去覆盖补充。
2.用例稳定性考量
目前是通过引流测试建立回归用例集，所以线上流量结果和测试环境回放结果是一致的（若不一致就是引流平台的bug了），后续随着业务迭代变更，若出现两者结果不一致的情况，是否能够快速定位分析问题所在，修复回归自动化用例，缺少实际经验，回归用例稳定性方面有待考量。
还有展望：
1.开展更多引流测试实践
这次接入引流平台的项目是一个整体架构较为简单、核心功能只有一个模块应用的小型API项目，本身也比较适合引流测试。后续希望开展更多项目的引流测试实践，在现有测试手段的基础上，通过引流测试真实模拟用户使用情况，有效确保核心业务逻辑精准覆盖，提升质量信心。
2.将引流测试融入日常研发流程
引流测试可以进行历史功能回归、重构功能的测试与验收，相比其他测试手段，引流测试是一种低成本高覆盖的测试方案，无需测试分析、人工设计用例，测试准备和测试执行的工作大大减少，非常适合成为开发自测的手段。如何让引流测试融入日常研发流程，也是需要不断摸索的。在后续的实践过程中，要让引流测试真真切切带来降本提效，为开发自测赋能，为QA解决痛点，为项目提升效率，为质量保驾护航。（作者：叶子）