转载：https://www.cnblogs.com/xiyozhang136/p/9633346.html
jmeter APP接口压力测试
第一步：获取开发文档，了解接口地址和参数名
第二步：jmeter中添加需要测试的接口
a.设计APP的接口框架：
b.http请求默认值设置如下：
- c.接口中应需要用到sign字段，加密字符串与时间戳，所以需要自己编写加密的代码。
在eclipse中编写需要加密的代码，调试成功后，在elipse中到处jar包
将导出的jar放到Jmeter安装目录下的lib文件夹下；
因为sign字段是由：时间戳+$+key加密而成，所以我们先需要获取时间戳：
因为所有接口中的sign规则相同，所以将需要的3个字段在测试计划中添加即可
添加完成后，在jmeter中添加beanshell Sampler，导入该jar包，将需要的字符串引用该方法即可,首先定义各个字符串，将字符串拼接后引用加密的方法，加密后的字符存到sign1中，设计如下：
在接口中引用该sign1字段：
d.接口的请求参数值需要从数据库中随机获取，那么设计如下：
添加JDBC Connection Configuration设置
再添加JDBC Request，首先需要将JDBC Connection Configuration中的
与jdbc Request中的
设置相同；然后将从数据库中获取需要的参数值，将所有的数据存储到result对象中，
在BeanShell中获取存储id值的对象，并随机读取
在请求参数中引用，sign与times获取方式如上设置一致，id的字段即从数据库中随机获取的值；
调试无问题后，设置查看结果：
监控测试的服务器需要用PMC
在测试服务器中加入
在测试服务器中linux服务器上首先将startAgent.sh设定为可执行文件：
启动服务后，再进行压力测试。
因为压力测试，需要分布式压力测试：
e.点击“全程启动”进行压力测试，再对结果进行分析：
聚合报告分析
- Label：httpRequest name属性值。
- Samples：测试的过程中一共发出了多少个请求即总线程数，（如果模拟10个用户，每个用户迭代10次，这里就显示100），对应图形报表中的样本数目。
- Average：单个Request的平均响应时间，计算方法是总运行时间除以发送到服务器的总请求数，对应图形报表中的平均值。
- Median：50%用户的响应时间。
- 90%Line：90%用户的响应时间。
- Min：服务器响应的最短时间。
- Max：服务器响应的最长时间。
- Error%：本次测试中出错率，请求的数量/请求的总数。
- Throughput：吞吐量，默认情况下表示每秒完成的请求数。
- KB/Sec：每秒从服务器接收到的数据量，即每秒钟请求的字节数，时间单位均为ms。
根据聚合报告以及图形结果各项参数指标分析
（1）每间隔一秒钟并发的线程数越多，接口99%Line参数值先增加后减小，多少个线程时基本达到峰值；
（2）每间隔一秒钟并发的线程数越多，吞吐量先减后增，每秒钟完成的请求数减幅较大。
据图形结果分析
（1）随着发送到服务器的请求数越来越多，偏离数量越来越大，服务器越来越不稳定；
（2）发送到服务器的请求数增加，吞吐量（即服务器每分钟处理的服务器的请求）先减少后增加。
一般情况下，当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间
得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的
响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟
透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。
第一步：获取开发文档，了解接口地址和参数名
第二步：jmeter中添加需要测试的接口
a.设计APP的接口框架：
b.http请求默认值设置如下：
- c.接口中应需要用到sign字段，加密字符串与时间戳，所以需要自己编写加密的代码。
在eclipse中编写需要加密的代码，调试成功后，在elipse中到处jar包
将导出的jar放到Jmeter安装目录下的lib文件夹下；
因为sign字段是由：时间戳+$+key加密而成，所以我们先需要获取时间戳：
因为所有接口中的sign规则相同，所以将需要的3个字段在测试计划中添加即可
添加完成后，在jmeter中添加beanshell Sampler，导入该jar包，将需要的字符串引用该方法即可,首先定义各个字符串，将字符串拼接后引用加密的方法，加密后的字符存到sign1中，设计如下：
在接口中引用该sign1字段：
d.接口的请求参数值需要从数据库中随机获取，那么设计如下：
添加JDBC Connection Configuration设置
再添加JDBC Request，首先需要将JDBC Connection Configuration中的与jdbc Request中的
设置相同；然后将从数据库中获取需要的参数值，将所有的数据存储到result对象中，
在BeanShell中获取存储id值的对象，并随机读取
在请求参数中引用，sign与times获取方式如上设置一致，id的字段即从数据库中随机获取的值；
调试无问题后，设置查看结果：
监控测试的服务器需要用PMC
在测试服务器中加入
在测试服务器中linux服务器上首先将startAgent.sh设定为可执行文件：
启动服务后，再进行压力测试。
因为压力测试，需要分布式压力测试：
e.点击“全程启动”进行压力测试，再对结果进行分析：
聚合报告分析
- Label：httpRequest name属性值。
- Samples：测试的过程中一共发出了多少个请求即总线程数，（如果模拟10个用户，每个用户迭代10次，这里就显示100），对应图形报表中的样本数目。
- Average：单个Request的平均响应时间，计算方法是总运行时间除以发送到服务器的总请求数，对应图形报表中的平均值。
- Median：50%用户的响应时间。
- 90%Line：90%用户的响应时间。
- Min：服务器响应的最短时间。
- Max：服务器响应的最长时间。
- Error%：本次测试中出错率，请求的数量/请求的总数。
- Throughput：吞吐量，默认情况下表示每秒完成的请求数。
- KB/Sec：每秒从服务器接收到的数据量，即每秒钟请求的字节数，时间单位均为ms。
根据聚合报告以及图形结果各项参数指标分析
（1）每间隔一秒钟并发的线程数越多，接口99%Line参数值先增加后减小，多少个线程时基本达到峰值；
（2）每间隔一秒钟并发的线程数越多，吞吐量先减后增，每秒钟完成的请求数减幅较大。
据图形结果分析
（1）随着发送到服务器的请求数越来越多，偏离数量越来越大，服务器越来越不稳定；
（2）发送到服务器的请求数增加，吞吐量（即服务器每分钟处理的服务器的请求）先减少后增加。
一般情况下，当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间
得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的
响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟
透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。