接口性能测试：Postman与Fiddler双剑合璧

性能测试是针对接口来进行测试的。使用接口管理工具来进行测试

postman
抓包工具 fiddler

性能测试是一个很大的范围，可对前端，可对后端，可对网络等等。性能调优时面试官最喜欢问的问题

但是项目里面的性能问题目前是很难解决的

性能测试需要集群，高并发，但是我们的电脑，我们的服务器不能支持这样的操作，随便一下我们的电脑就废了，无法支持这种高并发调优

纸上谈兵

功能测试在前（保证功能没有问题），性能测试在后

简历上只能写：了解，会性能测试，不能太狂妄，要谦虚

什么是性能测试

五菱宏光和法拉利

功能：都是车，都能开，都能载人...

性能：人造皮和真皮、百米加速十几秒和几秒...

概念：为了发现系统性能问题或获取系统性能相关指标而进行的测试

评估性能好或不好，会有一个指标来评估

一个人好不好：看面相/看身高/看性格/看内涵...

常见性能测试指标

并发数

并发用户数

从业务层面看，并发用户数指的是实际使用系统的用户总数

从后端服务器层面看，指的是 web 服务器在一段时间内处理浏览器请求而建立的 http 连接数或生成的处理线程数

案例：一个已经投入运行的系统，有 5000 人使用，但只能同时 2500 人使用，用户分别进行浏览页面、填写订单、提交订单... 等等操作

那么这个系统的业务并发数是 2500，实际并发用户数是提交订单和查询订单操作的用户

吞吐量

单位时间内处理的并发数（每一秒有多少并发数）

直接一线软件系统负载承受能力
吞吐量越高，系统承受的并发越多，性能越好

案例：有 AB 两种场景

A：有 100 个并发用户，每个用户每隔 1 秒发出一个请求

B：有 1000 个并发用户，每个用户每隔 10 秒发送一个请求
AB 吞吐量一样，都是每秒处理 100 个请求。但是 A 场景思考时间短，所以占用的系统资源更多（请求太密集了，系统太累了）

TPS

transaction per second：每秒处理事务数

用于衡量系统在一定时间内能够处理的事务数

计算公式：总的请求成功的事务数 / 总的运行时间

举例：某一系统 1 分钟处理 1000 个业务，那么 TPS=1000/0=16.7
举例：2026 年最高的一天有 10 万笔交易，预测 2023 年 TPS 需要多少合格？
- 理论 TPS = 100000 / 24_60_60 = 1.2（理想状态），然而实际上订单量会在某段时间内突然增加，并不是平均到每个时间段内，因此
  1. 没有更详细的数据：根据二八定律（80% 的事务在 20% 的时间内完成）TPS = 100000 * 0.8 / 24 * 60 * 60 * 0.2 = 4.6
  2. 如果有详细的数据：5 万笔交易在晚上的 8~9 点完成的
    TPS = 50000 / 60 * 60 = 13.9（实际还要参考往年业务的增长，假设每年业务增长 30%，则 TPS = 50000 + 50000 * 0.3 / 60 * 60 = 18）

一般来说，吞吐量越大，性能越好

QPS

query per second 每秒查询率

若一个事务中只有一个接口且是查询接口，则 QPS=TPS

响应时间

验证系统处理快不快

应用系统从请求发出开始，到客户端接收到最后一个字节数据所消耗的时间

对于 web 系统而言，系统响应时间包含前端展现时间和系统响应时间

前端响应时间：页面渲染时间
后端响应时间：包含服务器、数据库、通讯网络等响应时间

并发数量、系统吞吐量、系统响应时间之间的关系

当并发用户较少，系统吞吐量低，系统响应时间较短，我们认为系统处于空闲区间
随着系统并发用户增加，系统吞吐量开始呈线性增长，系统进入了线性增长区间

当达到拐点，此时并发数达到最大。从这个并发数开始，继续增加并发数，将给系统造成压力，系统表现开始变差

系统处理不过来了，但是并发还在增加，响应时间开始增加，吞吐量随之降低

系统性能的拐点通常是性能测试的主要目的之一

资源利用率

有没有把 cpu 打满，有没有把内存打满...

通过查看系统占用的情况分析资源瓶颈

服务器：cpu、内存、磁盘、网络等

性能测试关注点

不同的角色看待性能测试的侧重点不同

前端：如果资源大，客户端渲染时间就会久
后端：避免全表查询，耗时非常久

性能测试分类

基准测试

例子：对电商网站首页做单用户访问测试，记录从打开页面到完全加载完成的时间、服务器 CPU 占用、内存使用等数据。
总结：在单用户低压力下，摸清系统 "基础性能底线"，为后续多用户并发测试提供参考对照。

并发测试

例子：模拟 100 个用户同时点击 "提交订单" 按钮，测试系统是否会出现订单重复提交、库存数据错乱、数据库锁等待超时等问题。
总结：验证多用户同时操作时，系统的性能表现与并发下的稳定性，提前发现资源争用、数据不一致等隐患。

负载测试

例子：逐步从 100、500、1000... 增加并发用户数访问电商秒杀页面，直到页面响应时间超过 3 秒（安全临界值），最终确定系统在响应时间≤3 秒时，最多能承载 800 个并发用户。
总结：通过逐步加压，找到系统在满足性能要求下的最大负载，获取系统峰值处理能力。

压力测试

例子：电商大促时，先按负载测试找到系统在响应时间≤2 秒下的最大承载 1 万用户，再继续加压到 2 万、3 万用户，观察到 3 万用户时系统崩溃，同时发现高负载下的内存泄漏、数据库同步问题。
总结：在超出预期负载或资源不足的条件下，逐步加压让系统资源饱和甚至失效，找出高负载下才暴露的缺陷，找到性能拐点，确定系统极限服务能力，用于性能诊断、调优和容量规划。

稳定性测试

例子：在确定系统可承载 800 个并发用户（响应时间≤3 秒）后，让系统持续运行 3 * 24 小时，期间保持 800 个并发用户访问，监测是否出现内存泄漏、服务宕机、响应时间逐渐变长等问题。
总结：在负载测试确定的安全负载基础上，长时间（通常 3 * 4 小时以上）运行系统，验证系统在持续压力下的稳定性，发现长时间运行才会暴露的问题。

假设你要为「618 大促」做电商平台性能测试，完整流程如下：

基准测试（单用户打底）

场景：

选大促核心业务：商品详情页、提交订单、支付
每个业务只模拟1 个用户操作，记录：
- 商品详情页：打开时间、服务器 CPU / 内存、接口响应时间
- 提交订单：接口耗时、数据库写入耗时
- 支付：第三方支付接口调用耗时
  
  作用：拿到系统 "单用户性能基线"，比如商品详情页单用户打开耗时 0.5 秒，为后续多用户测试做对照。

并发测试（查并发隐患）

场景：

模拟200 个用户同时点击 "提交订单"，同时操作同一件商品库存
观察：是否出现库存扣减错乱、订单重复、数据库死锁、接口超时

作用：提前发现并发下才会暴露的问题（比如多用户抢同一件商品时的数据不一致），保证大促时数据不乱。

负载测试（找安全最大负载）

场景：

逐步增加并发用户数：100 → 500 → 800 → 1000...
要求：响应时间 ≤ 3 秒、错误率 ≤ 0.1%
结果：当并发到800 用户时，响应时间刚好 2.8 秒；超过 800 后，响应时间 > 3 秒

作用：确定系统在满足性能指标下的最大安全负载（800 并发），作为大促日常峰值的容量依据。

压力测试（探系统极限）
场景：

在负载测试基础上，继续加压：900 → 1500 → 2000 → 2500 用户
观察：
- 1500 用户：响应时间 5 秒，开始出现内存泄漏
- 2500 用户：系统崩溃，无法响应
  
  作用：找到系统性能拐点和极限（最多扛 2500 用户），知道大促超峰值时系统会怎么崩，提前做容量规划（比如加机器）。

稳定性测试（验长期可靠）

场景：

用负载测试确定的800 并发用户 （安全负载），持续运行3*24 小时
监测：响应时间是否逐渐变长、内存是否持续上涨、服务是否宕机

作用：验证系统在持续压力下的稳定性，发现长时间运行才暴露的问题（比如内存泄漏慢慢累积导致宕机）。