性能测试
-
环境一定要干净，环境折算
测试环境不可能像生产环境服务器那么多
-
负载测试：
通过提高负载，观察系统各项指标的表现（如CPU使用率）
-
压力测试：
找到系统瓶颈或不能接受的性能点，判断系统能提供的最大服务级别
-
性能测试流程：
- 需求分析以及需求确定：对于一些指标达到什么范围（需求从哪里来的？是系统高峰期时的并发时间？运维采集到的？）。（一般会有3种人要求进行性能测试：客户，产品经理，项目经理（三年后，性能需要达到什么要求））
- 性能指标制定：响应时间，吞吐量，资源使用率，每秒点击次数，当前用户数
- 环境准备
- 使用性能测试工具脚本开发
- 场景设计：基准测试，负载测试，压力测试，稳定测试都怎么做？
- 监控部署：数据库，资源使用率
- 测试执行
- 性能分析
- 性能调优
- 生成测试报告
-
并发量与线程数
并发量指的是在同一时刻同时对系统某个功能进行操作的用户数量或请求数量。
一个线程可以发送多次请求，一个线程的并发量 = 1000ms/响应时间
1000个请求不等于1000个并发，因为有网络延迟的情况
- 例如，一个网站同时能承受 1000 个用户在线操作，这就是并发量。
-
性能测试指标：
虚拟用户数：用线程模拟
并发数：某一时刻，一定数量的虚拟用户同时对系统某个功能进行交互，一般通过集合点实现
事务：一个完整的功能，可有多个接口。由测试决定。一般会把一个流程作为一个事务，从搜索到下订单到支付等。事务控制器。
场景：即测试用例，比如1s增加多少用户，执行多久等
响应时间：平均响应时间，中位数，基准测试(一个用户请求接口，接口响应时间)，压力测试(并发请求接口，接口响应时间)
TPS：在一定时间内的系统处理的事务数（在银行系统中又可以叫交易数），系统的重要性能指标。TPS=总事务数/总时间数
例：去年的营业额在最高的一天达到10万，问今年他的TPS达到多少是合格的。
计算公式10万/一天多少秒 这么计算是错误的，因为这是一种理想状态，他将事务平均分了，实际上可能会有一个高峰期
如果没有更详细的数据，二八定律：80%的事务在20%的时间内完成
增加上业务的增长比率，比如预计今天业务会增加30%
吞吐量：衡量网络成功传输数据量，单位为bytes/s
-
吞吐量
服务器1s中处理了多少请求。小于等于并发量
- 示例：一个服务器每秒能处理 1000 个事务，这就是它的吞吐量。
并发量是关于有多少“人”同时在做事，而吞吐量是关于这些“人”做事的整体速度和效率。比如，在一个网络系统中，高并发量不一定意味着高吞吐量，可能存在大量并发请求但由于资源竞争等原因导致每个请求的处理速度较慢，从而使吞吐量不高；反之，即使并发量不特别高，但如果系统资源配置合理、处理高效，也能实现较高的吞吐量。
-
elk看微服务日志
ELK是Elasticsearch,logash,kibana的结合。
Elasticsearch可用于日志收集展示。
Logstash(收集日志)：到应用服务器上拿取log,并进行格式转换后输出到es中
Kibana是对 Elasticsearch索引中的数据进行搜索、查看、交互操作的工具，可以很方便的利用图表、表格及地图对数据进行多元化的分析和呈现。比es-head更加的可视化。
filebeat：通过使用 Filebeat，可以方便地将分布在不同服务器上的日志数据集中起来进行统一的管理和分析，为系统监控、故障排查等提供有力支持。
Filebeat (搜集文件数据)，相较于Logstash是轻量级工具
ELK工作原理展示图：
【APPServer集群】→→【logstash Agent 采集器】→→【ElasticSearch Cluster】→→【Kibana Server】→→【Browser】
● Logstash收集AppServer产生的Log，并存放到ElasticSearch集群中，而Kibana则从ES集群中查询数据生成图表，
再返回给Browser。 -
错误率
Jmeter压测报告中的异常率。
高并发海量请求，系统没有错误，没有报出当前请求人数太多，请稍候等错误信息
-
Jmeter压测
一般不采用原生线程组，因为它的线程数量是固定的
梯度线程组，灵活逐步增加线程数量
需安装插件
官方不建议在界面进行压测，因为UI界面本身会带来性能损耗
建议采用命令行
不建议在windows上压测，会出现端口不够的情况
-
测试报告
通过grafana图形界面显示
-
判断系统瓶颈
吞吐量是否随着并发量的增加而增加，没有的话，到达瓶颈
波浪形说明系统不稳定
响应时间没达到要求
错误率太高
-
排查
cpu占用，内存占用，网络问题
出现波浪可能是JVM垃圾回收时，STW stop the world
-
如何通过性能测试发现系统中的 潜在问题？
以下是通过性能测试发现系统潜在问题的一些方式：
-
首先，在性能测试过程中密切关注各项性能指标的变化。当响应时间突然变长、吞吐量下降明显，或者资源利用率出现异常升高时，这通常是潜在问题的信号。
-
观察系统在不同负载情况下的表现。例如，随着并发用户数增加，是否出现某些功能失效、报错，或者数据处理出现错误或不一致的情况。
-
分析测试结果中的错误日志和异常信息。这些往往能直接揭示系统在特定场景下暴露出的问题，如数据库连接失败、内存溢出等。
-
对比不同测试场景的结果。如果某些场景下系统性能差异较大，可能意味着该场景涉及的功能或模块存在特殊的处理逻辑或资源需求方面的问题。
-
关注系统的稳定性。长时间的性能测试中，如果系统频繁出现崩溃、重启等不稳定现象，说明存在严重的潜在问题需要解决。
-
对关键业务流程进行重点测试。如果这些流程在性能测试中出现卡顿、延迟等问题，会对业务产生较大影响，也反映出系统在这些方面可能存在不足。
例如，在性能测试中发现当并发用户数达到一定数量时，系统频繁报错“数据库连接超时”，这就提示可能存在数据库连接池配置不合理或数据库负载过高的潜在问题；又或者在某个复杂数据处理场景下，发现 CPU 利用率急剧升高且响应时间大幅增加，可能暗示该部分代码的算法或逻辑存在效率低下的问题。
-
-
性能压测场景设计
-
单接口基准测试（使用一个用户测试5分钟）：在没有任何压力的情况下，查看各性能指标
-
单接口负载测试：对一个 接口进行施压，直到出现性能拐点，获得被测接口的最大性能指标。用的不多
-
混合负载压测：多接口（一个事务），验证整个业务的最大最优的性能体现。 重点在于模型的设计，一般来讲，企业里搞得就是这个
递增线程组组件的使用方法
- 每5秒增加10个线程，持续30s
- 全部加载完成后，持续运行多少秒（负载测试一般10min到30min，压力测试一般4h,8h,12h,24h)
- 最后每1s停止5个虚拟用户数
-
压力测试场景：验证系统的极限，直到有一个性能指标不符合预期
-
稳定性测试：在压力测试的场景下持续运行4-24h
-
-
无界面压测
- 为了节约系统资源且更快捷，只需启动命令，为了性能压测集成，用Jenkins跑
- 脚本jmx后缀
- 命令行：Jmeter -n -t test.jmx -l result.jtl -e -o report (-n无界面压测，-t执行脚本，-l生成测试报告,-e -o 直接生成报告)，会直接生成一个html，里面包括聚合报告等
