API接口吞吐量测试是评估被测系统在单位时间内成功处理API请求的最大能力。吞吐量 通常以每秒事务数（TPS）或每秒请求数（ RPS）来测评。本测试的目的是：确定关键API接口的性能容量极限，发现性能极限（如代码效率、数据库查询、外部依赖、基础设施限制），为系统扩容、性能优化及SLA（服务等级协议）的制定-提供精准稳定的数据。

api测试对象： 第三方网站系统中承担核心业务功能、高频访问或涉及复杂运算的API接口，例如：用户登录、商品查询、下单接口、支付回调、数据提交等。

api测试的需要测试的指标：

1.吞吐量 ： 系统在单位时间内处理的请求数量（RPS）或事务数量（TPS）。这是本次测试的直接指标。 一个“事务”可能包含多个请求。

2.并发用户数 ：在同一时间点向系统发出请求的虚拟用户数量。注意：高并发不一定产生高吞吐量。 如果系统存在瓶颈，那么增加并发用户数可能导致吞吐量下降和响应时间激增。

3.响应时间 ：从发送请求到接收到完整响应所花费的时间。通常关注平均响应时间、90%百分位数（P90）、95%百分位数（P95）等。响应时间应在可接受的范围内维持稳定。

4.错误率 ：在测试过程中，失败请求数占总请求数的百分比。高错误率（如>0.1%）是系统过载或存在Bug的标志。

5.资源利用率 ：测试期间系统服务器的CPU使用率、内存占用、磁盘I/O、网络I/O以及数据库连接数等。用于定位性能瓶颈的具体位置。

测试环境和测试工具准备

测试环境要求：

隔离性： 测试环境应尽可能与生产环境硬件配置、软件版本（操作系统、中间件、数据库）、网络架构保持一致。绝对禁止在生产环境直接进行压测。

数据独立： 使用独立且与生产环境数据量级、数据分布相似的测试数据库，避免污染生产数据-。

环境纯净： 测试环境没有其他无关作业运行，以减少干扰。

专业负载测试工具：

JMeter: 开源、Java-based，功能强大，社区支持好，可通过GUI设计测试计划或进行命令行压测，适合复杂的测试场景。

k6: 开源，基于JavaScript，专注于API性能测试，脚本编写更符合开发者习惯，适合CI/CD集成。

Gatling: 开源，基于Scala，高性能，报告详细，同样适合CI/CD集成。

商业工具： LoadRunner（功能全面，企业级）、NeoLoad等。

数据监控工具：

系统监控： Prometheus + Grafana（用于监控服务器CPU、内存、磁盘、网络等指标）。

应用监控： APM工具（如Azure Application Insights, 听云, Pinpoint）用于监控代码级性能，如慢SQL查询、函数执行时间等。

数据库监控： 监控数据库服务器的QPS、慢查询日志、连接数等。

测试过程

1.编写测试脚本： 使用选定的工具录制或编写API请求脚本，正确添加请求头（如 Authorization: Bearer <token>）、请求体（如JSON），并处理关联（如从登录响应中提取token用于后续请求）-。

2.基准测试 : 以较低的并发用户数（如5-10个）运行一段时间，验证脚本正确性并获取系统在低压力下的性能基线-。

3.负载测试 : 逐步增加并发用户数，模拟预期的正常和峰值负载，观察系统性能变化趋势，找到最佳性能区间-。

4.压力测试 : 继续增加负载，直至系统吞吐量达到峰值并开始下降（性能拐点），同时响应时间急剧上升或错误率飙升。压力测试的目的是找到系统的极限压力和薄弱位置-。

5.耐力测试 : 在系统能承受的压力水平下（如80%的最大吞吐量），持续运行数小时甚至数天，检查是否存在因内存泄漏、资源耗尽等问题导致的性能下降-。

6.阶梯增压 : 并发用户数随时间逐步增加，有助于观察系统在不同压力下的表现情况-。

7.恒定的并发: 保持固定的并发用户数运行，用于评估系统在稳定压力下的稳定性情况-。

API吞吐量测试不是一个简单的“跑个压测”任务，而是一个系统的工程。需要严谨的测试策略、合适的工具链、对系统架构的深入理解以-及精准的数据分析能力。