测试人 Skill 全家桶 · 第⑤篇前四篇我们走完了功能侧的一条线拆点 → 出用例 → 接口自动化 → UI 自动化。 这一篇讲那个总被临时抓来、又最容易糊弄的活儿——性能测试。 它的价值不在于跑了个脚本而在于给业务一个能拍板的答案。一、大促前三天老板问你那句话【贴图 01】大促前三天老板在群里 你「咱们系统能扛住当天流量吗」你手上有一份性能测试报告——是上个月临时被抓去压的。翻开一看最显眼的一行是平均响应时间183 ms然后呢能扛多少拐点在哪瓶颈在哪多花一台机器能多扛多少你答不上来。因为那份报告从一开始就只回答了跑得动没回答能扛多少。【贴图 02】性能测试最大的误区就是把它当成跑一遍、出个数。真正的性能测试永远在回答三个问题在什么条件下多少并发、什么业务配比能扛多少TPS / 容量水位且不超 SLA瓶颈在哪客户端 / 网络 / 服务端 / 数据库 / 下游一份说不出能扛多少、卡在哪的报告不是结论是免责声明。而这恰好是性能测试值钱的地方——它是测试领域里薪资溢价最高、最稀缺的方向之一^1。因为它要的不是会点工具是能对系统下判断。二、第一原则没有 SLA不开压【贴图 03】压测最怕的场景是先压了再说。跑完一堆曲线然后呢——没有标准你连过没过都不知道。所以第一步永远是和业务把 SLA 谈清楚。SLA 至少包含四个量|指标|含义|例子|| — | — | — ||TPS|每秒处理的事务数|目标 800 TPS||P95 响应时间|95% 请求的耗时上限|P95 500ms||错误率|失败请求占比| 0.1%||并发数|同时在线的虚拟用户|500 并发|一句话没有 SLA 不做压测。否则你压的不是系统是自己的时间。这张 SLA 表其实不用现抄——场景表、报告模板、那条瓶颈定位决策树我都整理进了文末那份《性能测试落地手册》。三、第二原则场景要像真人不是锤接口【贴图 04】新手压测最爱干一件事逮住一个接口死命地打。这不是性能测试这是压力攻击。真实的用户是有节奏的浏览、加购、下单之间有思考时间不同业务的访问配比也不一样100 个人里可能 80 个在看、15 个在买、5 个在支付。所以场景要建模至少四种基准测试单用户摸清基线负载测试目标并发验证 SLA压力测试逐级加压找拐点性能开始急剧下降的那个点^5稳定性测试7×24 长时间跑看内存泄漏 / 连接泄漏。【贴图 05】还有个隐形杀手数据不真实。用同一批 ID 反复压缓存全命中成绩好看得离谱——上线就现原形。压测数据必须唯一、可清理、贴近真实分布。四、第三原则只报平均值等于没报【贴图 06】这是性能测试里最坑人的一行“平均响应时间 183ms”。平均值会骗人——它被大量快的请求拉低了而用户真正骂街的是那 5% 慢到爆的请求。所以指标必须看分位数 拐点 水位P95 / P99P95 500ms 才叫95% 的请求是好的拐点TPS 到某个点后不升反降、响应时间陡增那就是容量上限容量水位结论要写成P95500ms 时能支撑 800 QPS而不是服务正常。只报平均值的报告等于没报。必须给 P95 / P99。五、第四原则没有监控的压测不算性能测试【贴图 07】最容易被忽略、也最致命的一条压测时必须同时采集服务端资源——CPU、内存、GC、数据库连接池、线程池、下游依赖延迟。为什么因为没有资源监控你只知道慢永远不知道为什么慢。一个是应用 CPU 打满、一个是数据库连接池等待、一个是 GC 频繁——三种慢优化方向完全不同。【贴图 08】定位瓶颈时按这条链路逐段排除客户端(压测机)→ 网络 → 服务端(应用/中间件)→ 数据库 → 下游依赖先确认不是压测机自己先撑不住这是新手最常见的乌龙再往内看。相关工具与方法可参考 JetGuide 的性能测试入门整理^7与 ThoughtWorks 的性能测试指南^8。六、同一个接口裸问 vs 用 Skill【贴图 09】拿一个再普通不过的需求「给下单接口做性能测试目标 P95 500ms」。裸问 AI 给的看着专业其实空用 JMeter 起 100 个线程循环 10 次跑完看一下聚合报告的平均值。问题没有 SLA 对比、没有拐点、没有资源监控、用平均值下结论、没提数据造数。跑完你还是答不上能扛多少。用「性能测试 Skill」给的节选目标定义TPS 800 / P95 500ms / 错误率 0.1% / 并发 500场景建模基准 / 负载 / 压力 / 稳定性 四张场景表含思考时间 业务配比脚本与数据参数化、唯一数据、可清理梯度加压逐级加压找到 TPS 拐点指标采集TPS、P50/P95/P99、错误率 服务端 CPU/内存/GC/连接池瓶颈定位区分客户端 / 网络 / 服务端 / DB / 下游报告结论“P95500ms 时支撑 X QPS瓶颈在数据库慢查询建议加索引 / 缓存”。前者是我压过了后者是我能拍板了。七、这个 Skill 长什么样工作流程7 步① 目标定义与业务确认 SLATPS/P95/错误率/并发 ② 场景建模基准 / 负载 / 压力 / 稳定性 ③ 脚本与数据参数化、唯一数据、真实业务配比 ④ 梯度加压逐级加压找拐点 ⑤ 指标采集TPS、RT(P50/P95/P99)、错误率、资源 ⑥ 瓶颈定位客户端/网络/服务端/DB/下游 ⑦ 报告容量水位 拐点 结论 下一步动作检查清单核心资产· 有没有明确的 SLA没有 SLA 不开压 · 场景是否含思考时间与业务配比不是锤接口 · 压测数据是否唯一且可清理避免缓存命中失真 · 是否同时采集服务端资源否则只看到「慢」看不到「为什么慢」 · 压测环境配置是否与生产对齐 · 是否区分了客户端瓶颈与服务端瓶颈 · 结果是否给出拐点与容量水位 · 结论是否可执行扩容 / 优化 SQL / 加缓存 / 限流这份清单已做成一张可打印的速查卡手册里还有可填空的场景表和报告模板。硬性规则没有 SLA 不做压测 / 没有监控不算性能测试 / 必须给 P95P99 / 生产压测须审批并有限流预案。反模式❌ 只跑一轮就下结论 ❌ 忽略 DB 和下游 ❌ 用平均值判断好坏。八、落地效果 踩过的坑效果团队自测仅供参考每轮压测都能输出一句可执行的结论能扛多少 / 卡在哪 / 怎么办大促前的容量评估从拍脑袋 加班变成按 SLA 交答案因为提前发现数据库慢查询 / 连接池不足避免了至少两次高峰期事故。四个坑一定要看AI 爱只压一个接口——必须显式要求含思考时间和业务配比AI 爱用平均值——明确要求输出 P95 / P99否则一律打回忘了压测机自己也是瓶颈——先看压测机 CPU/网络再怪服务端结论不可执行——报告最后一定要落到扩容 / 优化 SQL / 加缓存 / 限流这种动作上。** 彩蛋这期加料了**公众号后台回复「skill」领取《测试人 Skill 全家桶》加料版10 个 SKILL.md 10 张速查卡可打印《性能测试落地手册》SLA 模板 / 场景表 / 报告模板 / 决策树《能力自检 2026 面试高频》 资料总目录。 下篇预告《缺陷复盘为什么同一个坑你们会踩三次》—— 功能、自动化、性能都讲完了。下一篇回到最人的环节一个线上故障复盘怎么从谁的锅走到下次不会再犯。