一、性能测试指标
1、吞吐量：单位时间内，能处理多少请求。（单位：秒、每秒处理的请求量）
（1）TPS事务请求
用户操作伴随数据变化，例如：淘宝下单，40万订单/秒。
（2）QTP查询请求
用户查询数据，例如：打开淘宝查看某个商品页面。
2、响应时间（Response Time）
用户体验视角：网站打开快不快？
一个请求从用户发起，到收到服务器响应，所需要的时间：1、页面打开响应时间；2、具体单个资源响应时间。
3、并发处理能力
海量用户使用系统时候，在系统不崩溃情况下，能够支撑多少人同时使用。
单位：秒
（1）同时在线：
例子：10w人在线观看视频；session会话信息保存到 服务器存储 里面。
（2）同时操作：
例子：支付宝同时操作付款。
4、资源占用率
（1）成本角度：最小成本【最少资源】支持最多的吞吐量、支持最小的响应时间，包括：内存、网络、磁盘等资源。
例子：两个app，功能一样，做的事情一样；
1、第一个app：能够运行在5年前的手机上，2GB运行内存；
2、第二个app：能够运行在3年前的手机上，4GB运行内存；
结论：第一个app性能好。
（2）同时处理100个请求：需要占用多少CPU、内存、网络、磁盘。
例子：打开一个网站的请求，加载一系列图片 、html、js、css等内容。
需要观察：
1、内容压缩；
2、服务器将数据传输到浏览器客户端，观察服务器网络带宽资源：（1）每秒能够传输多少KB的数据；（2）需不需要加大服务器带宽；
3、当前这个系统部署在服务器，占用网络带宽是否太多？是否导致每一秒只能返回一个请求所需要的数据？
二、性能测试场景
1、追求更大的并发。【担心用户太多，搞垮系统用户量太多，担心处理不过来】
2、追求更短的响应时间。【觉得系统响应太慢】
3、追求更少的资源。【成本太高，需要服务器太多】
例子：用户量激增的情况下，系统是否崩溃。
1、前置条件：
（1）性能测试环境 通过采取和正式环境相同的机型；
（2）固定硬件配置：CPU、内存、网络、磁盘；
（3）固定软件配置：链接池配置、JVM配置、限流配置；
（4）不允许性能测试过程中动态变化，否则性能测试失去准确性。
2、机器数量：
（1）首先单机压测
目标： 测试系统是否能承载5000/s并发请求。
生产服务器会有5台：1、理论上每台服务器能够承载1000/s请求即可；2、那么结论：如果一台服务器能够承载1000/s请求；
（2）再小集群压测
1) 一台机器 性能吞吐量---》1000/s；
2) 4台机器 理论吞吐量---》4000/s；
3) 集群部署 机器之间的网络通信损耗；
4) 例如： 4台机器--->实际吞吐量3600/s 8台机器--->7200/s；
5) 损耗值需要压测才能出来，经验值大概是95%。
3、测试方式：
（1）模拟海量用户，请求系统；
1) 线程就是模拟用户；
2) 线程数量不是随便写的：
3) 也不一定是测试决定的；
4) 市场方面：需要市场规模预估，例如：当前2亿用户；
5) 产品方面：（1）需要产品经理产品规划，例如：产品日活20%；（2）用户操作习惯，例如：早上8-9点用的人最多，集中一个小时-30%-360w，每分钟6w人，每秒1000人；
6) 架构师方面：（1）线上数据分析，后台服务器统计系统数据；（2）经验值预估：每秒1000*10，一般经验是数量的10倍；
（2）预估线上用户并发数量最高峰值；
（3）尖峰测试+阶梯压测
1) 某一瞬间或者多个频次下用户数和压力陡然增加的场景；
2) Ultimate Thread GroupJmeter插件里面“终极”线程组：
·“终极”意味着不需要更多的线程组插件 ；
· 关键字段意思
（1）Start Threads Count：开始线程数；
（2）Initial Delay,sec：初始延迟，秒
（3）Startup Time,sec：启动时间，秒
（4）Hold Load Forsec：保持加载，秒
（5）Shutdown Time：关机时间
3) 执行命令：/u01/test/apache-jmeter-5.4.1/bin/jmeter -n -t spike.jmx -I test1.jtl -e -o ./report
4) 性能测试是否通过标准：
·请求错误率
· 响应时间在接受范围
· 资源使用在使用范围：服务器监控
感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
719
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
