开发者社区> 大数据文摘> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

基于RPC接口的业务侧流量回放

简介: 在产品需求迭代过程中,功能测试与回归测试是必不可少的两个环节。对于改动较大的项目,首先,确保功能的实现符合产品逻辑并做到100%没有问题离不开有效的功能测试;其次,项目中很多逻辑的改动都是在原有功能的基础上进行的,这时候就需要一定的回归测试。通常,在功能测试时,人工case不能模拟线上用户的所有行为,且具有一定的主观性;回归测试时,采用全面回归的方式往往也伴随着测试成本的增加。一个好的方式就是利用线上流量来验证。
+关注继续查看

背 景\
在产品需求迭代过程中,功能测试与回归测试是必不可少的两个环节。对于改动较大的项目,首先,确保功能的实现符合产品逻辑并做到100%没有问题离不开有效的功能测试;其次,项目中很多逻辑的改动都是在原有功能的基础上进行的,这时候就需要一定的回归测试。通常,在功能测试时,人工case不能模拟线上用户的所有行为,且具有一定的主观性;回归测试时,采用全面回归的方式往往也伴随着测试成本的增加。一个好的方式就是利用线上流量来验证。

一方面,通过记录线上流量,在沙箱或者测试环境回放,来发现新分支代码是否能够让系统功能正常运行,从而降低代码变动给整体系统带来的风险;
另一方面,通过线上流量进行线下回归测试可以在保障全面回归的情况下有效的节约测试成本。

简 介
流量回放
使用真实的线上流量进行线下回放测试,节约回归测试成本,保障代码质量,进而减少线上事故。

流量平台搭建成本
全链路流量平台具备的能力

能录制线上真实流量;
能实现海量数据的并发请求;
能支持常见协议的请求;
对线上尽量应用透明,也就是说无侵入性;
工具使用简单,能够满足各场景流量回放。

可以看出按照以上的能力需求搭建一个流量平台需要投入一定的成本,而我们目前考虑的是针对某一个项目的快速流量回放,可能并不需要设计这么复杂并且重量级的流量平台。那么,如何快速的实现满足业务需求的流量回放呢?基于RPC接口的流量回放,简单、快捷、容易上手。接下来我将通过实际的业务场景来介绍下流量回放在采货侠卖场侧的业务应用。
流量回放的应用
1、项目背景
采货侠卖场侧新增后台配置功能且还涉及到对成拍逻辑的改动,需要验证新功能的正确性并对多种成单场景进行一定的回归测试。

回归工作量大需要有效的手段提高测试效率;
成单逻辑不容出错需要100%的保障。

2、 方案
流量回放

回归测试:使用真实的线上流量进行线下回放测试,对比不支持议价功能的商品线上、线下成单结果的一致性;
功能测试:使用真实的线上流量进行线下新功能的验证。线上保持原有Apollo配置逻辑,线下应用新开发运营后台的配置功能。保持相同配置应用线上流量数据通过新开发分支代码运行获取相应的成单结果,验证补贴后台和议价后台功能的正确性。

优点

可以高度结合业务逻辑,实现细粒度定制化流量复制;
解放部分回归测试的人力成本,提升测试效率;
对业务的用例场景更加客观,保障代码质量,进而减少线上事故。

3、核心功能
流量采集

通过云窗获取相应要求的线上商品信息以及对应的最高出价和成单结果
将云窗所得线上数据的相关信息写入到数据库对应的字段中

流量回放

代码设计逻辑

首先,通过读取线上商品的保底价映射成相同价格的线下商品参拍暗拍卖场,接着模拟用户在采货侠卖场中的真实行为进行流量回放,并将线下的商品数据和成单结果写入数据库表;整个过程中采用了多线程以及数据库表批量增加、查找来提高运行效率。

数据存储结果

表中线上、线下数据一一对应存储,清晰、明了有利于结果分析。

结果分析
结果分析思路:调用开发分支在测试环境进行流量回放,得到相应的期望结果后和线上同一商品的相应结果进行比较,判断结果是否一致。校验的字段可根据实际需求场景进行相应的变更,在本次案例中验证的字段是成单结果和补贴金额。

回归测试验证逻辑

读取不议价商品的流量回放成单结果和线上相应数据的成单结果进行对比,判断结果是否一致。如下图所示为成单验证结果:线上和线下的成单结果全部是一致的,这说明新需求代码的开发未影响到原有不议价商品成单逻辑的正确性。此外,采用该方法进行测试使原计划进行回归测试的时间缩短了3倍多,这有效的节约了回归测试的成本。

功能测试验证逻辑

为了做进一步的功能保障。通过获取线上真实的用户流量,在保证线上原有配置和线下运营后台一致的情况下,调用新分支代码实现线下流量回放得到相应的预期结果,然后和线上结果进行比对。首先,对比线上、线下成单结果是否一致来验证成单逻辑的正确性;其次通过比较线上、线下补贴金额是否一致来验证运营后台补贴配置功能的正确性。本次验证不关心成单后商品的状态流转,而线上部分商品状态已经流转,所以验证成单结果时,可以把生成订单后流转的一些状态重置为成单状态和线下成单结果进行比对。逻辑如下:

验证结果如下:

首次验证结果中出现了部分商品线上、线下成单结果不一致,需进一步分析解决
问题1: 线下部分商品状态一直在售卖中
原因: 有部分商品调用结束竞拍没有成功
解决: 商品调用结束竞拍失败后继续重新调用
问题2: 线上商品成单,线下商品却是流拍
原因: 线下运营后台部分价格段的设置没有和线上的保持一致
解决: 保证线上、线下各价格段补贴、议价金额一致
确保线上、线下配置一致的情况下,使用优化后的代码重新进行流量回放,可以得到相同成单结果和补贴结果。说明运营后台配置功能的代码实现以及成单逻辑都是正确的。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Redis挂了,流量把数据库也打挂了,怎么办? (中)
Redis挂了,流量把数据库也打挂了,怎么办? (中)
81 0
Redis挂了,流量把数据库也打挂了,怎么办? (下)
Redis挂了,流量把数据库也打挂了,怎么办? (下)
26 0
歪国人整理的 2019 年 Java 开发路线图,值得参考!
许多Java开发人员都希望通过某种Java成长路线图,来解答有关:该学习哪些技术,使用哪些工具以及框架之类的问题。 在此,我将向大家展示一张根据自己多年经验总结出的路线图。该路线图在保持简单可行的基础上,介绍了各种具有业界标准、且方便多数人遵循的工具和程序库。
32 0
HBase流量限制和表负载均衡剖析
1.概述   在HBase-1.1.0之前,HBase集群中资源都是全量的。用户、表这些都是没有限制的,看似完美实则隐患较大。今天,笔者就给大家剖析一下HBase的流量限制和表的负载均衡。 2.内容   也许有同学有疑问,为啥要做流量限制,无限制全量跑不是更好吗?举个例子,比如今天的双十一日,数据流量是非常大的。
1606 0
基于VLC的播放器开发
VLC的C++封装     因为工作需要,研究了一段时间的播放器开发,如果从头开始做,可以学习下FFmpeg(http://www.ffmpeg.org/),很多播放器都是基于FFmpeg开发的,但是这样工作量和难度都比较大,如果想很快能拿出一个播放器来用的,可以研究下开源的播放器,参考下射手播放器作者的文章:媒体播放器三大底层架构。
1051 0
[转]基于C#的接口基础教程之一
from: http://www.vs2005.com/CSharp-VB.NET/9/1/default.aspx第一节 接口慨述        接口(interface)用来定义一种程序的协定。实现接口的类或者结构要与接口的定义严格一致。
666 0
23
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载