51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 1338|回复: 1
打印 上一主题 下一主题

[转贴] 测试实践——如何做一次生产压测

[复制链接]
  • TA的每日心情
    擦汗
    前天 09:04
  • 签到天数: 1047 天

    连续签到: 5 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2022-2-11 14:06:37 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
          相信很多人都填过问卷调查,目标用户收到问卷内容后在特定时间去填写且仅能提交一次的网上问卷调查。作为测试人员,怎么在特定时间去模拟百万用户填写并提交问卷调查是我今天想要分享的内容,包含测试方案编写、执行、数据关注等。接下来要分享的是我做线上压测的例子。(由于担心涉及敏感数据,以下我会用很多XX来表示,对压测流程描述没有影响。)

      功能设计
      通过发放调查问卷,了解XX(某个功能)的使用情况。

      压测方案
      压测方法
      采用(单)场景压测验证系统真实能力,探知系统最大水位,主要包含以下几点:
      从XXX发起,无限模拟真实用户发送流量;
      环境上无限逼近真实环境,使用生产环境结合数据库影子表的方式,充分验证生产真实链路;
      场景上无限逼近真实场景,使用场景验证,探测真实的系统瓶颈。
      压测机向生产环境发起流量,带上压测标,标记出压测流量,然后通过WEB服务器、EDAS中间件、DRDS中间件等实现压测标传递和识别,从数据上,在同一个库建立影子表用于压测数据的查询和存储,逻辑上隔离生产数据和压测数据。

      测试范围和目标
      问卷调查流程


      压测范围
      问卷调查的业务包含查询问卷调查、提交问卷调查。

      压测指标
      · 业务估算
      目前完成2020年度XXXX的用户大约5050万,计划选择目标用户群中的400万人进行推送。
      · 指标估算
      目前计划投放400万份问卷调查。目标用户查看和提交问卷调查的入口有2个,APP首页或者弹屏,其中弹屏这块参照公共中心1min处理5万,EMAS在1min处理9万(每秒保守1500的发送量,总共是5万,按照移动、联通、电信划分),故保守能在80min内完成投放。假设有80%的用户在收到问卷调查后的4个小时内会点击查看、提交问卷调查。


      [url=]测试用例[/url]


      注意事项
      XXX并发开始到XXXX并发(数值由小到大,慢慢探测。)

      链路说明


      数据设计
      数据类型和数据量
      对于生产小于XXXXW的数据,保持影子表与生产一致。对于生产大于XXXXW的数据,至少保证影子表数据为XXXXW。

      执行与监控
      链路侧上需要监控入口流量,主要是NG中的总请求量、每秒峰值请求量、其中APP渠道峰值QPS、其中客户端渠道峰值QPS。应用上需要监控的相关设备有应用服务器、数据库、REDIS,其主要监控指标如下:
      应用服务器监控项
      请求QPS峰值、CPU使用率、CPU load值、网络发送、网络接收、瞬时FullGC次数、runnable线程数、阻塞线程数、IO读、IO写。
      数据库监控项
      CPU使用率、网络输入、网络输出、逻辑QPS、物理QPS、逻辑RT、物理RT、连接数、活跃连接数。

      REDIS监控项
      连接数、内存、peak、流量流入、流量流出、QPS、CPU、keys_rt_avg_monitor、hit_rate_monitor。


      测试工具


      测试环境
      本次问卷调查[url=]压力测试[/url]将在专有云生产环境执行,通过问卷调查压测标和影子表实现生产、测试数据互隔离。

      脚本编写与调试
      JMeter
      因为问卷调查每人只能提交一次,所以编写脚本的时候跑完一次就要去数据库重置一下问卷调查是否已提交的状态。
      还有一种办法是设置两个线程,第一个线程组是启动后跑一次,然后把状态改掉,第二个线程组跑并发。如下图所示:


      图片第一个线程的设计



      第二个线程的设计(按需设置并发数):


      注意事项
      多个线程组要顺序执行,下图这个选项要勾选,否则两个线程组就是并行跑的。


      压测方案评审
      · 评审成员
      · 测试、开发、产品
      · 评审内容
      · 压测方案(压测指标、调用链路、测试用例等)
      · 数据库相关(表设计、[url=]SQL[/url]等)
      · 脚本

      脚本执行
      · 测试环境或者性能测试环境进行预测试(JMeter)
      · 生产环境影子表、脚本上传等准备
      · 生产上预测试
      · 生产上压测

      注意事项
      · 1和3一定要做,曾经我遇到过以下几种情况。
      · 测试环境压测时发现SQL有优化空间(多表查询)。
      · 测试环境压测时发现有个逻辑处理有优化空间(有个每个人都先去查企业信息再去查询XX的逻辑可以优化成查一次企业信息,在这个企业下的人直接去查询XX)。
      · 生产预测试的时候发现有报错,通过查看日志发现有个配置有问题。(生产预测试一般在正式压测的前几个小时做,假设晚上10点压测,预测试6点就可以跑一下,以防10点才发现问题。)

      监控采集
      · 应用层图片


      · 数据库


       ·将采集结果分析后填写到表格里


      测试报告
      输出详细的测试报告:


      报告里呈现测试结论:


      以上内容就是全部,包含了整个性能测试的流程(梳理调用链路-编写脚本-调试-预测试-正式测试),以及关注性能测试报告的哪些数据。

    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏1
    回复

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    2#
    发表于 2022-3-30 17:36:26 | 只看该作者
    生产压测最重要的就是别把生产给压垮了
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-17 07:12 , Processed in 0.064390 second(s), 23 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表