需要了解的性能测试理论（面试必备）
首选对于一个性能涉猎不久的小白来说，会脚本编写不足以支撑整个面试需要，确实需要一些理论的东西来证明一下你了解性能测试，什么时候做性能测试。各项指标的含义是什么？
1.为什么需要性能测试呢？
随着互联网行业的发展，用户量大大增加，业务和系统架构越来越复杂，数据越来越多，用户不仅仅满足于功能的实现，在某些场景下，更在意系统性能
2.什么是性能测试：
性能测试是基于系统性能的预期指标，建立测试模型，制定测试方案，制定监控策略，验证被测系统在高并发的条件下的处理能力、响应能力、稳定性等，能都满足预期。定位性能瓶颈，排查性能隐患，保障系统的质量，提升用户体验。
3.什么样的系统需要做性能测试：
访问量高的系统，比如淘宝，核心业务比如淘宝下单，算法逻辑高的，比如下单界面的账单计算，还有推广类的促销等
4.性能测试发生的场景：
新系统/新项目，线上性能问题的验证和调优，新技术选型
性能容量评估和规划
日常系统性能回归
性能测试指标：
事务：在性能测试领域里，衡量一个系统性能的好坏，只要看得是单位时间内，系统可以处理多少业务量。各个系统的业务各不相同，为了方便衡量业务的性能，需要在测试脚本中添加一对变迁，测试工具统计单位时间内，标签的业务量，就可以统计出真是的业务量
脚本中的标签，就叫事务，事务是用户定义的，想测试什么业务的性能，就把改业务加到事务中
TPS/QPS
Transation per Second每秒处理的事务数
响应时间：网络传输时间+各组件业务处理时间
一个请求从发送出去到接手回来所需要的时间
LR《==》网络设置《==》中间件《==》应用程序《==》DB
平均响应时间：在测试过程中，所有请求的平均耗时
如果出现响应时间过长的情况，最后可能发现在DB和应用程序身上
TOP响应时间：
将所有的请求时间先从大到小进行排序，计算指定比例的请求都小于某个时间，该指标统计的是大多数请求的耗时
Tp90（90%响应时间）：90%的请求耗时都低于某个时间
Tp95（95%响应时间）：95%的请求耗时都低于某个时间
Tp99（99%响应时间）：99%的请求耗时都低于某个时间
并发数/虚拟用户（Vuser）
压测工具中设置线程/进程数量
成功率
请求的成功率
PV（page view）
页面/接口的访问量
UV（unique vistor）日活
页面/接口的每日唯一访客
吞吐量
网络中上行和下行的流量综合，吞吐量代表网络的流量，TPS越高，吞吐量越大
TPS、响应时间和并发数的关系
在系统达到性能瓶颈之前，TPS和并发数成正比管理
响应时间单位为秒的情况下
TPS=1/响应时间*并发数
TPS=并发数/响应时间
响应时间单位为毫秒的情况下
TPS=1000/响应时间*并发数
TPS=1000*并发数/响应时间
性能监控指标：
操作系统级别监控
Cpu使用率、内存使用率、网络IO，磁盘（read、write、util）
中间件监控
连接数、长短链接、使用内存
应用层监控
线程状态、JVM参数、GC频率、锁
数据库监控
连接数、锁、缓存、内存、sql效率
性能测试流程：
需求调研==》测试计划==》环境搭建==》数据准备==》测试脚本==》压测执行==》调优回归==》测试报告
需求调研：项目背景、测试范围、业务逻辑&数据流向 系统架构、配置信息、测试数据量、外部依赖、系统使用场景、业务比例、日常业务量、预期指标、上线时间
测试计划：项目描述、业务模型及性能指标、测试环境说明、测试资源、测试方法以及场景设计原则（基准测试、单交易负载测试、混合场景测试、高可用性测试、异常场景测试、稳定性测试、其他特殊性测试）测试进度安排及测试准则
环境搭建：
测试机器硬件配置尽量和线上一致
系统版本与线上一致
测试环境部署线上最小单元模块
应用、中间件、数据库配置与线上一致
其他特殊配置
数据构造：
业务接口：--适合数据表关系复杂
--优点：数据完整性比较好
存储过程：--适合表数量少，简单
--优点：速度最快
脚本导入：--适合数据逻辑复杂
--自由度比较高
数据量级：--测试数据
--基础数据
脚本编写：
选择工具，选择协议，参数化，关联，检查点，事务判断
压测执行：
分布式执行
监控 --linux --jvm --数据库
收集测试结果
数据分析
瓶颈定位
调优回归：
性能调优需要整个团队完成
反复尝试
回归验证
监控工具
全链路排查
日志分析
模块隔离
性能测试工具：
Loadrunner（功能强大，重量级，商业软件）
Jmeter（小巧灵活，轻量级，开源）
Ngrinder（开源压测平台）
Locust（python开源框架）
现状和趋势：
性能自动化，平台化
测试工具多样性，开源、二次开发
在高并发下验证功能的正确性
线上线下相结合，线上发现问题，线下调优
