全链路压测(10):测试要做的准备工作

本文涉及的产品
性能测试 PTS,5000VUM额度
简介: 功能验证环境即用来验证技术组件本身的功能正确性和接入性能损耗的环境,有独立的随时可用的环境最好。如果考虑到成本,也可以用线下性能环境来进行验证。

前言


前面的几篇文章介绍了全链路压测准备阶段的很多事项,包括核心链路梳理、构建压测模型、容量评估和容量规划,大多都是研发和运维同学负责的事情。


那么全链路压测在准备阶段,测试同学要做哪些事情呢?以我个人的实践经验来说,全链路压测在准备阶段,测试同学要做的事情主要有如下几点。


640.jpg


环境准备


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


640.jpg


功能验证环境


功能验证环境即用来验证技术组件本身的功能正确性和接入性能损耗的环境,有独立的随时可用的环境最好。如果考虑到成本,也可以用线下性能环境来进行验证。实践经验来说,功能验证阶段,要做的事情核心有如下几点:


  1. 能否快速接入;
  2. 压测标记是否完整的透传到了数据库表;
  3. 数据落库或者读库的路由逻辑是否正确;
  4. 下游或外部调用是否都被mock挡板过滤;
  5. 采用自动化的方式快速验证接口链路是否正常;
  6. 梳理的业务场景和测试场景是否都匹配了接入的业务范围等;
  7. 接入前后对业务应用以及中间件的性能损耗是否在可接受范围内;


线下性能环境


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


线下性能测试环境的作用如下:


  1. 满足日常的版本迭代和技术优化性能验证需要;
  2. 生产压测前的单机单接口和单机混合链路压测验证;
  3. 为生产压测集群的资源扩容提供容量评估的参考依据;


生产压测集群


因为全链路压测都是在生产环境进行,压测的目的也是为了满足未来某个时期业务活动的需要,因此需要提前评估准备资源。这里的资源指的是扩容的资源,而非单独重新搭建环境的资源。一般需要准备的资源如下:


  1. 带宽资源;
  2. CDN资源;
  3. 应用资源;
  4. 缓存资源;
  5. M Q资源;
  6. 短信资源;
  7. D  B资源;


数据准备


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


640.jpg


铺底数据


铺底数据可理解为冷数据,SQL执行过程中,空表和大表对性能的影响还是很大的。


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


  1. 正式表:如果数据隔离方案采用的是读写业务表,那无须准备铺底数据。但压测产生的数据需要通过特殊字段来做标识处理,避免对业务造成影响。
  2. 影子表:如果采用的是影子表方案,常见的做法就是将涉及到的库表数据按需按量同步到影子表并进行脱敏。
  3. 影子库:影子库的数据铺底数据准备方案和影子表类似,但要考虑的一点是:因为影子库是正式库是在同一个数据库实例上,需要更多的硬件资源支撑,以及在参数配置上(如活跃连接数)需要进行一定调整。


热点数据


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


参数化数据


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


准备参数化数据的过程中,需要注意如下几点:


  1. 数据的幂等性(是否可重复使用);
  2. 数据的关联性(是否需要前置动作来更新状态);
  3. 数据的有效性(数据需要在使用阶段内一直生效);
  4. 数据的唯一性(数据在逻辑处理中仅且只有某些场景才可用);


数据可用性验证


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


脚本准备


脚本开发


脚本准备实际上是个很复杂的事情,因为要考虑到具体的业务场景和压测链路。我在实践中的做法,一般遵循如下的过程步骤:


  1. 梳理核心链路(得到被测应用和涉及到的接口);
  2. 梳理流量模型(便于压测过程中性能指标监控及流量模型配置);
  3. 划分脚本类型;
  • 准备测试数据的脚本(某些场景用到的数据需要通过前置动作才能产生);
  • 单机单接口压测脚本(性能环境快速验证接口维度的性能表现,快速发现性能瓶颈);
  • 单机混合链路压测脚本(性能环境快速验证应用维度的性能表现,调整流量配比,便于容量评估);
  • 生产环境全链路压测脚本(生产环境压测专用的压测脚本);
  • 梯度增加脚本(验证生产环境的性能,发现性能瓶颈和拐点);
  • 稳定性验证脚本(验证生产服务集群在长时间高负载情况下的稳定性);
  • 数据状态恢复脚本(特殊业务场景数据只能用一次,可理解为数据回滚策略);
  • 稳定性预案验证脚本(验证限流、熔断、降级等稳定性预案是否生效);


脚本联调


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


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


压测方案


编写压测方案的目的:同步信息,保持整体的压测节奏一致,为下一阶段工作做铺垫。


  1. 背景和目的(通用内容);
  2. 业务和技术指标(统一目标,即使有临时变更也能快速调整);
  3. 涉及范围和链路(更细化的内容,需要和涉及的各团队一一对齐);
  4. 压测实施里程碑(生产压测需要多轮,每轮次的目标和要做的事情);
  5. 压测任务及进度(整体的压测任务拆分以及当前进度,提前评估风险);
  6. 压测模型和策略(类似功能测试过程中的case评审,查漏补缺的过程);
相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
27天前
|
Web App开发 前端开发 安全
前端研发链路之测试
本文由前端徐徐撰写,介绍了前端测试的重要性及其主要类型,包括单元测试、E2E测试、覆盖率测试、安全扫描和自动化测试。文章详细讲解了每种测试的工具和应用场景,并提供了选择合适测试策略的建议,帮助开发者提高代码质量和用户体验。
28 3
前端研发链路之测试
|
10天前
|
缓存 监控 数据挖掘
C# 一分钟浅谈:性能测试与压力测试
【10月更文挑战第20天】本文介绍了性能测试和压力测试的基础概念、目的、方法及常见问题与解决策略。性能测试关注系统在正常条件下的响应时间和资源利用率,而压力测试则在超出正常条件的情况下测试系统的极限和潜在瓶颈。文章通过具体的C#代码示例,详细探讨了忽视预热阶段、不合理测试数据和缺乏详细监控等常见问题及其解决方案,并提供了如何避免这些问题的建议。
32 7
|
2月前
|
缓存 Java 测试技术
谷粒商城笔记+踩坑(11)——性能压测和调优,JMeter压力测试+jvisualvm监控性能+资源动静分离+修改堆内存
使用JMeter对项目各个接口进行压力测试,并对前端进行动静分离优化,优化三级分类查询接口的性能
谷粒商城笔记+踩坑(11)——性能压测和调优,JMeter压力测试+jvisualvm监控性能+资源动静分离+修改堆内存
|
3月前
|
消息中间件 Kafka 测试技术
【Azure 事件中心】使用Kafka的性能测试工具(kafka-producer-perf-test)测试生产者发送消息到Azure Event Hub的性能
【Azure 事件中心】使用Kafka的性能测试工具(kafka-producer-perf-test)测试生产者发送消息到Azure Event Hub的性能
|
3月前
|
Java 测试技术
SpringBoot单元测试快速写法问题之区分链路环节是否应该被Mock如何解决
SpringBoot单元测试快速写法问题之区分链路环节是否应该被Mock如何解决
|
4月前
|
弹性计算 Prometheus Cloud Native
SLS Prometheus存储问题之Union MetricStore在性能测试中是如何设置测试环境的
SLS Prometheus存储问题之Union MetricStore在性能测试中是如何设置测试环境的
|
3月前
|
Java 测试技术 API
SpringBoot单元测试快速写法问题之确定链路上的Mock点如何解决
SpringBoot单元测试快速写法问题之确定链路上的Mock点如何解决
|
3月前
|
测试技术 索引 CDN
hyengine wasm业务性能测试问题之测试设备如何解决
hyengine wasm业务性能测试问题之测试设备如何解决
|
4月前
|
监控 数据可视化 测试技术
性能测试:性能测试报告
**性能测试报告摘要** 报告详述系统在不同负载下的性能,作为决策、问题发现与解决、沟通合作及监控改进的依据。内容涵盖测试目的、环境、策略、用例、结果、分析、问题、调优建议及风险评估。清晰的图表辅助理解,为开发团队提供优化指导,确保系统性能与用户体验的提升。
80 2
|
4月前
|
监控 测试技术 应用服务中间件
性能测试:性能测试计划
性能测试计划是在进行软件或系统的性能测试之前制定的详细计划和指导文件。它描述了所需性能测试的目标、范围、测试环境、资源需求、测试策略、测试用例、时间表等重要信息。
66 0