性能测试（1）

目标能够对个人编写的项目进行接口的性能测试同样是一辆车五菱能跑法拉利也能跑但为什么价格差那么多因为性能不同。软件也一样功能实现了只是“能开”性能好才是“开得爽”。一、什么是性能测试功能测试在前 再执行性能测试简单说功能测试回答“系统能不能做这件事”而性能测试回答“系统做得有多快、能扛住多少人”。比如你做一个购物网站功能测试用户能登录、能下单、能支付 ✅性能测试双十一那天10000人同时下单页面会不会卡死响应时间会不会超过3秒 ❌性能测试就是在真实或模拟的环境下用工具给系统施加一定的负载监控各项指标发现性能问题如页面打不开、加载慢、服务器无响应等。概念为了发现系统性能问题或 获取系统性相关的指标 而进行测试二、核心性能指标 —— 如何衡量“好不好”2.1 并发数并发用户数分两种视角业务层实际使用系统的用户总数。比如公司有5000人最多同时2500人在线业务并发就是2500。服务器层Web服务器建立的HTTP连接数或处理线程数小提示不是所有在线用户都会同时“搞事情”。真正给服务器压力的是那些正在提交订单、查询数据的用户2.2 吞吐量单位时间内系统能处理的请求/事务数量直接体现系统的负载能力。吞吐量越高性能越好。常见单位TPS每秒事务数一个完整业务如下单的每秒处理量。公式总成功事务数 / 总运行时间例子1分钟处理1000个订单 → TPS ≈ 16.7QPS每秒查询数如果单个事务就是一次查询QPS TPS。实际估算TPS时别傻傻按全天平均。用二八定律80%的请求发生在20%的时间里。例如一天10万订单 → 理论TPS1.2实际按二八定律≈4.6。如果有高峰时段数据比如晚上8~9点5万单则TPS≈13.9再考虑业务增长30% → 18左右。2.3 响应时间从你点击按钮到页面上收到最后一个字节的时间。包括前端展现时间浏览器渲染页面系统响应时间服务器数据库网络等用户在乎的是主观感受——超过3秒就烦超过5秒可能直接关掉。空闲区并发少响应快吞吐量低。线性增长区并发增加吞吐量成比例增加响应时间平稳。饱和点拐点系统处理能力达到极限。性能测试的核心目标就是找到这个拐点。过饱和区请求排队响应时间暴涨吞吐量反而下降甚至崩溃。阶段并发用户数TPS响应时间状态空闲区间少低短系统轻松线性增长增加线性上升缓慢增加正常运行拐点临界值达到峰值开始明显变长⚠️ 性能瓶颈过饱和过多下降急剧增加❌ 系统濒临崩溃2.4 资源利用率服务器吃得消吗看CPU、内存、磁盘、网络的使用率。如果CPU长期100%那肯定扛不住了。三、不同角色眼中的性能不同的角色看待性能测试的侧重点不同从客户端发送一个请求到客户到收到请求的整个过程中各个阶段都可能存在在问题角色关注点终端用户响应快不快主观时间运维人员全局利益最大并发 vs 响应时间的平衡。比如100万用户响应3秒 vs 500万用户响应8秒可能选后者开发人员算法效率、内存泄漏、架构可扩展性、SQL调优测试人员场景设计、脚本编写、缺陷定位需要广博的知识DB、JVM、网络等不需要一个人搞定所有但知道各方关注点才能做好性能测试。四、性能测试的五大分类4.1 基准测试也称为单用户测试主要用于监测被测系统在较低压力下的运行状态并记录相关数据。当性能测试环境确定后通常选取业务模型中的重要业务做基准测试对被测系统施加一定压力从而获取被测系统在单用户运行情况下的各项性能指标对多用户并发场景和混合场景等提供参考依据。用一个用户跑一遍核心业务记录各项指标响应时间、CPU占用等。作为后续对比的“标尺”。就像你先空手跑一次100米记下时间再负重跑就知道影响了多少。类比一颗白菜能存放多久先测一颗4.2 并发测试评估多个用户同时操作时的性能表现发现内存泄漏、线程锁、资源争用等问题。类比100个人同时登录会发生什么4.3 负载测试逐步增加负载比如从100用户慢慢加到10000用户同时保持性能指标不超标比如响应时间2秒测出系统最大能扛多少负载。类似举重不断加重量直到运动员动作变形指标超标之前的重量就是最大负载。逐步增加并发负载直到某项性能指标达到安全临界值确定系统最大承受量。4.4 压力测试超过预期负载直到系统崩溃找出只有在高负载下才会出现的缺陷。负载测试 vs 压力测试的区别负载测试在满足性能指标如响应时间≤2秒前提下找最大负载如1万用户压力测试继续加压到2万、3万用户直到系统崩溃找极限点⚠️ 负载 vs 压力维度负载测试压力测试目标找到满足性能指标下的最大负载找到系统崩溃极限负载程度正常峰值仍在指标内超过峰值崩溃类比举重运动员动作标准时的最大重量再加到动作变形甚至受伤的重量产出容量规划数据系统健壮性、崩溃恢复能力4.5 稳定性测试在一定的负载下通常是正常负载的80%左右长时间运行比如3×24小时看系统会不会内存泄漏、日志爆炸、越来越慢。类比不是看谁跑得快而是看谁跑到最后