大促前最让人发愁的，是测完了也说不清系统到底能扛多少。阿里云 PTS 能帮忙录脚本、跑压力，但脚本录完之后，真正卡住人的是怎么判断容量。
很多系统平时运行平稳，一到大促、活动或热点事件就出问题。接口超时、数据库连接耗尽、缓存击穿，往往都是真实流量压上来才暴露。压测的意义就在于提前找出这些问题，让扩容多少、限流设在哪里有数字可依。
传统做法是自建 JMeter 集群，自己维护压力机、配置网络、汇总报告。这套方式灵活，但人力和运维成本不低。阿里云PTS（Performance Testing Service）是云端性能测试服务，压力机、分布式调度和报告分析都托管在云上，测试人员可以把精力放在场景设计和结果解读上。
PTS 覆盖的四个环节
用下来，PTS 大致覆盖四个环节，每个环节的注意点也不同。
- 脚本创建，可以导入已有的 JMeter 脚本，也能通过录制生成 HTTP/HTTPS 请求，从零写脚本的门槛低了。录完后要检查请求是否带齐登录态和签名，否则压的可能是错误路径。
- 场景编排，并发模式和 RPS 模式都能选，还能设置阶梯加压、峰值保持、逐步降压等流量曲线。曲线要贴近业务实际，否则结果只能说明机器在某种假设下的表现。
- 分布式压测，压力节点由平台按需调度，可以从不同地域发起请求，访问分布更接近真实用户。
- 实时监控与报告，测试过程中能看到 TPS、响应时间、成功率的变化，结束后生成详细报告，便于定位瓶颈。
对于已经接入阿里云监控体系的系统，PTS 的压测数据可以和应用监控放在一起看。压测时同步盯着服务端的 CPU、线程池和数据库慢查询，就能判断瓶颈在应用层还是存储层。如果只看压测工具给出的响应时间，很容易把排队问题误判成计算问题。
实战案例：电商大促前的容量评估
某中型电商团队要在大促前验证订单链路的承载能力。核心链路包括商品查询、加入购物车、下单和支付回调，峰值目标是单秒三千笔下单请求。
第一步，按用户行为组合场景，不逐个接口加压
团队没有对每个接口单独加压，而是按真实用户行为设计组合场景。浏览商品占六成，加购占两成五，下单占一成，支付回调占半成。这样能暴露接口之间的资源争抢。单独压下单接口时一切正常，并不代表浏览和加购挤占连接池之后，下单链路依然稳定。
第二步，录完脚本后先做数据参数化
团队先用录制功能生成基础脚本，再把用户 ID、商品 ID、库存参数改为从 CSV 文件读取。如果所有请求都命中同一条数据，缓存会一直处于热状态，测出来的响应时间会比线上好看，这种结果没有参考价值。脚本里还加入了签名和 token 刷新逻辑，保证压测请求与线上一致。这一步容易被跳过，但脚本能跑通，不代表请求像真实用户发出的。
第三步，阶梯加压，盯住拐点
测试采用阶梯方式，每五分钟提升一次压力，重点观察响应时间从哪里开始拐弯。压力到约两千二百 QPS 时，下单接口的 P99 响应时间明显上升，数据库连接池等待时间也随之增加。顺着监控往下查，问题出在库存扣减的同步锁上。
团队随后将库存扣减改为预扣减加异步校验，并调整连接池参数。复测时，三千 QPS 下的 P99 响应时间回落到可接受范围内。从脚本准备到复测完成，整个过程约三天，比之前靠人工协调压力机快了不少。
使用建议
- 压测前先和业务方对齐流量模型。场景没对上，数字再精确，也回答不了大促会不会出事。
- 压测对象必须是测试环境，或已获得授权的系统。压到第三方接口上，影响的不只是自己。
- 脚本里的数据要参数化，测完要清理测试数据，避免污染生产库。
- 每次只改一个变量，前后结果才有对比价值。
PTS 适合需要快速搭建压测能力、又不想长期维护压力集群的团队。把它当作容量规划和发布前验证的常规步骤，风险就能在大促之前暴露，而不是等线上出事再补救。
