超全性能测试-全链路压测总结，完整一套从环境到脚本详细...

目录：导读

前言

性能测试，全链路压测在准备阶段，测试同学要做哪些事情呢？

请添加图片描述

环境准备

一般来说，需要准备如下三套环境。
环境准备阶段，大体的工作事项和分工如下：

请添加图片描述

1、功能验证环境
功能验证环境即用来验证技术组件本身的功能正确性和接入性能损耗的环境，有独立的随时可用的环境最好。

如果考虑到成本，也可以用线下性能环境来进行验证。
实践经验来说，功能验证阶段，要做的事情核心有如下几点：
能否快速接入；
压测标记是否完整的透传到了数据库表；
数据落库或者读库的路由逻辑是否正确；
下游或外部调用是否都被mock挡板过滤；
采用自动化的方式快速验证接口链路是否正常；
梳理的业务场景和测试场景是否都匹配了接入的业务范围等；
接入前后对业务应用以及中间件的性能损耗是否在可接受范围内；

2、线下性能环境
如果未经基础的测试就直接在生产环境开展全链路压测，风险和问题排查成本都是很高的。

线下性能测试环境的作用如下：
满足日常的版本迭代和技术优化性能验证需要；
生产压测前的单机单接口和单机混合链路压测验证；
为生产压测集群的资源扩容提供容量评估的参考依据；

3、生产压测集群
因为全链路压测都是在生产环境进行，压测的目的也是为了满足未来某个时期业务活动的需要，因此需要提前评估准备资源。

这里的资源指的是扩容的资源，而非单独重新搭建环境的资源。

一般需要准备的资源如下：
带宽资源；CDN资源；应用资源；缓存资源；M Q资源；短信资源；D B资源；

数据准备

全链路压测过程中，涉及的数据以及职责分工如下：

1、铺底数据
铺底数据可以简单理解为冷数据，因为SQL执行过程中，空表和大表对性能的影响还是很大的。

准备铺底数据，还要根据具体的数据隔离技术实现方案来看，分为如下2方面：

正式表：如果数据隔离方案采用的是读写业务表，那无须准备铺底数据。但压测产生的数据需要通过特殊字段来做标识处理，避免对业务造成影响。

影子表：如果采用的是影子表方案，常见的做法就是将涉及到的库表数据按需按量同步到影子表并进行脱敏。

影子库：影子库的数据铺底数据准备方案和影子表类似，但要考虑的一点是：因为影子库是正式库是在同一个请添加图片描述
数据库实例上，需要更多的硬件资源支撑，以及在参数配置上(如活跃连接数)需要进行一定调整。

2、热点数据
为了避免压测时瞬间的大流量对服务的冲击，需要提前将这些热点数据预热到缓存中。最典型的热点数据莫过于用户的登录态token了，其他还有类似秒杀活动的库存数据、商品信息数据以及优惠券等数据。

当然，热点数据的预热，需要根据具体的业务来制定预热方案，而非单纯的照着做。

3、参数化数据
参数化数据指的是压测过程中脚本中需要引用到的数据。以电商业务来说，常见的有用户id，商品id，订单id。

准备参数化数据的过程中，需要注意如下几点：
数据的幂等性（是否可重复使用）；
数据的关联性（是否需要前置动作来更新状态）；
数据的有效性（数据需要在使用阶段内一直生效）；
数据的唯一性（数据在逻辑处理中仅且只有某些场景才可用）；

数据可用性验证
做完了上述的几点数据准备工作，最后要做的就是对数据可用性进行验证，看看它是否如预期满足工作需要。

脚本准备

1、脚本开发
脚本准备实际上是个很复杂的事情，因为要考虑到具体的业务场景和压测链路。

一般遵循如下的过程步骤：
梳理核心链路（得到被测应用和涉及到的接口）；
梳理流量模型（便于压测过程中性能指标监控及流量模型配置）；
划分脚本类型；

准备测试数据的脚本（某些场景用到的数据需要通过前置动作才能产生）；

单机单接口压测脚本（性能环境快速验证接口维度的性能表现，快速发现性能瓶颈）；
单机混合链路压测脚本（性能环境快速验证应用维度的性能表现，调整流量配比，便于容量评估）；
生产环境全链路压测脚本（生产环境压测专用的压测脚本）；
梯度增加脚本（验证生产环境的性能，发现性能瓶颈和拐点）；
稳定性验证脚本（验证生产服务集群在长时间高负载情况下的稳定性）；
数据状态恢复脚本（特殊业务场景下某些数据只能用一次，可以理解为一种数据回滚策略）；
稳定性预案验证脚本（验证限流、熔断、降级等稳定性预案是否生效）；

2、脚本联调
脚本开发完成，接下来就是联调工作。

联调阶段，除了要考虑环境因素，重点是验证数据模型和流量模型是否匹配的问题。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图