目录为什么要聊性能测试性能测试是什么先把 “功能” 和 “性能” 分开软件里的性能问题长什么样四大核心指标并发数、吞吐量、响应时间、资源利用率4.1 并发用户数4.2 吞吐量与 TPS / QPS4.3 响应时间与那条 “性能曲线”4.4 资源利用率谁在关心性能四种角色的四个视角性能测试的五种类型6.1 基准测试6.2 并发测试6.3 负载测试6.4 压力测试6.5 稳定性测试6.6 负载测试 vs 压力测试一、为什么要聊性能测试功能测试的结论通常是一句这个需求通过了而性能测试的结论是一堆数字多少并发、多少 TPS、多少毫秒、CPU 打到百分之几。还有一条实践经验值得先记住功能测试在前性能测试在后。功能都没跑通的接口压出来的数据没有任何意义。二、性能测试是什么先把功能和性能分开五菱宏光和法拉利都是四个轮子、一个方向盘、能坐人往前开、有挡风玻璃遮风挡雨——功能上它们是一类东西。但座椅是人造皮还是真皮、0 到 100 km/h 是十几秒还是几秒这是性能上的天壤之别。同一件事能不能做是一回事做得好不好是另一回事。做饭也是能不能吃和好不好吃是两个维度。性能测试的定义为了发现系统性能问题或获取系统性能相关指标而进行的测试。落到执行层面它通常长这样在真实或接近真实的环境中在特定的负载条件下用工具模拟实际软件系统的运行与操作同时监控各项性能指标最后分析结果判断系统的性能水平。一句话概括性能测试不是点点看会不会崩而是用可控的负载去测量系统的行为边界。三、软件里的性能问题长什么样拿购物 App 举例用户能直接感知到的三类典型症状购物过程中页面突然打不开刷新一下又好了双十一期间进不去商品详情页页面加载时间过长用户把大量时间花在等待上。服务端视角下的常见表现则是查询数据耗时过长、网络传输慢、服务器无响应、列表要转很久才出来。这些现象背后往往是同一个根因链请求量超过了系统某一环的处理能力于是请求开始排队响应时间拉长最终超时或崩溃。性能测试要做的就是把这个某一环提前找出来而不是等它在大促当天自己暴露。四、四大核心指标并发数、吞吐量、响应时间、资源利用率性能好不好不能靠感觉得靠指标。评估系统性能主要看这四个维度。4.1 并发用户数并发数业务层面并发用户数指实际使用系统的用户总数。服务器层面指 Web 服务器在一段时间内为处理浏览器请求而建立的 HTTP 连接数或生成的处理线程数。一个案例把它们分开某已上线的 Web 系统有 5000 名员工使用最多同时有 2500 人在线用户分别进行浏览页面、填写订单、提交订单、查询订单等操作。业务并发用户数 2500同时在线的总量实际并发用户数只是其中正在执行提交订单、查询订单这类关键操作的那部分人结论在线 ≠ 并发 ≠ 请求数。压测脚本里的线程数要对应哪一层取决于你要复现的是哪种压力。4.2 吞吐量TPS / QPS吞吐量单位时间内处理的并发数直接体现软件系统的负载承受能力。吞吐量越高系统能承受的并发越多性能越好。先做一个容易踩坑的对比A 场景100 个并发用户每人每隔 1 秒发一个请求B 场景1000 个并发用户每人每隔 10 秒发一个请求。两个场景的吞吐量完全相同都是 100 请求/秒。但A 场景的用户思考时间更短连接和线程被占用的时间更密集因此 A 场景占用的系统资源明显更多。这就是为什么只看 QPS 数字会骗人——同样的吞吐资源消耗可能差一个量级。吞吐量的两种常用分类口径① 按请求数量TPS 与 QPS先明确事务一个接口可以是一个事务多个接口串起来也可以是事务一个完整业务流程就是一个事务。事务代表一个完整的业务功能粒度和业务定义强相关。如果某个事务里只有一个接口、且是查询接口那么QPS TPS。② 按网络数据量KB / 秒同样 100 QPS返回 200 字节的接口和返回 2MB 大 JSON 的接口完全不是一个量级的负载所以容量评估时网络带宽吞吐也要单独看。4.3 响应时间与那条性能曲线响应时间应用系统从请求发出开始到客户端接收到最后一个字节数据所消耗的时间。它验证的是系统处理速度的快慢。对 Web 系统而言用户等到的总时间要拆成两段并发用户数、系统吞吐量、系统响应时间三者的关系**是性能测试里最重要的一条曲线当并发⽤⼾较少系统吞吐量低系统响应时间较短我们认为系统处于空闲区间。随着系统并发⽤⼾增加系统吞吐量开始呈线性增⻓系统性能进⼊了线性增⻓区间。吞吐量在某个点上达到了饱和点也称之为拐点。在这之后⽤⼾请求不再被⽴即处理响应时间随之变⻓吞吐量也逐渐降低系统性能进⼊了过饱和区间。系统性能的拐点通常是性能测试的主要⽬的。4.4 资源利用率通过查看系统资源占用情况来分析资源瓶颈CPU、内存、磁盘、网络等。一次请求的完整链路上每一环都可能成为瓶颈两个高频实践结论前端资源加载过多、渲染时间就会变久用户侧的慢未必是后端慢后端select *全表查询、索引缺失是响应时间恶化最常见的元凶之一。性能调优做的事本质就是在这条链路上定位瓶颈环节然后把它拆开。五、谁在关心性能四种角色的四个视角从客户端发起请求到客户端收到响应中间每个阶段都可能存在性能问题。但没有任何一个角色需要为全流程负责——不同角色看性能的侧重点天然不同。运维的取舍题很能说明视角差异A 方案100 万并发用户登录响应时间 3 秒B 方案500 万并发用户登录响应时间 8 秒用户会骂 B但运维往往更倾向 B——因为容量优先。至于性能测试人员要求是这几类里最杂的既要有系统架构、存储架构、网络架构的全局知识面又要有大量纵深积累比如数据库 SQL 执行计划调优、JVM 垃圾回收、多线程常见问题等。可见性能测试的范围非常大也正因为如此大部分同学实际走的岗位仍是功能/业务测试为主、偶尔涉及性能更多是接口层面这完全正常——先把接口和流程测稳再谈调优。六、性能测试的五种类型6.1 基准测试Benchmark Testing又称单用户测试用于监测被测系统在较低压力下的运行状况并记录相关数据。性能测试环境确定后通常选取业务模型中的重要业务做基准测试对系统施加一定压力获取单用户运行情况下的各项性能指标为后续多用户并发测试、混合场景测试提供参考依据。一个形象的类比基准测试就像问一颗白菜能放多久——先在没有额外干扰的条件下拿到一份原始基线后面的对比才有意义。没有基准就没有变慢了这个结论。6.2 并发测试Concurrency Testing用于评估被测系统某些特定操作同时发生时的性能表现例如多个用户同时登录时的响应能力或某一功能被多人同时操作时的表现。并发测试的价值有两层拿到多用户并发操作时的性能指标发现并发条件下才会暴露的问题——内存泄漏、线程锁、资源争用。例如模拟多个用户同时访问同一份数据、同时更新数据可能暴露出数据库访问错误、写入错误。几乎所有的性能测试都会涉及一些并发测试。但要注意并发测试对同时这个时间要求比较苛刻通常需要借助专门的性能测试工具用多线程或多进程来模拟多个虚拟用户的并发操作。6.3 负载测试Load Testing性能测试的一种类型用于评估被测系统在预期的不同负载下的行为。负载可以通过控制并发用户数或进程数来实现。做法是逐步加压不断给系统增加并发访问负载监测性能变化直到某项或多项性能指标达到安全临界值最终确定在满足该指标的前提下系统能承受的最大负载量。类比举重运动不断给运动员加重量确定他在身体状况正常的前提下能举起的最大重量。例如某系统响应时间要求不超过 2 秒。逐步增加访问量假设当访问量超过 1 万人时响应时间超过 2 秒——那么可以确定在响应时间 ≤ 2 秒的前提下系统最大负载量是 1 万人。负载测试主要用于性能验证、性能诊断、性能调优。6.4 压力测试Stress Testing用于评估被测系统在高于预期、高于指定容量负载需求或低于最少资源需求的条件下的行为。它关注的是系统处理超出预期或特定峰值负载的能力也可以评估资源匮乏计算能力、带宽、内存不足时的表现。做法同样是逐步加压但目标是让某些资源达到饱和甚至失效从而发现只有在高负载下才会出现的缺陷同步问题、内存泄漏等并找出性能拐点、获得系统所能提供的最大服务级别系统能承受的最大压力。类比路况基准/负载测试像在城市道路正常行驶压力测试则是把车开上高速路段、极限工况看它什么时候开始失控。压力测试主要用于性能诊断、性能调优、容量规划。6.5 稳定性测试在负载测试的基础上执行较长时间的测试以检查系统的稳定性。通常较长时间指3×24 小时以上。它要抓的是那些跑一会儿看不出问题的毛病内存缓慢泄漏、连接池未释放、日志/临时文件堆积、定时任务累积影响等。6.6 负载测试 vs 压力测试同一条数据串起来看最直观响应时间要求 2 秒负载测试回答最多能带多少人上路还不超时压力测试回答车什么时候散架。
