苏宁MOCK测试桩服务建设实践

来源：IT刊

2018 年苏宁易购提出了智慧零售大开发战略，快速的发展速度对苏宁的 IT 技术提出了更高的要求，其中一个重要的环节就是加快软件版本的上线步伐，伴随着软件的上线必然存在巨大的测试压力。

前言

2018 年苏宁易购提出了智慧零售大开发战略，今年将新开 5000 家门店，到 2020 年，线下门店总数达 2 万家。半年来，以急速推进的大开发战略高超迭起，店面实现从城市到县镇市场全面覆盖，使得消费者在任何时间、任何地点、任何服务的需求都可以得到满足。

这样的发展速度对苏宁的 IT 技术提出了更高的要求，其中一个重要的环节就是加快软件版本的上线步伐，伴随着软件的上线必然存在巨大的测试压力，在敏捷过程中，苏宁测试遇到了如下困境：

依赖方不可用，测试人员无法提前介入测试；数据构造，复杂的场景或者特殊的数据，无法很快生成，导致场景无法覆盖；异常模拟；外部系统不可用，或者没有对应的测试环境，或者需要现金交易；压测时，依赖方性能较差，无法保证本系统性能最优；全链路压测时，无法限定链路范围；

为了提高生产效率和测试覆盖率，苏宁蛙测平台上线全场景 Mock 桩服务解决方案，支持 HTTP、ESB、RPC 等协议 Mock，支持同步、异步以及回调场景等功能，成功解决测试人员、开发人员在测试和研发过程中，数据构造、环境依赖等痛点，大大提高了生产效率，提高测试场景的覆盖率，保障了业务版本上线的质量。目前蛙测 Mock 服务应用于苏宁 100+ 中台、后台系统，服务了 1000+ 万次桩服务调用，在苏宁各个测试产品线得到了广泛的应用。具备的能力如下：

实践过程及应用效果

第一阶段：Mock1.0 从无到有过程

当初，苏宁并没有一套通用的 MOCK 服务能力，各个业务线基本是由开发人员，在应用代码中，植入 Mock 逻辑，由测试人员在应用外部统一针对特定接口进行预埋桩响应内容，这样的方案给开发和测试带来了很大的工作量，开发人员需要在版本迭代过程中，不断维护 Mock 逻辑，同时也污染了应用代码，很容易把 Mock 逻辑发布到生产坏境，增加上线的风险。所以，迫切的需要一套通用的 Mock 服务能力。基于这样的问题，苏宁蛙测服务平台，通过收集各个产品线 Mock 需求、分析，开始从 0 到 1 建设一站式 Mock 服务能力，实现代码无侵入式的通用 Mock 服务桩，也就是 Mock1.0 版本，整体思路是与中间件打通，组件识别 Mock 的标识，将请求路由到 MockService 上，实现千人千面的 Mock 服务:

正常请求：

而由测试工具发起的请求（HTTP、ESB、RPC 等），首先测试人员会在本地预埋 Mock 响应内容，同时启动本地 MockService，在发起 Mock 请求时会生成的 Mock 标识，Mock 请求到达被测系统 A 时，相应组件会识别此 Mock 标识，将依赖方的请求转发到 MockService 上，大致思路如下：

Mock 请求：

Mock 标识如何传递:

RPC 类型：内部 Java 远程调用框架 RSF，在测试工具模拟服务消费方，发起 RSF 请求时，会附带本次请求中需要 Mock 的后端依赖方，以 Attachement 方式附带到 RSF 服务方，在服务方应用中，RSF 组件会进行识别、路由，RSF 中间件请求完成后，进行 Mock 信息清理；HTTP/ESB 类型：被测应用在打包或者 CD 发布时，手动或者自动在 web.xml 中配置中增加 Mock 的 filter 过滤器，在 doFileter 方法中，如果识别到 HTTP 请求头中包含 Mock 标识，则将 Mock 信息设置到中间件中，在中间件发起依赖方 HTTP 请求时，进行 Mock 识别、转发，请求结束后，清理本次请求的 Mock 信息；测试工具如何埋桩：

一次 RPC 的调用，可能涉及多个后端依赖系统服务调用，所以，在工具脚本设计时，增加了步骤 Group 概念。把本次一次调用过程中，需要 Mock 的调用，放在一个 Group 下，在发起请求时，把 Group 下的 Mock 步骤，打成多个 Mock flag 标识，供 RPC 组件中 Mock 识别模块识别，交互如下：

在 MockService 服务上，还支持匹配规则，根据匹配规则，响应不同内容。

在 Mock1.0 服务中，仅支持 RPC、HTTP、ESB 同步类型、基于单次请求级别的 Mock 调用，测试人员在本地用测试工具进行发起请求，每个测试工具都作为一个独立的 MockService 存在，达到互不干扰、千人千面的效果，同时业务方系统无需植入 Mock 代码，即可支持 Mock 能力，大大减少开发工作量和发布上线风险。

随着 Mock 功能深入开展，基于请求级别的 Mock 还远远不能完全满足业务测试场景，尤其是后台系统，测试人员在实际使用过程中，又遇到如下困难：

多线程、Job 等异步方式发起后端依赖方请求，尤其应用自己实现的多线程逻辑时，请求的调用链路会断开，导致 Mock 标识无法传递；被测应用的一次调用过程，往后端系统同一个接口，发起多次不同参数的请求，无法得到不同的 Mock 响应；实际测试场景中，存在回调过程，无法模拟；请求从 UI 层面发起时，无法生成 Mock 标识；为了解决测试的痛点，提高测试覆盖率，蛙测平台将 Mock1.0 进行功能扩展，推出了全局桩、UI 桩、回调桩等功能，也就是 Mock2.0 版本。

第二阶段：Mock2.0 从局部到全面过程

在 Mock1.0 版本中，仅支持请求级别的 Mock 功能，而在 Mock2.0 版本中，Mock 能力将从请求级扩展到全局桩、UI 桩、回调桩等全面桩，解决测试过程中，所涉及的 Mock 需求。

全局桩：

全局桩功能是为了解决异步、多线程等测试场景，整体思路是：测试人员事先一次性的将需要 Mock 的依赖方接口信息，刷入被测系统 JVM 内存中，这些 MOCK 信息，全局生效，当请求中没有附带 Mock 标识时（请求可能由页面触发、也能由其他测试工具触发），被 Mock 的后方接口，一律走全局桩服务，当请求中附带 Mock 标识时，请求级 Mock 优先级高于全局桩 Mock。

UI 桩：

UI 桩主要应用于是分层测试设计中，通过分层、解耦，可以简化问题，针对有明确分层设计的系统，在层与层之间验证接口的正确性。比如：Web、APP UI 层面，可以适当介入 Mock，将关键接口 Mock 掉，达到 UI 验证的目的，而后端接口，通过接口方式进行场景验证，从而达到分层测试目的。UI 桩设计思路如下：

测试工具可以自动将本地浏览器代理、手机代理设置为 Proxy 服务地址，同时，根据规则，监听前后交互请求，测试人员可以选择录制生成自动化脚本，还可以根据规则篡改、响应等等，达到前后分离测试目的，还能屏蔽后端服务或者接口，对边界值、等价类划分等数据进行模拟，提高测试场景覆盖。

测试工具提供简单的 GUI 操作，具体如下：

启动代理：

生成步骤：

埋桩：

回调桩：

在实际系统交互中，还存在这样的场景：后方依赖服务响应比较慢，在高并发场景下，调用方会积压大量的线程阻塞等待依赖方的返回结果，导致调用方资源被耗尽，产生严重后果，为了解决这种场景，业务方一般采用异步回调方式来解决。为了模拟异步回调测试场景，Mock 能力也扩展了回调功能，模拟后方系统结果返回、延迟回调等场景，从而达到测试目的。

第三阶段：从自动化到压测挡板过程

从第一阶段的请求级桩到全局桩，桩的服务能力不断增强，不断满足测试产品线各类业务场景，主要针对功能的验证，模拟依赖方的返回，并结合自动化工具，固化成脚本，达到复用的目的。但在性能测试过程中，期望对 Mock 还需具备压测挡板的能力，问题如下：

在跨系统的性能测试中，由于客观因素的限制，如：测试资源有限、后端系统不具备压测条件、后端系统性能不达标等，导致无法线下压测被测系统性能；全链路压测过程中，无法屏蔽外部依赖系统和限定链路范围；线下压测过程中，很难模拟在后端应用不同性能下，比如：延迟设置 0.5s、1s 甚至 2s 的不同延迟，考察被测应用在不同的延迟情况下的性能表现。为了解决以上压测过程中问题，蛙测推出了基于热插拔方式压测挡板服务，主要解决了压测过程中，模拟依赖应用性能，比如：TPS、响应延迟等，具备能力如下：

支持热插拔，随时可以终止 MockFilter 服务，提高了系统对灾难的及时恢复能力、扩展性和灵活性；支持消费端挡板，桩信息一次性刷入被测应用 jvm 中，被 Mock 的后端服务，直接从消费端内存中直接获取并返回，模拟延迟等，此 Mock 请求直接从被测应用的服务器内拿 Mock 响应；支持服务端挡板，桩服务由蛙测平台额外独立提供，根据用户设定的性能 TPS 指标，动态计算需要多少 Mock 服务线程以及多少台 Mock 服务节点，并把响应的 Mock 信息一次性刷入到 Mock 服务器中，供本次压测使用，此 Mock 请求从被测应用服务器外部拿 Mock 响应；为什么要区分消费端挡板和服务端挡板呢？主要是在实际应用中，尤其生产环境的压测，并没有那么多的 Mock 服务器资源供挡板调用，而消费端挡板恰恰解决了这一问题，充分利用被压应用服务器资源，压测预热前，一次性刷入需要 Mock 的后端应用服务，压测过程中，通过各个中间件进行 MockFilter，决定后端调用是 Mock 调用还是真实调用，是消费端 Mock 还是服务端 Mock。

消费端挡板整体思路：

服务端挡板整体思路：

蛙测挡板创建：

消费端 VS 服务端挡板压测结果对比：

压测目的：消费端挡板与服务端挡板性能对比机器 4C 8G场景：被 Mock 系统模拟桩数 1 万条

从压测对比中，得出结论：消费端挡板性能表现远远的高于服务端挡板，但相应的对于服务端资源消耗占比较高。针对以上数据对比，并结合实际业务场景压测需求，可择优选择合适的挡板方案。

结语

蛙测的 Mock 服务能力从最初的请求级、千人千面的 Mock 到全局桩能力，从手工测试到自动化测试再到压测挡板，不断的探索、提升测试过程中的效能。未来，我们还会在字节码层面进行线上录制，转化成自动化脚本，回放到测试环境，Mock 掉必要的依赖调用等，达到线上录制回放的目的，在测试技术方向，蛙测团队将会继续努力探索，永不停歇！