流量录制与回放升级版：AI如何过滤噪音流量，生成高纯度测试集

图片

    某接口录制了一天的线上流量，导出来一看，几十万条记录。等真正要拿去回放测试时才发现，里面至少三成是健康检查心跳包、客户端重试和爬虫请求，跟业务逻辑没什么关系；真正覆盖了多个业务分支、值得拿去回放的请求，可能也就几千条，淹没在这几十万条"噪音"里，工程师光是人工筛一遍就要花掉大半天。这是流量录制回放这项经典测试技术，一直没绕开的老问题：录得多，不等于测得好。

一、流量录制回放好用，但"量大"反而成了负担

流量录制回放的价值很清楚：不用手写用例，直接拿线上真实流量当测试输入，覆盖率天然就高，还能验证中间过程而不只是最终结果。阿里的Doom平台、字节跳动自研的ByteCopy/ByteDiff、Twitter的Diffy，走的都是这条路。字节跳动自己也提到过类似的思路转变：早期引流回放系统只是被动按需采集，后来发现并不是每次测试都需要实时流量，于是逐步把系统改造成主动错峰、定时录制并维护一个流量池，用的时候直接取用——这其实已经是在为"减少冗余采集"做架构层面的准备，只是当时主要靠调度策略，还没用上语义层面的判断。

但痛点也很实在：真实流量里混杂着大量与业务逻辑无关的噪音——心跳检测、客户端重试、爬虫请求、近乎重复的请求。这些不仅占着存储和回放资源，还会拖慢diff比对，甚至制造误报：重试流量天然会触发幂等性相关的差异，很容易被错误地标成"发现了bug"。像GoReplay这类成熟工具已经支持按路径、按header做规则过滤，但规则得靠人工持续维护，业务一变、新增一个监控探针路径，规则就要跟着补，治标不治本。

二、AI能补上的，是"语义理解"而不只是"规则匹配"

这里AI能帮上忙的地方，主要是三类。一是语义聚类去重：把请求向量化后按相似度聚类，每一簇只保留有代表性的样本，而不是像传统规则那样只能做字符串层面的完全匹配去重，容易漏掉"参数值不同但业务路径相同"的大量冗余请求。二是噪音识别：学习心跳、重试、爬虫这类流量的语义特征，而不是死守一份路径白名单，新增一个探针接口也能被认出来，不用每次都靠人补规则。三是业务场景标注：让模型读一批流量，按业务意图打标签，比如"下单流程"、"退款流程"、"权限校验失败"，把一堆HTTP日志变成按场景分类的语义化测试集——这一步传统规则引擎做不到，因为它需要理解参数组合背后的业务含义，不只是匹配字符串。打上标签之后，这批流量也更容易和测试管理平台里已有的用例库对应起来，方便核对哪些业务场景已经被流量覆盖、哪些还得靠人工补。

三、"高纯度"的隐患：被过滤掉的，可能恰恰是最该测的那批

但"纯度"这个词本身值得警惕。如果判断标准是"跟大多数流量相似就保留，不像就当噪音过滤"，那些小众但合法的边缘请求——某种罕见的优惠组合、某个低频但真实存在的并发时序——反而最容易被当成噪音一并清掉。这跟系列前面讨论过的"AI生成用例同质化"是同一个问题的另一种表现：只不过这次不是生成阶段趋同，而是筛选阶段把多样性筛没了。

更具体一点，重试流量本身有时就暴露着上游超时或幂等性设计的缺陷，如果简单把"重试"归为噪音直接过滤，反而可能把最该测的那类并发问题一起处理掉了——这跟之前提到的、藏在并发场景里才会暴露的闭包陷阱bug是同一种风险。

四、落地建议：把AI过滤当成减负工具，而不是全权代理

几个相对现实的做法：先用规则引擎过滤掉确定无价值的噪音（已知爬虫UA、固定的健康检查路径），再用AI对剩下的流量做语义聚类和场景标注——纯粹靠大模型逐条处理全量原始流量，成本和延迟都扛不住，业内在大模型数据清洗上的经验也印证了这一点，混合架构（传统规则先粗筛、模型只处理筛剩下的复杂部分）往往能把处理成本压低一大截，这个思路同样适用于流量过滤。给低频、异常的流量单独开一条通道，不参与按相似度折叠去重的逻辑，避免边缘场景被悄悄吞掉。定期把AI筛出来的"高纯度测试集"和原始全量流量的业务场景覆盖率做对比审计，看有没有系统性漏掉某一类场景。每一条被标记为噪音丢弃的流量也要留痕，方便后续排查复盘。

结语

流量录制回放的核心价值，本来就是用真实世界的多样性，补人工编写用例时想象力不够的短板。AI在这里能帮的忙，是把海量原始流量整理得更可读、更高效，但"高纯度"不该等于"高同质化"。衡量一份测试集好不好，标准从来不是它有多干净，而是那些最容易被忽略、却最该被测到的边缘场景，有没有被留下来。