一.性能测试指标
1.系统吞吐量throughput
单位时间内系统的请求数目
在没有达到性能瓶颈时吞吐量和虚拟用户间存在一定的联系
F=VU*R/T——VU：虚拟用户数，R：每个用户发出的请求数，T：考察的时间
2.响应时间（系统延迟）
通常一个系统的性能受吞吐量和响应时间两个条件的约束，有以下两种场景
吞吐量越大，系统延迟越大，因为请求量过大，系统繁忙，响应速度降低
系统延迟越好，能支持的吞吐量就越高，因为响应速度快，因此能处理更多的请求
3.并发数
系统能够同时处理的请求数／事务数
4.QPS（TPS）
并发数／响应时间假定系统响应时间一致的情况下，并发数越大，QPS也越高；当并发数超过一定值（系统瓶颈）时，响应时间变慢，QPS降低
依赖于公司的监控系统，做接口压力测试时主要关注点在qps，响应时间以及准确率，并发数是要靠算的
二.jmeter接口测试
创建测试计划，添加线程组，在线程组里面添加HTTP请求，设置http请求详情（包括服务器IP和端口号，协议，方法，编码，请求方法，方法中的参数等），为http请求添加请求头，为了查看jmeter的运行结果，需要添加监听器（常用的有“查看结果树”和“聚合报告”）
如何使用csv文件实现参数化：添加配置元件CSVDataSetConfig
以下介绍一些配置项的概念
线程组管理：设置线程数，设置ramp_upperiod，设置执行测试的次数
线程组元件控制Jmeter运行测试时使用的线程数，每个线程会作为一个整体执行测试计划并完全独立于其他测试线程，多线程用来模拟到达服务器的同步连接；Ramp-upperiod告诉JMeter多久开始"ramp-up"选择的全部线程。如果使用10个线程，ramp-upperiod是100秒，那么JMeter用100秒使所有10个线程启动并运行。每个线程会在上一个线程启动后10秒（100/10）启动。如果有30个线程和一个120秒的ramp-upperiod，那么每个连续的线程会延迟4秒；修改jmeter的线程数会加快数据的生成速度。
你的硬件能力会限制你有效运行JMeter的线程数。它也会依赖于你服务器的速度（一个更快的服务器因为它更加快速的返回一个请求所以会使JMeter工作更加努力）。JMeter工作越多，它的时间信息就越不准确。JMeter做越多的动作，每个线程必须等待访问CPU的时间越长，定时信息越长。如果你需要大规模的负载测试，考虑在多个机器上运行多个非用户界面的JMeter。
这里需要明确并发的概念，曾经看到小伙伴在单机笔记本上发起了600个线程，这种情况下设置线程数过多资源不足负载机排队，另外请求数据在网络队列上也有排队，到达服务端也会排队，严格意义上的并发很难指定，如果不能达到性能测试的瓶颈，可以考虑增加机器
减少资源使用的一些建议：使用非用户界面模式：jmeter-n-ttest.jmx-ltest.jtl?尽可能少的使用监听器；如果使用-l标志??不要使用函数模式?使用CSV输出而不是XML?仅保存你需要的数据?尽可能少的使用断言
三.压力模拟工具
若为Java类接口且单机并发数控制在500内，则可选择Jmeter或者Loadrunner。
若为WebService类接口且单机并发数控制在500内，则可选择SoapUI或者Loadrunner。
若单机并发数超过500且控制在5000内，则可选择Loadrunner。
若单机并发数超过5000，则建议采用负载集群，即采用“中控（ControlCenter）+多机部署（LoadGenerator）”方案。
四.测试场景
1.系统达到**qps时的响应时间；
2.单个机器可以达到的qps；总的请求数不变，逐渐增加线程数（线程数越大，数据的生成速度越快，总的请求数不变，当qps不随线程数的增大而改变时，可以认为得到了结果值）
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
