共计 1627 个字符，预计需要花费 5 分钟才能阅读完成。
Jmeter 外围原理
基于协定，模仿实在用户场景，并通过多线程模仿用户发动申请。
- 基于协定：性能测试的对象是网络分布式架构的软件，而网络分布式架构的外围是网络协议
- 多线程：人的大脑是单线程的，电脑的 cpu 是多线程的。性能测试就是利用多 线程的技术模仿多用户去负载
- 模仿实在场景。用户的拜访工夫，拜访频率都不是固定的
性能测试实践
性能测试的
- 根本指标：测试零碎性能是否达标；通过肯定的技术手段，模仿用户的并发申请，去测试零碎最大解决能力与稳固运行的能力，找到性能瓶颈，晋升零碎整体解决能力
- 根本办法：基准、负载、压力……
外围原理
基于协定，通过多线程的形式模仿用户并发，在不同场景下施压服务器
- 基于协定：包含 http，https，tcp，udp，socket，websocket，基于协定发动申请
- 多线程：通过多线程的形式，模仿并发用户，施压服务器
- 波及场景：jmeter 办法，元件；设计用户应用零碎的关联，思考工夫，集合点，对后果进行断言
应用领域
能力验证：零碎是否在固定条件下具备所申明的能力
乙方向甲方提供的我的项目中，申明了零碎能够反对 5000 用户同时登录，且响应工夫不超过 3s; 乙方须要通过性能测试失去测试后果，给予甲方验收报告
瓶颈发现：发现瓶颈与缺点，无可参照的性能指标与指标
通过一系列的性能测试伎俩，发现性能瓶颈与缺点
性能调优：对系统性能的调优
针对发现的性能瓶颈做调优
- TPS 瓶颈
- 服务资源瓶颈
- 响应工夫瓶颈
- SQL 瓶颈
- 容量布局：零碎是否反对将来一段时间内的用户增长
以后用户可能只反对 5000 用户并发;
预计将来用户并发量能达到 50000 or 500000;
针对将来可能存在的业务量暴发，以预计的用户并发量为基数，做对应的性能测试，提前调整硬件设施
测试思路
- 要测什么？
前端：web、APP；从用户角度思考，更多关注页面加载工夫，与响应工夫
服务端：
- 工具层面：关注错误率与吞吐量
- 服务器层面：CPU，内存，IO，JVM
数据库：包含慢 SQL，死锁……
- 怎么测？
需要 – 打算 – 计划 – 测试环境搭建 – 设计用例 – 数据筹备 – 设计场景 – 脚本开发 – 数据监控 – 后果剖析 – 性能调优 – 提交报告
- 测试后果通过的规范：
依照需要：测试后果合乎预期
无规范需要的：例如测试一个页面的最大并发
性能指标
- 前端性能指标
响应工夫：用户视角最优先关注的指标
258 准则：
- 2s 以内，很称心
- 5s，个别
- 8s，无奈承受
前端相应工夫：
- 前端资源加载渲染的工夫
- 前后端交互的工夫
- 前端将后端查问的数据，在页面出现进去
网络连接工夫：
- connect time- 连接时间：申请收回到服务端接管到，两头的网络工夫
- latency- 提早：网络连接工夫 + 服务解决返回的工夫
- 服务段解决工夫 =latency – connect time
错误率
点击率（HPS）：用户点击按钮，触发申请
TPS：
- 单接口业务：单位工夫实现的申请数
- 多接口业务：单位工夫实现的事务数
RPS：间接从服务端角度掂量压力值
- 单位工夫发动的申请数
TPS 掂量了服务端 / 零碎的性能；RPS 掂量了压力
- 服务端性能指标
CPU
内存
磁盘 IO
JVM
中间件：Tomcat、redis、Nginx
测试视角
用户视角
- 响应工夫
- 零碎稳固
运维视角
- 硬件设施是否须要更换
资源利用率是否达标
- 利用率超标
- 利用率过低
- 零碎容量
开发视角
- 代码是否须要优化
- SQL 优化
- 零碎架构优化
性能测试工程师的视角
测试类型
基准测试：每一次版本迭代都须要做基准测试，目标是比照上一次的测试后果，给出调优的根据
负载测试：继续一直地减少压力；须要保障压力的持续性；找到零碎的瓶颈点
- 并发用户模型：继续一直地减少并发用户
- RPS 模型：继续一直地减少申请数
压力测试：当资源处于一个饱和状态，继续运行服务，考查零碎的稳定性；或者负载处于一个顶峰
- 稳定性测试：最大压力的 80%，继续运行一段时间
- 破坏性测试：在最大压力的根底上，仍然一直减少压力，目标是让零碎解体报错
失效恢复测试：零碎异样之后，是否及时地复原
容量测试：考查零碎在将来时间段内，能撑持的用户数；测试大容量下，零碎须要的硬件设施
