聊聊性能测试中梳理流量模型的方法

昨天有同学问了我这样一个问题：

在开展性能测试梳理流量模型时，到底应该按照业务近几个月的交易量来计算流量占比，还是应该按照top5门店的交易量来计算流量流量模型？

我给这位同学的回答就一句话：视你的被测业务场景而定。

开展性能测试时，梳理三大模型(业务模型、流量模型、数据模型)是前期准备阶段的核心工作，只有将这三大模型梳理清楚，才能在性能测试实施阶段得到更精准的结果。

但我发现很多同学在这个阶段，要么拍脑袋定几个指标就开搞，要么拿了一大堆数据不得要领，最后的结果自然无法对线上系统容量给到很好的参考，更不要提容量规划和稳定性保障了。

这篇文章，具体聊聊性能测试中，梳理流量模型的几个方法。

首先，简单聊聊为什么三大模型是性能测试前期准备阶段的核心工作。

所谓的三大模型，即业务模型、流量模型、数据模型。其中，业务模型决定测什么，流量模型决定怎么测，数据模型决定如何开展测试。

在性能测试工作，三大模型是至关重要且必须在项目中构建的，否则很可能导致测试场景和实际差距很大，测试结果最终无法为性能分析和优化提供足够的有说服力的支撑。

为了便于大家理解三大模型，我会以电商业务下单的场景来举例说明，如下图：

其中，业务模型可以看作功能测试中的业务场景，决定了测试用例怎么设计；流量模型的本质，其实是按照不同的业务场景将请求按照真实的线上比例进行配置，也称之为业务配比；数据模型则很好理解，即执行压测时的输入数据。

因为性能测试会在短时间内发起大量请求，这是构建数据模型的根本原因。否则如果按照功能测试的方法，几条数据重复使用，很容易导致请求失败。构建数据模型的目的，最直观的就是压测时候的测试数据参数化。

其次，对流量模型进行详细的拆解。

通常来说，执行压测时都是基于接口或URL来进行的，本质是模拟生产环境的用户，构造请求对被测系统施加压力，验证系统性能是否满足业务需要，是否存在性能瓶颈。生产环境的用户操作场景是很复杂的，所以请求的大小和请求路径也各不一样。

以上图为例，下单时候有些用户使用了优惠券，有些用户不是vip会员无法享受折扣，有些商品没有营销活动。这些因素要求我们在构造请求时，需要按照不同的业务场景构造不同的请求。

大家也可以将流量模型理解为压测模型，工作中常见的压测模型有如下三种：

1、单机单接口基准测试：最常见的就是对登录场景进行压测。我们可以通过梯度递增的方式，观察随着请求的增加，其性能表现&资源损耗的变化。

2、单机混合链路容量测试：以上图为例，订单服务包含创建订单、取消订单、订单列表、订单详情等接口。每个接口的请求量大小、请求内容各不相同。单机混合场景，大多通过梯度增加请求的方式，观察服务级别的性能表现，目的是排查上下游调用依赖的瓶颈。

3、生产环境全链路压测场景：常见的案例就是双11电商大促。生产全链路压测模型较多，一般有如下几种：

梯度加压：探测集群模式下系统的最大吞吐量（避免压垮服务，造成事故）；
固定并发：验证系统长期处于负载下的稳定性；
脉冲并发：验证系统的健壮性、限流熔断等服务保护措施的正确性&可用性；
超卖验证：对电商业务来说，主要针对一些限时抢购&秒杀的场景(一般这种场景，会涉及到分布式锁、缓存、数据一致性等技术点；玩不好的话，容易造成客诉、资损、甚至服务异常宕机)。

再次，聊聊如何构建流量模型。

下面是我在实际工作中一次双11大促时的流量模型构建案例，供大家参考。

业务目标：客单均价500，单日GMV10亿，则可得支付订单量为10亿/500=200W。

技术指标：

假设日常支付订单量为50W，支付转化率为40%，订单支付QPS峰值为200。预估大促时的支付转化率为60%，则可得：大促峰值订单支付QPS为（200/40%）60%（200W/50W）=1200QPS。为了留有一定冗余空间，上浮30%，即订单支付的QPS预估为1500；
电商的导购下单支付链路为：首页→商品详情→创建订单→订单支付→支付成功，这是类似漏斗的一个转化逻辑。假设首页→商品详情转化率为40%，商品详情→创建订单转化率为40%，创建订单→订单支付转化率为40%，那么可得：创建订单QPS为1500/40%=3750，商品详情QPS为3750/40%=9375，首页QPS为9375/40%=23437；
按照核心链路之间的依赖调用关系，借助trace追踪，可得到大促期间所有核心应用及核心链路的QPS数值。

建议评估流量模型后，结合业务场景和服务间的调用关系，绘制成一个流量模型图，这样会更直观，便于工作开展。

最后，以开篇问题为例，回答一下梳理流量模型时，为什么要视被测业务场景而定。

这个问题的答案很简单，即先确定业务场景，再设计测试用例，最后根据测试用例准备测试数据。无论功能测试或者性能测试，开展的前提是按照测试用例执行，而测试用例来源于需求分析的结果。

简单来说，梳理流量模型的前提，是被测业务场景是从什么维度或者目标来确定的。

如果你的测试目标，是验证所有交易业务系统的性能表现，那在梳理流量模型时，就要拉取所有的交易量。如果只是验证部分门店(假设你们的业务有不同线上渠道或者按照不同区域划分线下门店)，则只需要统计该部分门店的交易量。

当然，有一种比较特殊的情况，就是要验证的这部分门店的交易量占比，在所有的交易业务量中占据绝大多数，则可以以这部分门店的交易量当作总交易量。

其实性能测试没大家想象的那么复杂，只需要抓住几个核心点(测试目的、测试目标、统计维度)，然后按照目前已经很成熟的性能测试流程执行即可。