月光宝盒助力全自动高覆盖回归测试

月光宝盒诞生之始

一直以来我们研发面临的一个巨大挑战就是，业务场景越来越复杂，任何一个轻微改动，可能都需要成百上千用例回归；需求迭代越来越快，技术重构也是时常有，全量回归测试频率越来越高；技术体系又是大规模服务化，上下游依赖特别多，准备测试数据成本非常大。依靠人工编写测试用例、准备测试数据，很容易有遗漏，效率也特别低。更严重的是，经过中台建设、组件化、国际化以及未来PaaS之后，我们的业务将是遍地开花，部署环境如同雨后春笋，研发面临的回归测试压力将是不可承受之重。因此，我们自然而然也想到了通过录制生产环境流量，到测试环境进行回放对比，从而实现全自动化、高覆盖率回归测试。

其实，流量录制与回放并不是一个新话题，特别是在回归测试场景应用由来已久。京东内部也有多个团队进行过相关实践。然而，相关 工具 一般同业务紧密耦合，或者跟特定业务深度绑定，功能比较薄弱，通用性、扩展性都不太好，无法快速推广复用。业界也有一些相关开源产品，但是调研下来，总体感觉还不能完全满足我们场景：要么是基于TCP/HTTP网络协议层，缺乏上层业务可定制化能力；要么非 Java 技术栈，二次扩展开发或运营维护成本较高；要么只开源了底层核心能力，缺乏具体应用场景配套功能，而且还需集成京东中间件，二次开发工作量比较大。

因此，我们决定开发一套全新的流量录制与回放平台——月光宝盒应运而生。

让时光回溯

月光宝盒，简称 JCASE (java testcase, jd testcase, jewelry case），典故源自大家再熟悉不过的电影《大话西游》，寓意时光倒流。其核心思想是将生产环境流量录制下来，然后在测试环境进行回放，最后对比两份结果是否一致，来判定被测代码逻辑是否有问题，基本流程如下图1：

图1

生产流量真实可信，随机性好，源源不断，因此借助流量充当测试用例、测试数据，再也不用为准备测试数据发愁了，而且能够有效保证覆盖率，可极大降低测试成本，同时高效推进项目进程。

月光宝盒最早是在18年8月左右开始开发的，当时技术中台正在大规模推进组件化，下文我们也可以看到诞生于组件化的她，天生就具有组件化典型特性，例如灵活、可扩展、可组装、可裁剪等，能够适应不同场景需求。因此，根据前期对已有工具或产品的调研分析，我们在设计之初，就定下明确目标，月光宝盒应具备如下几个产品特性：

• 通用友好，简单易用

• 功能丰富，开箱即用

• 开放性好，扩展性强

• 代码整洁，文档完善

• 无侵入，低开销

经过一年多的内部运行，不断建设完善，月光宝盒目前已广泛应用于零售技术中台主交易、供应链Y业务、7 Fresh以及数字科技等诸多业务线系统中。特别是在2019年组件化、国际化过程中，月光宝盒经过了有效检验，对新老系统平滑切换的质量保证与效能提升发挥了巨大作用，已成为我们日常需求迭代开发与系统重构升级必不可少的稳定性护航利器。

除了回归测试这一典型用途之外，我们也可以将流量录制回放应用于压力测试、离线调试、上线预热等诸多场景，这几方面功能月光宝盒也初具雏形，其中压力测试已同京东内部分布式压测平台 forcebot 做了紧密集成，可利用线上流量进行高保真的压力测试。本文我们将先重点阐述回归测试方面的具体运用。

跨越时空的密码

前文我们对月光宝盒从产品设计角度，包括核心思想和主体功能做了简单介绍，本节我们将结合设计原理，从使用角度，分别对在线回放和离线回放两个场景进行重点阐述。

1

在线回放

为了提供丰富功能，满足多种使用场景，同时又要兼具强大的扩展性，月光宝盒的完整体系结构还是比较复杂的。因此，为了能让读者对其设计原理有个基本了解，以便能够快速上手使用，今天我们首先从其核心架构谈起，并结合最简单的使用场景——在线回放展开介绍。

如下图2所示，月光宝盒核心功能由三大核心模块组成：录制代理(Record-Agent)、回放服务(Replay-Service)、回放代理(Replay-Agent)，三者刚好形成一个“正三角”结构。通过此拓扑结构，可实现一个最简单的在线回放场景，即直接将流量进行回放调用对比，中间没有对流量进行持久化存储。此时，回放服务一方面相当于承担了代理转发角色，将录制流量转发给被测应用，同时对录制回放结果进行对比，无需额外的流量存储，部署简单，成本低廉，特别适合于只读接口的录制回放。下面，我们将对这三大模块分别进行一一介绍。

图2

录制代理 Record-Agent

这是一个客户端代理模块，提供流量录制功能，需要嵌入作为回归对比参照的流量来源系统，一般是生产环境。录制时，会录制方法的调用参数、返回结果以及相关上下文信息，支持主方法（或称入口方法）调用录制以及关联子方法调用录制。如果是只读场景，可只录制主方法，性能开销更少，同时可通过在线直接回放，运维成本较低；如果是写场景，通常需要录制子方法，以便回放时进行依赖 Mock。这部分下文介绍回放代理时再展开详细介绍。

整个录制代理模块内部由录制器、过滤器、缓冲区、上报器等多个组件组成。

录制器，通过 AOP 拦截技术实现无侵入自动录制，支持 JSF、HTTP 协议以及纯本地方法调用。考虑到我们大量 JSF 服务，也实现了JSF 过滤器录制，配置比较方便。同时也支持手工编程录制，可满足特殊场景下的自由录制，此时就有一定的侵入性了。

过滤器，提供流量过滤功能，内置了采样率、接口名、方法名、JSF分组名、IP等常用过滤器实现。某个流量请求经过录制器时，会通过一系列过滤器判定是否应该被录制。

缓冲区，提供录制器的流量暂存功能，缺省由一个小型的有界队列实现。

上报器，将缓冲区内的流量上报给接收器，是一种推的模式。上报器，相对于业务主线程是异步执行的，与录制器、缓冲区组成了一个经典的生产者与消费者模型。内置提供了多种实现方式，例如常用的直接回放上报和京东JMQ上报。直接回放上报，其实就是将流量从内存缓冲区直接发送给下文马上谈到的ReplayService，中间无存储。而 JMQ 上报，就是先将流量写入JMQ，下文介绍离线回放时会重点提到。

此外，录制总开关，过滤器规则等控制属性均可通过远程配置中心动态加载，实现实时开启或关闭录制、调整采样比例等。目前，配置中心内置支持了技术中台主交易DBConfig 以及京东分布式统一配置中心 DUCC，也可进行扩展开发支持更多配置中心。

可以看到，在录制客户端内部，其流量录制过程，属纯内存操作，异步上报完成，不承担复杂工作，是一个轻量级模块，开销是非常低的。

回放服务 Replay-Service

这是一个需要独立部署的服务模块，主要提供流量回放核心功能，包括回放调用、回放与录制结果对比、对比结果存储等。

回放调用，是基于前述录制的入口方法请求参数对指定的被测服务进行调用获取回放结果。目前支持 JSF与HTTP协议，可扩展其他协议，也可根据实际情况进行自定义扩展，例如对回放调用的请求参数进行转换，解决录制与回放接口不兼容的问题。

回放对比，是将录制结果和回放结果进行比较，默认是对两个对象进行字段级别、递归深度比较。对比结果会进行实时监控统计，默认是通过京东统一监控平台 UMP 实现，可以设置报警。同时，会将对比结果进行持久化存储，通过内置的Web Viewer工具可进一步分析排查。

这里还有一个关键问题：录制与回放两端总会有一些已知差异，典型如时间差、服务器IP、随机值，还有新老接口有差异，例如新接口增加新字段等等，这些我们称之为回放对比“噪音”。只有这些消除噪音，才好发现真正的差异，不然会被噪音淹没掉，无法分析定位真正的对比失败以及背后的BUG。月光宝盒已内置了一系列常用比较规则来辅助消除对比噪音，例如忽略某字段、忽略大小写、浮点最小差值、列表先 排序 等等，同时也可以通过扩展开发进行自定义比较满足复杂场景。

注意到，回放服务整体是一个旁路应用，承担着回放调用与结果对比的重活，与线上业务系统是完全解耦的独立应用，不占用业务系统资源，有问题即使宕机了也不会影响主业务。同时，日常业务需求经常变更，回放调用与回放对比也经常要同步扩展开发或调整对比规则，作为独立应用，就可以随时快速部署上线变更，对主业务没有额外风险。总的来说，作为一套辅助工具平台，从多方面最大程度降低对生产系统的性能影响以及稳定性风险，是月光宝盒的核心设计原则之一。

回放代理 Replay-Agent

这也是一个客户端代理模块，内嵌运行于回放目标被测系统，一般即测试环境。它主要提供回放Mock功能。当业务系统有大量的依赖调用时，例如外部RPC、 Redis 、数据库等，在测试环境回放时，这些依赖底层数据源通常无法直接提供录制时的现场数据，就需要使用录制下来的子调用数据进行相应Mock，达到还原现场的目的。技术上，同录制代理类似，也主要是通过 AOP 拦截技术实现。

此外，这是一个可选模块。如果是只读接口场景，而且其内部依赖在回放环境与录制环境无差异，那么也就无需Mock，那么录制时也就无需深度录制子调用，这样录制开销更低。

2

离线回放

除了在线回放，月光宝盒也支持离线回放。所谓离线回放，是指把录制的流量先持久化存储下来，然后读取流量记录进行回放。离线回放相对于直接回放有很多优点：首先，流量存储下来可以重复利用，随时可用，这样就可以将流量引入测试环境进行回放；还可以对流量进行识别打标，关联测试用例，统计测试用例覆盖率；同时，对于含有子调用的深度录制，数据报文一般比较大，直接回放开销可能比较大等等。

图3

如上图3所示，离线回放也因此需要更多的组件和资源来配合完成，部署拓扑结构也相应变得复杂。下面详细展开介绍：

1. MQ：用于暂存录制代理端上报器上报过来的流量，当然也支持直接将流量上报到数据库，但一般不建议，数据库一般写入吞吐量都不高，通过 MQ 缓冲，更具有伸缩性。目前，上报器组件已经内置了京东自研 JMQ 实现。

2. 数据库：用于流量持久化存储，一般选择HBase 或 ES，当然小规模流量存储也可以选择 MySQL。目前，内置实现了 HBase 和 MySQL。

3. Record-Dumper：实现将流量从 MQ 转移到数据库的转储功能。可以独立部署，也可以合并到 Replay-Service，建议后者，这样可以有效降低部署和维护成本。

4. Record-Pumper：扫描读取流量数据库，然后调用ReplayService进行回放调用对比。部署方式同 Record-Dumper 组件。

5. Record-Service：提供流量查询服务，主要用于解决类似HTTP协议回放调用时，需要单独获取子调用录制数据用于 Mock。而像 JSF协议这种支持隐式参数的，就会优先通过隐式参数传递子调用录制数据，无需此组件。部署上，同样建议合并到 Replay-Service中即可。

写接口回放时，强烈建议通过离线回放完成。离线回放可以将流量引入测试环境进行回放。因为一般情况下，测试环境与生产环境网络是隔离不互通的，这样可以最大程度避免写回放时，因为配置失误或潜藏BUG等因素引起Mock失效时，导致流量误写入生产环境，引起数据污染，甚至造成严重业务事故。

综上所述，我们可以发现，月光宝盒是高度模块化的，由多个模块构成，模块由组件构成，大组件又由小组件构成，组件即扩展点，每个组件均是可扩展的，每个模块或组件提供丰富的内置功能，使用方可优先通过配置方式满足不同需求，也可进一步根据实际需求情况进行自定义扩展开发满足个性化场景。

传说尚未结束

本文主要对月光宝盒流量录制与回放平台进行了功能与原理的基本介绍，后面将做更多详细介绍，例如更多的产品功能、实践案例、设计细节等等。目前，月光宝盒已在京东技术中台内得以广泛使用，上线前先通过流量回放进行回归测试已成为很多团队的标准流程。如果大家对流量录制与回放话题、对月光宝盒原理与使用感兴趣，可与我们联系：wangxiaofeng3@jd.com，期望本文对大家有所帮助。