文件上传功能测试、性能测试解决方案（含Jmeter配置及加压参数分析）

一、背景和测试用例

上传是每个系统非常常见的功能，但是多半时候开发、测试容易忽略很多细节，测试虽不可穷尽，但前人踩过的坑、我们踩过的坑，坚决不能再出第二次。看到一篇博客考虑的很全面，拿来主义了，感谢博主。

测试用例参考：https://blog.csdn.net/u011159607/article/details/80144142

二、上传接口jmeter配置

其余同普通接口的配置，区别主要体现在文件这里的配置，可以参考下图

 

 

三、个人对上传接口的压力测试过程和一点体会

尝试对一个上传接口进行了逐步加压测试，主要改变线程数量、循环次数，ramed up periods in seconds，初步得到这样的结论：

1、线程数量对性能的影响最为直接，比如10个、20个、40个、100个，最初尝试10个、100个，100个等了约1小时仍没完全处理完毕，任务在jmeter中挂掉了，看日志提示内存溢出，看报告成功了10多个；后尝试同时开20个线程，成功14-17个，没有全成功，之后尝试40个，同样是成功10几个，基本上可以得出上限是10几个；同时还有一点，压到瓶颈了之后，再继续加压的意义其实也就不大了，附图，里面可以看到，无论线程数量如何加压，成功的数量都是在20个以内；

日志中的报错信息：

2、 循环次数：尝试了两组： 10*2  vs 20*1 ，20*2 vs 40*1，结论是并发量小的话效果比较理想，也就是循环次数对性能造成的压力并不明显，附图

3、 Ramp up period in second：尝试了其他参数不变情况下 1s 和5s进行对比，5s情况下，吞吐量情况会有所提升，处理数据分别为14/m 和18/s,附图

 

四、jmeter配置相关

1、初级：http://www.cnblogs.com/star91/p/5059222.html

2、进阶-多个请求控制循环次数：https://blog.csdn.net/weixin_37556886/article/details/78790387

【todo】3、吞吐量如何理解】--延迟如何理解？jmeter中没看到这个参数

https://www.cnblogs.com/binyao/p/5162424.html

4、测试报告分析参考

https://blog.csdn.net/kaluman/article/details/78972192

 

五、jmeter使用中解决的实际问题记录

1、如何看某个接口一段时间内平均的性能情况

一个接口如果只压一次并发，偶然性的因素比较大，因此我们可以通过持续一段时间加压，看这段时间的响应情况，来对接口进行观察。通常可以设置为几分钟（比如3-5分钟），循环请求的方式，具体配置参考

 

2、如何在结果树中快速查看失败的记录

由于当请求的次数比较多时，结果树中只显示了一部分的执行结果，不容易快速定位错误，可以通过筛选，只看失败的记录来快速找到失败的日志，具体配置参考

 

 

3、性能测试如何兼顾业务场景

可以将多个接口为一组，一起执行

 

4、超时设置，避免接口返回没有收到而直接报错，通常可设置为2分钟

 

三、其他

1、jmeter场景设置 从业务场景到接口并发数量的设计

https://blog.csdn.net/laofashi2015/article/details/78552663

2、jmeter本身的内存调整，适应高并发

https://blog.csdn.net/gc_cg/article/details/78939611

3、性能并发用户数量的确定方法、峰值用户数量确定方法

https://wenku.baidu.com/view/77061f73581b6bd97e19ea62.html

4、测试脚本的规范、组织

https://www.cnblogs.com/zishi/p/8448073.html

5、跨线程传参值实例 beanshell

http://www.51testing.com/html/01/n-3725501.html

【2种方式，暂未试验，看上去比较全面】https://www.cnblogs.com/superbears/p/7041723.html

6、跨线程实现参数传递【已试验成功】

https://www.cnblogs.com/georgelei/p/749888c0ce42868e972baa1d94fa950b.html

7、性能测试场景测试问题：线程执行顺序 如何让线程同时执行【待试验】

https://blog.csdn.net/qq2901qq/article/details/79046577

8、思考时间设置【待试验】

https://blog.csdn.net/u011466469/article/details/78322513

https://www.cnblogs.com/licl11092/p/6862520.html

9、jmeter内存限制调整【已修改-确实非常奏效，压测2000情况下错误率下降了很多】

https://www.cnblogs.com/onmyway20xx/p/4635656.html

10、jmeter+jenkins 分布式多个节点jenkins思路 解决jmeter单机运行容易报错的问题、以及不能回顾历史的问题

https://www.cnblogs.com/miaomiaokaixin/p/6120682.html

11、jmeter+jenkins：https://blog.csdn.net/tomoya_chen/article/details/72677336

有比较详细的jenkins安装、配置操作步骤

12、jmeter中重要指标解释、一些坑【方法论比较全面】

https://www.cnblogs.com/jiu0821/p/5999297.html

13、不同场景下的思考时间处理--定时器

固定定时器（Constant Timer）

当放置Constant Timer于两个http请求之间,那么它代表的含义是:在上一个请求发出至完成后,开始Contant Timer指定的时间,最后再发出第二个请求.它并不是代表两个请求之间的发送间隔时间.这是最重要的定时器。

https://blog.csdn.net/zhanghenana/article/details/80846222

http://blog.51cto.com/ydhome/1874090

多种定时器的解释--https://www.cnblogs.com/wxinyu/p/7687063.html

实践：使用固定定时器试验了一下几个接口，可以连续的跑，每个接口间隔3秒

 

14、综合场景下按比例分配并发数量

https://www.jianshu.com/p/db092cbcceb1

 

15、配置不同的请求比例，解决不同请求配比问题，以不同比例调用不同接口。

https://www.cnblogs.com/Detector/p/8665923.html#_label1