你以为的场景根本不是用户真实走的路径
很多人对压测的认知还停留在“把接口QPS拉到预期值的两倍就算完事”。没用的。
你就算把登录接口压到1万QPS，也架不住真实用户根本不会在高峰期同时挤着登录——大部分人是刷着刷着商品想起来要加购，才顺手登一下。这种非集中式、带随机跳转的行为，是你写个固定循环脚本根本模拟不出来的。
之前见过一个团队做短视频APP压测，脚本里写的流程是打开APP就直接滑10个视频，算下来每个用户平均停留3秒，压出来的视频流接口QPS特别漂亮。结果上线才发现，真实用户平均要在一个视频上停留15秒，很多人会点进作者主页翻往期作品，甚至会在评论区反复刷——这些路径带来的额外请求，压测的时候半毛钱都没覆盖到。上线当天视频流接口的实际负载是压测值的2.7倍，直接卡成PPT。
说穿了，场景设计的核心从来不是“覆盖所有接口”，是“还原真实的流量权重”。你得拿着生产环境过去3个月的用户行为日志，把每个接口的调用占比、跳转顺序、用户分层的行为差异全抠出来，而不是拍脑袋给每个接口随便分配个流量值。
数据构造才是压测结果的命门
老周他们那次压测，除了流量占比错了，最坑的就是数据。他们构造的100万条商品数据，库存全是100万，价格全是99块，用户手机号全是13800000000这种连号。压测的时候扣库存、查用户的接口快得飞起，结果上线的时候真实商品库存最多的也就几百件，扣库存的时候锁竞争直接把Redis打满；用户手机号是五花八门的真实号段，查用户的时候索引区分度极低，数据库查询耗时直接翻了5倍。
说实话，我第一次做压测的时候也踩过一模一样的坑。
数据构造绝对不能只看“有没有”，要看“像不像”。
你要模拟真实的数据分布：用户等级的占比，商品的价格区间，交易金额的分布，甚至要把数据的冷热比例算清楚——80%的请求打在最近3个月产生的热数据上，剩下20%打在半年以上的冷数据上，不能全把压测请求打在你刚批量插进去的那批假数据上，不然缓存命中率根本不准，压出来的结果比真实值好看一倍都不止。
还有个容易被忽略的点：压测数据一定要和生产数据的索引特征匹配。比如你构造的用户表，user_id全是连续自增的，按id查当然快，但真实生产里很多查询是按手机号、按用户等级筛选的，如果假数据里这些字段的取值高度重复，索引的区分度为0，压测的时候根本测不出真实的查询耗时。之前有个做内容社区的团队，压测的时候构造的用户关注列表全是空的，动态流接口压出来QPS特别高，上线的时候老用户平均关注了200个账号，动态流要关联查的表多了三倍，接口直接慢到5秒以上，那叫一个离谱。
别等压测上线才补窟窿
很多团队的压测流程特别割裂：开发写完代码扔给测试，测试照着去年的老脚本跑一遍，出个达标报告就准备上线，全程没人拉业务侧的人对齐。上次那个做直播电商的团队就是，压测的时候根本没考虑到直播场景会有几万人同时刷同一条商品链接，热点key的问题完全没覆盖，上线当天直播开始5分钟，Redis直接因为热点key打满了网卡，用户连商品详情都刷不出来。
不过话说回来，场景设计和数据构造本来就不是测试团队一个部门的事。你得拉上运营、产品甚至前端一起对：运营要告诉你上次大促哪个接口被刷得最狠，哪个活动会带来集中的热点数据；产品要告诉你不同路径的用户占比是多少；前端要记着把用户反复点提交按钮、滑动页面触发的重复请求也算进流量模型里。
别总觉得压测是为了给领导凑个好看的汇报数字。
真的不是。
你要是没真的站在用户角度想清楚他们会怎么用你的系统，会产生什么样的数据，那压测出来的所有数字，全是自嗨。等上线当天系统崩了，再想起当初压测的时候偷的懒，那时候再补，就晚了。