1. 简介

1.1 说明

如未特殊说明，涉及工具的理论都是基于jemter来说的

问题 性能测试能不能模拟客户操作，发现服务器性能问题？  很难

1.2 什么是软件性能

从相关角色的角度关注点来看

用户：只关心操作快慢

业务或产品：关注产品快慢，响应时间

运维：关注快慢、响应时间、监控各种资源、确保生产环境稳定性

dba:关注数据库各种资源利用率 、死锁、慢sql

开发：关注响应时间、代码有没有性能问题，有没有不合理的逻辑导致响应时间慢

架构：关注架构方面的问题，扩展性问题，高并发、高可用、稳定性

测试关注：以上所有问题

1.3 如何理解性能测试时的各种测试

性能测试：根据性能需求、业务模型，设计性能测试方案，准备性能测试数据，开发脚本，设计性能测试场景和性能监控，以合适的加压方式来进行压测同时监控去发现性能问题，根据监控去分析定位，最后优化性能（TPS、响应时间、资源使用率），达到性能需求。

负载测试：不同的客户端线程对服务端发起压力，看服务器处理情况

容量测试：是系统承受超额的数据容量(如数据库、业务容量)，测试系统是否能够正常处理，通常和数据库有关。

递增测试：不断加压，在系统各项指标合理的情况下，找出系统最大tps

强度测试：测试系统的极限，最大能测多少

等等

2.性能测试现状

压测目标：不明确

执行压测：不专业

性能报告：无参考价值

例如：

1.领导说我们系统有几百个微服务，某某给我做个性能测试，然后你就去用jmeter压测了一下，给了一个结果，这不叫压测，连门都没入

2.领导说我们系统有几百个微服务，某某给我做个性能测试，你是用命令监控了服务器资源，数据库，压力机，给出了慢sql,索引问题，说tps低，io有问题。粗略定位到了，没给出调优建议，让开发自己去解决。这只是入了门，算初级性能测试。

3，领导说我们系统有几百个微服务，某某给我做个性能测试，你用grafana搭建了监控环境，通过监控环境，给出了慢sql,给出了索引有问题，定位到了业务方法层面，对配置给出了调优建议。这算中级性能测试。但面对微服务，复杂的系统，不能精准定位。

4.领导说我们系统有几百个微服务，某某给我做个性能测试。你搭建了全链路监控环境，定位到了慢sql,索引问题，给出了优化建议。通过链路监控精确定位到中间件问题调优了中间件，精确定位到了代码层级的问题，给出了优化建议。这才算是真正的性能测试。

3.一些概念

3.1 什么是并发？（线程？tps?）和用户、并发用户数、服务端线程池大小的区别是？

并发分为绝对并发和相对并发

绝对并发：同一时刻对系统发起的同一请求的数量（单场景）

相对并发：一个时间段内对系统发起的请求数

线程：一个客户端请求就是一个线程

tps:每秒服务器能处理成功的事务数（某一时刻tps=处理总请求/并发时间=线程数*（1000/rt））

用户：有业务含义的tps

并发用户数：有业务含义的tps的大小

压力线程、服务端线程池大小：服务器能同时处理的业务数

线程是否是虚拟用户？否，线程的每次迭代才是一个用户

压力线程数是否是并发用户数？否，压力线程数是客户端线程数，具有业务含义的并发就是并发用户数

rt：响应时间，压测时间从低到高（响应时间变长）

3.2 再说说其它几个ps:qps、tps、rps、hps的区别

QPS(Query Per Second 每秒查询数)：有些公司只做查询业务的压测，这样的话tps=qps

RPS(Request Per Second 每秒请求数):客服端每秒能发送的请求数，无意义的指标

HPS(Hits Per Second 每秒点击数):一次请求可能包含多次点击

TPS(Transaction Per Second 每秒事务数):衡量服务器的处理能力，通常测试人员理解的并发

3.3 tps，rt,三者的关系

TPS随线程数线性增加，一段时间后，TPS增加速度越来越小，可能出现TPS下降，rt变得越来越长。需要找到性能拐点，这个拐点处就是最优tps

3.4 性能指标

tps、rt、成功率，服务器资源使用率

并发度=tps/在线用户数

活跃度=在线用户/存量用户，活跃度一般又分为日活跃度，周活跃度，月活跃度

3.5 准确理解术语

参数化：

• 数据库不允许提交重复值（唯一性约束）
• 避免查询缓存
• 模拟真实场景需要不同用户数据

关联：下一个请求的入参依赖上一个请求的返回值

断言/检查点：判断一个请求是否成功，需要用到断言/检查点

吞吐量/吞吐率：时间段内传输的数据量/每秒吞吐量

定时器/思考时间：为了模拟用户的等待时间（不建议加）

集合点：模拟大量用户同时向服务器发起请求（秒杀、抢购）