一、性能测试关键点
- 评估性能指标——线程tps（可架构给）
吞吐量qps（可架构给）
错误率（可架构给）
平均响应时间（可架构给） - 模拟线上数据量
- 了解接口有没有缓存，有缓存的需要设计
每次调接口获取的是不一样的数据
二、如何评估需要测试的接口线程数?
- 针对老项目：
- 系统里查看过去一周（或者一个月）内，接口调用量最高的那一天，然后
再找到当天中接口调用量最高的时间点（分钟级别），比如说是在12:10调
用量为10000，那么我们再换算每秒调用量10000/60=166，因此可以确定
这个接口tps只要达到166即可满足
- 系统里查看过去一周（或者一个月）内，接口调用量最高的那一天，然后
- 针对新项目：
- 二八定律的算法为 80%的请求 / 20%的时间 * 冗余系数（冗余系数一般
为2-5之间，一般可取3）如金融股票交易app，一般是早上9点到下午3点，
76060=25200秒，注册用户1000万，日活差不多100w，80%=80w，
80w/25200*3=95.接口吞吐量是95即可满足
- 二八定律的算法为 80%的请求 / 20%的时间 * 冗余系数（冗余系数一般
三、压测实际操作
当确定吞吐量指标，根据指标去压对应的接口：
1、压测设置参数：添加线程组，线程数=用户数/10；ramp-up period多少秒内启动所有线程，默认一般是1秒，0就是立即全部启动；循环次数一般写永远，压测个10-30分钟，看报告
2、聚合报告：Samples发出的请求数、Average单个Request的平均响应时间（ms）、error错误率、Throughput简称tps,吞吐量，每秒处理的请求数。
3、写接口，如果多个接口添加正则表达式，上下接口串联
4、关联数据库，cmd运行: jmeter logFile -o reportPath得到报告
性能测试指标对应压测方法：
吞吐量的预估值=考虑用什么方法去进行压测
- 500以下 JM 注：接口吞吐指标在500以下，JM就能满足
- 500-5000 JM分布式或者LR
- 5000以上 中控+多机部署
- JM分布式：JM上配置参数接口，jenkins配置多台服务器，一台控制机，多台负载机，控制机的密钥加到负载机中；
- JM+Grafana+Influxdb监控性能参数，内存，cpu占用情况，接口吞吐量
- Linux系统
- 内存
- 换页swap空间
-
free -m | sed -n '2p' | awk '{print "used mem is "$3"M,total mem is "$2"M, -
used percent is "$3/$2*100"%"}'
四、接口的性能瓶颈怎么查看？
随着tps越来越高，如何评估接口性能qps指标：
- 软硬件的资源利用情况会越来越高，直到满负载（内存，cpu占用情况）
- 吞吐量会不断变高，直到达到峰值，下降或企稳
- 响应时间会慢慢变高，超过吞吐量峰值，响应时间曲线会急剧拉升（因
硬件资源满负载，软件接口无法处理超+ 高并发，接口处理速度最后会急剧变慢）
所以：性能指标是吞吐量最高的那个值，响应时间缓慢拉升到急剧拉升的拐点，硬件
资源最大，这三者的坐标区域中间，就是性能峰值
五、怎么做性能优化？
1、最简单的加线程，进程
2、数据库层面，加索引，加缓存，一些机算上的结果缓存，
表数据太多，分表，sql优化
3、在有IO（网络IO，磁盘IO）的时候，批量读，写，合并
网络请求，减少与单点的交互
4、代码更高效的实现，改运算逻辑，如本来以账户维度计
算金额，改成以产品维度去计算
总结：
感谢每一个认真阅读我文章的人！！！
作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。
视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。
