1.普通性能场景：

线程数：模拟并发用户数；jmeter本身对线程数无限制，受到电脑CPU的主频限制，http协调脚本线程数大概1500左右，最大2000（部分产不出来）模拟大于几千，考虑–分布式

ramp-up时间：启动所有线程数时间（如：5s内启动完1000个线程），时间结束后，所有线程数产生（合理范围设置），是否平均时间产生，不一定（有可能1s全部产生），启动时间内，一产生就会发起请求，不是全部产生一起请求（并发数不准）；广义并发：同一时间发起不同接口

线程数与ramp-up设计：500以内并发数，2-3s;500-1000并发数，5s;>1000并发数，5-8s；ramp-up时间在总的时间内占比不能太大（一个接口性能测试通常几分钟，几十分钟不需要太长）

循环次数：默认大于等于1 ，每个并发数执行的次数，勾选“永远”，一直循环，直到点击停止，与“调动器配置”一起使用；调动器：持续时长–在规定时间内一直发送请求，直到时间结束

报告：可用--聚合报告分析

2.压力测试（一定性能压力，查看服务器各项性能指标）

并发数--总并发数的20%-80%之间；时长--几十秒，几十分钟，无需太长

3.负载测试（逐渐增加并发数，获取最大拐点区间：阶梯性能场景（步长相同/步长不同））

增加步长可以相同，可以不同，相同只是一个特殊条件

 步长相同:jp@gc - Stepping Thread Group (deprecated)           步长不同：jp@gc - Ultimate Thread Group

 设计原则： 缓起步，快结束（结束时间过长，导致TPS准确率低）      + 快结束： 并不是瞬间结束

 报告：jp@gc - Transactions per Second   ---TPS；jp@gc - Response Times Over Time  ----响应时间，根据平均时间（不再增加可估算最大并发数，结合TPS图）；jp@gc - Active Threads Over Time   --监听单位时间内的线程数

4.面向目标场景（指定达到多少TPS/指定达到多少人）

需求： 期望我项目的接口，都要能满足50tps：Arrivals Thread Group ---达到多少TPS,每秒请求多少次数，通过该线程组达到控制请求数的目的

 需求：要做一个**秒杀**， 能支持1000个人同时，秒杀，我们的系统不能奔溃；Concurrency Thread： 达到多少人   并发数

5.混合场景（不同数量的并发用户数，向不同接口发起请求）

混合场景： **不同数量的并发用户数，向不同接口发起请求**---这种才是真正的混合场景，才真正符合企业产品实际情况

    + “假”混合场景：在一个线程组中，添加逻辑控制器，控制我们脚本的运行，这种，是把脚本混合了， 但是于生产的情况还是有差异。
                 + 会用到前面讲的什么技术
                 + 跨线程组传参
                 + 线程组1 40
                 + 线程组2 20
                 + 线程组3 10

                注册-登录-下单
  1. 时间规律场景（特定时间并发数多，特定时间并发数少，如：美团）

注意：在做性能测试时，不要连续去执行性能测试，在前一轮性能测试结束的时候，要休息一会，等待服务器的压力释放，再开始下一轮性能测试，不然，因为前面的性能测试导致服务器压力过大，未释放，从而影响后续性能测试结果。

7.报告分析

1.网络瓶颈，并发数不变场景
  聚合报告/汇总报告（ TPS = 总事务所/并发数/并发时间）

 2.并发数变化场景

  jp@gc - Transactions per Second   ---TPS

  jp@gc - Response Times Over Time  ----响应时间，根据平均时间（不再增加可估算最大并发数，结合TPS图）

  jp@gc - Active Threads Over Time   --监听单位时间内的线程数

3.节省jmeter自身消耗，不使用各种报告取样器，导出HTML报告

    1）查看结果树：输出jtl文件                                                                                                
    2）借助jmeter：.Tools：Generate HTMLreport :进行数据转换（out putdirectory：输出文件夹必须为空 ）