测试实践——如何做一次生产压测
相信很多人都填过问卷调查，目标用户收到问卷内容后在特定时间去填写且仅能提交一次的网上问卷调查。作为测试人员，怎么在特定时间去模拟百万用户填写并提交问卷调查是我今天想要分享的内容，包含测试方案编写、执行、数据关注等。接下来要分享的是我做线上压测的例子。（由于担心涉及敏感数据，以下我会用很多XX来表示，对压测流程描述没有影响。）功能设计
通过发放调查问卷，了解XX（某个功能）的使用情况。
压测方案
压测方法
采用（单）场景压测验证系统真实能力，探知系统最大水位，主要包含以下几点：
从XXX发起，无限模拟真实用户发送流量；
环境上无限逼近真实环境，使用生产环境结合数据库影子表的方式，充分验证生产真实链路；
场景上无限逼近真实场景，使用场景验证，探测真实的系统瓶颈。
压测机向生产环境发起流量，带上压测标，标记出压测流量，然后通过WEB服务器、EDAS中间件、DRDS中间件等实现压测标传递和识别，从数据上，在同一个库建立影子表用于压测数据的查询和存储，逻辑上隔离生产数据和压测数据。
测试范围和目标
问卷调查流程
http://www.51testing.com/attachments/2022/02/15326825_2022020814423310evI.png
压测范围
问卷调查的业务包含查询问卷调查、提交问卷调查。
压测指标
· 业务估算
目前完成2020年度XXXX的用户大约5050万，计划选择目标用户群中的400万人进行推送。
· 指标估算
目前计划投放400万份问卷调查。目标用户查看和提交问卷调查的入口有2个，APP首页或者弹屏，其中弹屏这块参照公共中心1min处理5万，EMAS在1min处理9万（每秒保守1500的发送量，总共是5万，按照移动、联通、电信划分），故保守能在80min内完成投放。假设有80%的用户在收到问卷调查后的4个小时内会点击查看、提交问卷调查。
http://www.51testing.com/attachments/2022/02/15326825_202202081442332xXvW.png
测试用例
http://www.51testing.com/attachments/2022/02/15326825_202202081442333JInQ.pnghttp://www.51testing.com/attachments/2022/02/15326825_202202081442333JInQ.png
注意事项
XXX并发开始到XXXX并发（数值由小到大，慢慢探测。）
链路说明
http://www.51testing.com/attachments/2022/02/15326825_202202081442334hZ2x.png
数据设计
数据类型和数据量
对于生产小于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。
http://www.51testing.com/attachments/2022/02/15326825_202202081442335Z2TC.png
测试工具
http://www.51testing.com/attachments/2022/02/15326825_202202081442336WmTR.png
测试环境
本次问卷调查压力测试将在专有云生产环境执行，通过问卷调查压测标和影子表实现生产、测试数据互隔离。
脚本编写与调试
JMeter
因为问卷调查每人只能提交一次，所以编写脚本的时候跑完一次就要去数据库重置一下问卷调查是否已提交的状态。
还有一种办法是设置两个线程，第一个线程组是启动后跑一次，然后把状态改掉，第二个线程组跑并发。如下图所示：
http://www.51testing.com/attachments/2022/02/15326825_202202081442337BzGF.png
图片第一个线程的设计
http://www.51testing.com/attachments/2022/02/15326825_2022020814423387Q2O.png
http://www.51testing.com/attachments/2022/02/15326825_202202081442339AdYw.png
第二个线程的设计（按需设置并发数）：
http://www.51testing.com/attachments/2022/02/15326825_202202081455061CgWY.png
注意事项
多个线程组要顺序执行，下图这个选项要勾选，否则两个线程组就是并行跑的。
http://www.51testing.com/attachments/2022/02/15326825_202202081455062xswM.png
压测方案评审
· 评审成员
· 测试、开发、产品
· 评审内容
· 压测方案（压测指标、调用链路、测试用例等）
· 数据库相关（表设计、SQL等）
· 脚本
脚本执行
· 测试环境或者性能测试环境进行预测试（JMeter）
· 生产环境影子表、脚本上传等准备
· 生产上预测试
· 生产上压测
注意事项
· 1和3一定要做，曾经我遇到过以下几种情况。
· 测试环境压测时发现SQL有优化空间（多表查询）。
· 测试环境压测时发现有个逻辑处理有优化空间（有个每个人都先去查企业信息再去查询XX的逻辑可以优化成查一次企业信息，在这个企业下的人直接去查询XX）。
· 生产预测试的时候发现有报错，通过查看日志发现有个配置有问题。（生产预测试一般在正式压测的前几个小时做，假设晚上10点压测，预测试6点就可以跑一下，以防10点才发现问题。）
监控采集
· 应用层图片
http://www.51testing.com/attachments/2022/02/15326825_202202081455063bdyy.png
· 数据库
http://www.51testing.com/attachments/2022/02/15326825_202202081455064DIxJ.png
·将采集结果分析后填写到表格里
http://www.51testing.com/attachments/2022/02/15326825_202202081455065RVoL.png
测试报告
输出详细的测试报告：
http://www.51testing.com/attachments/2022/02/15326825_202202081455066Wpkh.png
报告里呈现测试结论：
http://www.51testing.com/attachments/2022/02/15326825_202202081455067EZbe.png
以上内容就是全部，包含了整个性能测试的流程（梳理调用链路-编写脚本-调试-预测试-正式测试），以及关注性能测试报告的哪些数据。
生产压测最重要的就是别把生产给压垮了
页:
[1]
