性能测试-如何开展

时间:2024-01-25 16:42:03

背景:最近正在准备双十一的准备,所以压测就是我们的第一要务。

一、需求调研:(我们公司需求为列简单列出)

  • 测试范围:订单流程、搜索等
  • 系统架构: gateway  、ES 、MySQL redis
  • 业务逻辑 & 数据流向:略
  • 测试数据量:商品数量:1w,用户数据:1w
  • 外部依赖:调用其他rpc,如user服务,mq等
  • 预期指标:
  • 1> 业务监控系统,找到业务量峰值,除以机器数量,计算出单机系统每秒的业务量
  • 2> 访问日志统计接口调用量。或者数据库表中查询每天的写入数据量,通过eads就能了解到
  • 命令:awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -10
  • 3> 只知道每天大概的业务总量,(每天的总业务量*80%) / (24 小时*3600 *20%)/ 部
  • 署机器数量 / 性能冗余量(30%-50%)
  • 业务比例:暂无
  • ps1 :性能测试,需求分析特别重要,一定要知道真实场景,场景不对,就等于白忙活;监控+工具提前都需要准备;
  • ps2:真实的压测场景,总会遇到一些问题,产品或者技术就给你说,我有个接口你给我们压压,就是不说我给你压多少;最好可能压的场景和实际的结果有出入,如果真的出了问题,可能要背锅(不过迄今为止没有发生线上严重的问题,除了一次的优惠券)

二、业务场景:(以我们公司为例)

  • 明确我们的测试范围和目的
  • 我们是社交电商+活动;促销活动,商品搜索、物流仓储业务,基础消息及推送服务(mq),订单交易+余额支付,拼店业务+秀场业务
  • 知道了这些范围,我们就可以和产品、开发、一起来梳理这些流程:
  • 首页:就是登陆,查看活动首页,看是否崩溃
  • 商品:商品搜索(数万级别)、查看商品详情
  • 订单:选择商品下单,确认订单,利用余额支付;选择商品+购物车,进行下单支付;最后查看订单商品;从拼店入口+选择商品,进行下单
  • 支付:采用余额支付,三方支付暂时没有考虑,mook掉了
  • 个人中心,签到流程,
  • 活动,首页营销活动,领取奖品,消耗奖品和优惠券
  • ps1:APP首页会关心活动首页和活动会有强依赖;商品和搜索、商品详情,加入购物车,甚至下单会发送消息有强依赖;订单、购物车、支付、搜索、用户和交易有强依赖的业务
  • ps2:压测前,分析各业务之间强弱依赖关系,不同服务会根据业务属性来进行高度内聚解耦,划分不同功能的优先级和重要程度

三、链路场景分析:

  • 场景和业务都梳理了,我们就需要对它的分析,需要从需求到测试点的覆盖和执行;
  • 任务拆解,细化,把场景转化成操作流程;
  • 任务确定时间;测试准备、数据准备、环境准备、瓶颈优化,这些时间都需要考虑进去,然后出一个时间;
  • 权重划分:哪些重要,资源偏向,还有就是场景比例的投放得当;

四、压测执行:

  • 以上工作做得差不多,还是需要拉一个会议讨论下,需要各方面的支持资源都需要沟通好
  •  

     该图采用老张很优秀的一副,看了老张这篇文章,最近也刚好做了,有很多共鸣,所以记录下

  • 老张连接https://www.cnblogs.com/imyalost/p/11415691.html