一、5 个核心判断维度
1. 业务访问量维度（并发 / 流量）
高并发场景：短时间大量用户同时操作，比如秒杀、抢券、登录高峰期、报表查询、批量提交。
大流量入口：首页、商品列表、搜索、查询接口，日均 PV/UV 很高。
批量数据处理：大数据导入导出、批量同步、定时任务、消息大批量消费。
简单判断：预估峰值 QPS 高、瞬时流量会暴涨，必须性能测试。
2. 业务影响程度维度（故障代价）
核心主链路业务：出性能问题直接导致业务不可用，会造成资金损失、用户投诉、业务瘫痪。
例：下单支付、订单创建、支付回调、登录鉴权、扣款。
对外提供的 API：给第三方、其他系统调用，超时卡顿会影响上下游整个链路。
高可用要求业务：生产不能接受超时、卡顿、雪崩，对稳定性要求高。
反之：后台内部极少使用的管理功能，就算慢一点，影响很小，可以不做。
3. 数据量级维度（数据量随时间膨胀）
业务数据会持续增长：比如订单查询、历史账单、大数据分页查询。少量数据跑没问题，数据量大后就会变慢、数据库慢 SQL、索引失效。
涉及大对象、大文件：大文件上传下载、大报表导出。
很多功能功能测试没问题，但是数据量上来性能直接崩盘，这类场景必须做性能。
4. 非功能需求 & 约束条件
需求文档有明确性能指标：响应时间、TPS、并发数、吞吐量、错误率。
例如：登录接口 200 并发，响应时间 < 200ms；下单 TPS500。
架构变更：数据库切换、中间件升级、接口重构、微服务拆分、缓存改造，核心链路需要性能验证。
资源约束：服务器 CPU、内存、数据库连接池、带宽有限，要验证系统在资源上限下能不能扛住压力。
5. 用户体验视角
用户对响应速度敏感：用户不能接受长时间等待。
比如搜索、商品查询，如果页面加载 3‑5 秒，用户直接流失，需要性能测试。
后台管理员低频操作，等待 5‑10 秒可接受，可不测。
二、典型必须做性能测试的业务场景
用户核心交易链路：登录、下单、支付、退款、库存扣减
流量入口：首页、列表页、搜索查询
营销活动：秒杀、抽奖、优惠券、大促场景（瞬时大流量）
批量操作：批量导入导出、批量审批、大数据报表
第三方对接接口、内部核心 RPC 调用链
定时任务、消息队列大批量消费任务
历史数据查询、分页查询（千万级数据表）
架构大版本变更后的核心业务
三、一般不需要专门性能测试的场景
使用频率极低的后台管理功能，日均访问个位数，就算慢一点不影响业务；
纯内部工具，仅开发运维人员使用；
简单一次性操作，没有并发，数据量很小；
注意：不是完全不管，只要做功能测试观察是否明显卡顿即可，不需要压测。
注意：即使不做完整性能测试，也建议做简单的基准测试，知道接口正常的响应水平。
400-035-7887
sales@spasvo.com
