接口性能测试

一.性能测试指标
在用jmeter做性能测试之前，首先要回顾下性能测试的关键指标

1.系统吞吐量 throughput

单位时间内系统的请求数目

在没有达到性能瓶颈时吞吐量和虚拟用户间存在一定的联系

F=VU * R /T ——VU：虚拟用户数，R：每个用户发出的请求数，T：考察的时间

2.响应时间（系统延迟）

通常一个系统的性能受吞吐量和响应时间两个条件的约束，有以下两种场景

吞吐量越大，系统延迟越大，因为请求量过大，系统繁忙，响应速度降低

系统延迟越好，能支持的吞吐量就越高，因为响应速度快，因此能处理更多的请求

3.并发数

系统能够同时处理的请求数／事务数

4.QPS（TPS）

并发数／响应时间 假定系统响应时间一致的情况下，并发数越大，QPS也越高；当并发数超过一定值（系统瓶颈）时，响应时间变慢，QPS降低

依赖于公司的监控系统，做接口压力测试时主要关注点在qps，响应时间以及准确率，并发数是要靠算的

二.jmeter接口测试
创建测试计划，添加线程组，在线程组里面添加HTTP请求，设置http请求详情（包括服务器IP和端口号，协议，方法，编码，请求方法，方法中的参数等），为http请求添加请求头，为了查看jmeter的运行结果，需要添加监听器（常用的有“查看结果树”和“聚合报告”）

这里不再重复赘述：可参考其余教程

如何使用csv文件实现参数化：添加配置元件CSV Data Set Config

以下介绍一些配置项的概念

1.线程组管理：设置线程数，设置ramp_up period，设置执行测试的次数

线程组元件控制Jmeter运行测试时使用的线程数，每个线程会作为一个整体执行测试计划并完全独立于其他测试线程，多线程用来模拟到达服务器的同步连接；Ramp-up period告诉JMeter多久开始"ramp-up"选择的全部线程。如果使用10个线程，ramp-up period是100秒，那么JMeter用100秒使所有10个线程启动并运行。每个线程会在上一个线程启动后10秒（100/10）启动。如果有30 个线程和一个120秒的ramp-up period，那么每个连续的线程会延迟4秒；

修改jmeter的线程数会加快数据的生成速度。

你的硬件能力会限制你有效运行JMeter的线程数。它也会依赖于你服务器的速度（一个更快的服务器因为它更加快速的返回一个请求所以会使 JMeter工作更加努力）。JMeter工作越多，它的时间信息就越不准确。JMeter做越多的动作，每个线程必须等待访问CPU的时间越长，定时信 息越长。如果你需要大规模的负载测试，考虑在多个机器上运行多个非用户界面的JMeter。

这里需要明确并发的概念，曾经看到小伙伴在单机笔记本上发起了600个线程，这种情况下设置线程数过多资源不足负载机排队，另外请求数据在网络队列上也有排队，到达服务端也会排队，严格意义上的并发很难指定，如果不能达到性能测试的瓶颈，可以考虑增加机器

减少资源使用的一些建议：   使用非用户界面模式：jmeter -n -t test.jmx -l test.jtl  尽可能少的使用监听器；如果使用-l标志     不要使用函数模式   使用CSV输出而不是XML  仅保存你需要的数据   尽可能少的使用断言

三.压力模拟工具
 若为Java类接口且单机并发数控制在500内，则可选择Jmeter或者 Loadrunner。
 若为WebService类接口且单机并发数控制在500内，则可选择SoapUI或者Loadrunner。
 若单机并发数超过500且控制在5000内，则可选择Loadrunner。
 若单机并发数超过5000，则建议采用负载集群，即采用“中控（Control Center）+ 多机部署（Load Generator）”方案。
以上仅代表个人理解
四.测试场景

1. 系统达到 **qps时的响应时间；
   2.单个机器可以达到的qps ；总的请求数不变，逐渐增加线程数（线程数越大，数据的生成速度越快，总的请求数不变，当qps不随线程数的增大而改变时，可以认为得到了结果值）

---

作者：for_choc
来源：CSDN
原文：https://blog.csdn.net/for_choc/article/details/79079947
版权声明：本文为博主原创文章，转载请附上博文链接！