经常有同学问我说“性能测试到底怎么做”一上来就着急下载工具、搜教程。这种热情没问题但方向容易跑偏。性能测试表面上拼的是工具操作核心拼的其实是流程。谁流程走得完整、走得稳谁的报告价值就高定位问题就快结果就可信。这也是为什么我会把“流程”单独拿出来当重点讲。这篇内容适合刚接触性能测试的同学也适合正在搭建测试流程、或者做完压测但总觉得结果不太对劲的同行。我会把整个性能测试的基础流程完整拆开从需求分析一路讲到报告输出把我们实际项目中会用到的做法、判断标准、以及那些教程上不常写但特别实用的经验一次性梳理清楚。1. 性能测试流程的整体认知与设计思路1.1 为什么流程比工具更重要有个很常见的误解性能测试 用工具压一下服务器。很多人花大量时间研究 JMeter 脚本怎么写、参数怎么配却忽略了整个测试过程的逻辑链条。结果就是压测做完了一堆图表贴在报告里但问三个问题就卡住了——这个测试到底验证了什么需求指标是多少算达标发现的问题优先级怎么排流程解决的就是这三个问题。性能测试不是一次性的“跑腿活”它是从业务需求到技术结论的完整推演过程。流程的每一环都有明确的输入和输出保证测试结果可以被解释、被追溯、被信任。这也是为什么在企业里性能测试流程本身就是项目质量体系的组成部分。一个不按流程走的性能测试数据再漂亮也只是一堆数字。用体检来打比方工具相当于体检设备流程相当于体检套餐的设计。你不可能把体检设备搬过来随便测一下就出健康报告你得先确定体检人群、要查哪些项目、参考指标是什么、结果异常后再做什么检查。性能测试流程干的也是这么回事。1.2 性能测试完整流程的八个关键阶段抛开特定的工具和平台性能测试的基础流程可以归纳成八个阶段需求分析搞清楚业务方到底要什么把模糊的说法翻译成可量化的指标。测试计划明确测什么场景、用多少并发、测多久、需要什么资源形成书面方案。脚本开发把业务操作转换成可被工具执行的脚本注意参数化、关联、断言这些细节。环境准备搭建与生产尽量一致的测试环境准备好存量数据部署好监控工具。测试执行按既定策略分阶段执行从单场景基准测试逐步推进到混合场景压力测试。监控采集在压测过程中同步收集服务器端、中间件、数据库、网络链路的运行数据。结果分析结合客户端响应数据和服务器端监控数据定位瓶颈区分性能问题是哪一层引起的。报告与调优建议输出结论性报告给出可执行的优化方向和优先级。这八个阶段里面最容易被忽略的是第一步和第八步。很多人默认“需求不就是领导说做个压测”结果指标都是拍脑袋定的最后报告也没人真正用。流程走全了性能测试的价值才说得清楚。2. 第一个关键节点需求分析与测试计划2.1 性能需求怎么才能问到点子上需求分析的功夫全在“问”。问不到点子上后面全白搭。我一般习惯问业务方这样几个核心问题这个系统预计的注册用户总量和日活用户量是多少业务高峰出现在什么时候高峰时段大概持续多久核心业务操作有哪些比如登录、查询、下单、支付、导出报表每个操作每天的调用量大概是多少用户能接受的最长响应时间是多少比如页面转圈转几秒会开始骂人历史上有没有出现过系统特别慢、卡死、甚至宕机的情况当时是什么场景未来半年到一年业务量有没有明显的增长预期这些问题问完基本就能估算出系统需要支撑的吞吐量和并发规模。举个例子如果一个业务日均 100 万次调用高峰集中在 2 小时内那么高峰期的平均 TPS 大约是1000000 ÷ 7200 ≈ 139。但高峰期往往是平均值的数倍我们要做的是峰值的 TPS 承载能力不是平均值。所以通常在估算基础上再乘一个系数比如 2 到 3 倍作为目标 TPS这样系统才不至于在真正的大促场景下被打穿。很多新人问“并发用户数设多少合适”这个数字恰恰不是拍出来的而是从需求推算出来的。生产系统如果在高峰期大概有 2000 个用户在同时操作压测时设置的并发数就应该围绕这个值上下浮动。用概念区分的话并发数关注同时在线或同时操作的用户量TPS关注每秒钟系统能处理的事务数量两者要一起看才有意义。2.2 测试计划与指标定制的实操要点需求理清之后测试计划就是把需求落到纸面上。一个合格的性能测试计划至少要包含这几块内容测试目标明确本次测试要验证什么比如“验证系统能否支撑 500 并发下单场景响应时间 P95 2 秒”。测试范围列出要覆盖的业务场景以及明确不覆盖的范围避免后面扯皮。测试策略说明采用什么测试类型是基准测试、负载测试、压力测试还是稳定性测试顺序怎么安排。指标定义把响应时间、TPS、错误率、资源利用率的目标值写清楚。资源与进度测试环境、压测机、人员分工、测试时间窗口安排。指标定制这里多说一句。响应时间究竟定多少算合理不能完全拍脑袋。行业内比较常见的是参考“3-5-8原则”或“2-5-10原则”意思是 2 秒以内用户感受良好2 到 5 秒还能接受超过 5 秒用户就会明显不满。但具体定多少要结合业务场景。比如登录接口用户等待耐心很低P95 控制在 1 到 2 秒比较合理报表导出这类操作时间长但只要在前端给出进度提示后端在 5 到 10 秒内返回也可以接受。还有一个实用的做法是看历史基线。同一个接口在最近一次版本迭代前响应时间是多少迭代后不能有显著劣化这种回归性指标往往比绝对值更有说服力。测试计划还需要做一件事评审。把计划拉给开发、运维、业务方一起过一遍。这一环看起来流程化实际上特别能避坑。开发能告诉你哪些接口依赖了外部系统运维能告诉你压测环境有哪些资源瓶颈业务方能补充你没想到的极端场景。评审会开完测试计划才能真正从“纸面方案”变成“执行依据”。3. 脚本开发与环境准备把场景变成真实的压力源3.1 JMeter 脚本开发的基础流程与细节脚本开发是很多人最感兴趣的环节网上一搜“jmeter性能测试步骤”就有大把文章但实际要做出一套靠谱的脚本远远不是录个脚本然后点击运行那么简单。我简单梳理一下用 JMeter 时的标准开发流程。第一步明确录制还是手工编写。如果用浏览器插件录制脚本录完一定要逐段检查。录制下来的内容经常包含大量静态资源的请求比如图片、CSS、JS 文件这些请求在性能测试里是否要保留取决于场景。如果测的是 API 接口静态资源请求应该全部删掉。如果测的是 Web 页面整体体验才需要考虑保留一部分但要注意它们在真实用户请求中是有并发和缓存机制的脚本里也要模拟不然压出来的流量和真实情况差异很大。第二步参数化。脚本里所有业务数据相关的值都要做参数化。比如登录账号、商品 ID、订单号这些值如果所有并发用户都用同一个压测结果根本不准。原因很简单系统很可能对热数据有缓存所有人都打同一个商品 ID查的是缓存测出来的性能当然比真实情况好。参数化要保证数据池足够大至少比峰值并发数大几倍避免压测中途参数用尽报错。第三步关联。很多系统和登录态、请求令牌绑定前一个请求返回的 token 要在后一个请求里使用。写脚本时从响应中提取动态值就是关联。没做关联的脚本要么每次请求都重新建连要么鉴权失败压出来的数据跟真实场景差得很远。例如登录后获取一个加密的 session 信息下单时要用这个 session 信息做签名不做关联脚本跑起来基本全红。第四步断言。很多人都忽视断言但一个没有断言的压测脚本是危险的。假设响应状态码是 200但返回的是一段错误提示业务实际上失败了如果只看 HTTP 状态码错误就被漏掉了。正确做法是加上响应内容断言比如判断响应体中是否包含成功标志字段。更严格一点的团队会同时结合业务日志来交叉验证成功率。第五步思考时间。真实用户不会每秒钟都在点按钮用户阅读页面、填写表单需要时间。不加思考时间压出来的是极端压力下系统的最坏表现加了合理的思考时间更接近真实体验。具体思考时间用多少我的建议是从用户操作习惯和业务日志的请求间隔来估计而不是随便填一个 1 到 3 秒。压测场景如果目的是找最大承载能力思考时间可以适当调小让压力更集中。3.2 测试环境、监控与数据准备要做到什么程度脚本准备好之后环境准备是另一个决定测试成败的关键环节。最理想的情况是独立的性能测试环境配置和生产保持一致数据库里放生产脱敏后的数据副本。环境不一致你测出来的数据就没有参考价值。比如生产是 8 核 16G 的实例测试环境只有 4 核 8G那性能数据整体偏移是必然的报告里写任何结论都不踏实。不过很多中小公司实际情况是环境资源有限这时候至少要保证被测应用、数据库、缓存、消息队列这些核心组件部署在独立的机器上同时压测链路必须避开其他业务的干扰。经验做法是先记录环境基线比如压力为 0 时被测服务的 CPU、内存、响应时间基线再开始压测。这样后面看数据时能区分哪些是压测产生的变化哪些是环境本身的问题。数据准备的重要性往往被严重低估。我曾经遇过一次线上事故排查发现测试环境数据量只有生产数据的几十分之一结果索引表现完全不一样单测怎么测都很快上线后一查慢 SQL 全出来了。这类问题在性能测试里非常典型。造数据的参考标准是按生产数据的量级和分布来准备至少要把核心表的体量逼近生产的 30% 到 50%同时保证数据分布合理。比如订单表如果全都是同一个用户的订单和分布在上万用户身上数据库执行计划会完全不同。监控工具这一块压测开始前就要部署好不要等压测进行中再去配。常见组合是 Prometheus Grafana 做指标采集和可视化配合 node_exporter 采集服务器基础指标Java 应用再用 JDK 自带的 jstat、jstack 看 GC 和线程状态数据库层面则可以用数据库自带的慢查询日志和连接数监控。压测发起端的机器性能也要提前评估。JMeter 默认是单机运行如果并发量超过几千本机可能先成为瓶颈CPU 飙高、线程调度不过来导致发出的请求量达不到设定值。这种情况下数据是无效的需要做分布式压测用多台压测机分担压力。判断压测机是否瓶颈可以看一个核心指标压测过程中压测机自身 CPU 是否长期超过 80%如果是优先解决压测机资源而不要去怀疑被测系统。3.3 正式开工前的冒烟验证用最少的时间确认一切正常环境和脚本都就位之后千万别直接上大规模压测。先做一轮冒烟验证用很小的并发比如 1 到 5 个线程跑几分钟目的只有一个确认脚本正确性、参数化数据可用、断言能正确判断成功与失败、链路没有问题。冒烟验证阶段需要观察几个点请求是否按预期发到了目标服务器看服务端访问日志是否有对应流量。响应时间是否符合初步预期有没有异常的超时或大浮动。确认压测数据的写入和清理机制有效。这一步看起来多此一举实则能帮你省下大量排查时间。当并发拉满后出现一大堆报错如果脚本本身就是错的所有结果都没意义。我见过有人全程用 500 并发压一个循环里依赖前一步响应的接口结果前一步 99% 失败后面跟着全挂压了一个小时出来一堆错误数据仔细一查是关联没做对。冒烟验证跑一遍这种低级问题当场就能发现。4. 测试执行与监控采集数据决定了报告的价值4.1 测试执行策略从基准到负载再到压力和稳定性执行阶段不能一上来就直接冲到目标压力。业界标准的做法是分层推进每一步的目的都不同数据之间还有逻辑关系。以 JMeter 为例典型的执行路线是这样的。先做基准测试。用很小的并发比如单线程跑一遍核心场景确定在无压力或低压力下接口的正常响应时间。这个数据极端重要它是所有后续分析的“标尺”。如果后面高并发场景响应时间暴增你对比基准就能知道系统退化了多少。然后是负载测试。逐步增加并发数或 TPS 目标比如从 50、100、200、500 这样往上推观察系统的响应时间、吞吐量和错误率变化。负载测试的目的是找出系统在正常负载范围内的表现验证是否满足目标指标。很多人在这里会犯一个错误不断叠加并发数但不等系统稳定就切换下一轮。性能测试讲究让系统在某个压力点下稳定运行一段时间观察数据是否平稳通常每个梯度至少要跑 5 到 10 分钟。负载测试之后是压力测试。持续增加压力直到系统接近或达到瓶颈点找到系统在崩溃边缘的表现。压力测试要关注的不只是“系统什么时候挂”更重要的是“挂之前有没有征兆”。比如连接池开始报错、响应时间曲线出现拐点、错误率从 0 跳到 5%这些数据对容量规划和告警阈值设置非常有价值。最后是稳定性测试。中大型项目基本都会要求做 7×24 小时或至少 8 小时的长时间压测。稳定性测试看的是系统在持续负载下是否有问题完整覆盖内存泄漏、线程泄漏、垃圾回收异常、连接池耗尽这些“跑短时间测不出来”的隐患。做稳定性测试时压力一般设置在目标 TPS 的 70% 到 80% 左右不是最大压力目的是模拟持续运营状态而不是极限状态。不同测试类型之间不是割裂的一个完整的性能测试项目通常按“基准 → 负载 → 压力 → 稳定性”的顺序串起来跑。每一步产生的数据都为下一步提供参考比如基准测试确定的单接口耗时能帮你估算后续负载测试每个梯度的预期 TPS。执行过程中还建议做好执行记录每轮压测的起止时间、配置参数、修改项都记下来。修改了脚本、调整了并发数、重启了被测服务这些操作必须记录在案。不然分析数据时看到性能突变连当时做过什么都不知道只能凭记忆推断准确度就很差。4.2 监控采集客户端指标只是冰山一角压测过程中JMeter 里看到的响应时间、TPS、错误率只是客户端视角的感知数据相当于病人自述哪里不舒服。真正的病灶在哪里要靠服务器端的监控数据来定位。这也是判断一个人是否真正懂性能测试的分水岭。客户端指标和服务器端指标必须结合看。客户端响应时间变长服务器端对应发生了什么要能从资源曲线上找到印证。比如响应时间 P95 明显上升的同时数据库 CPU 出现尖峰、慢查询日志持续打印那问题基本就能锁定在数据库执行环节。如果服务器端全都正常CPU 内存网络磁盘都在合理范围问题方向就要转向代码逻辑、锁竞争、线程等待这些更微观的层面。我习惯在每个压测场景执行时同时采集这样几类监控数据系统资源层CPU 使用率、内存、磁盘 I/O、网络带宽工具可以用 Prometheus node_exporter简单项目里用 top、free、iostat 查看也可以。应用层线程数、活跃线程数、阻塞线程数、GC 频率和耗时Java 应用用 jstat 和 jstack重点关注 Full GC 的情况。中间件层连接池大小、活跃连接数、等待队列长度Tomcat 线程池、数据库连接池都需要重点观察。数据库层慢查询、锁等待、连接数、缓冲池命中率必要时开启通用日志记录 SQL 执行情况。外部依赖如果被测应用调用了第三方接口或搜索引擎也要同步采集这些依赖的耗时。外部服务的性能波动经常被误判为主应用问题。监控日志建议按时间戳对齐保存比如服务器端指标每 5 秒一个采样点压测工具记录每 5 秒一个数据点后面做相关性分析时同样时间刻度直接对比就行。如果没有做时间对齐分析时就会发现客户端 TPS 最高点和服务器 CPU 尖峰对不上定位难度成倍增加。5. 结果分析与报告输出流程的终点是结论不是图表5.1 从数据到瓶颈定位一套实用的分析思路压测执行完毕手里有客户端测试数据和服务器端监控数据之后真正的分析才刚开始。我推荐的分析路径可以归纳成“由外到内逐层拆解”。第一步先从响应时间构成入手。一个请求从发起到返回消耗的时间通常包括网络传输、应用处理、数据库或外部服务调用。如果响应时间变长先看网络和中间链路是否正常再看应用层日志里请求处理耗时最后拆解数据库和外部调用耗时。通过拆解宏观定位问题在哪个环节。应用开启慢调用链路追踪的直接把每个环节耗时拉出来对比就行。第二步从资源利用率确认瓶颈性质。看测试过程中服务器各维度资源的利用情况如果 CPU 接近饱和而其他资源还有余量说明是计算密集型瓶颈方向在应用代码逻辑、线程模型、算法复杂度。如果内存持续走高并伴随频繁 Full GC方向在内存泄漏、对象创建过多、缓存策略。如果磁盘 I/O 或数据库等待明显方向在 SQL 效率、索引设计、数据量是否过大。如果网络占用率接近上限方向在传输数据量、序列化方式、压缩策略。第三步把链路数据合并判断。比如 TPS 上不去但 CPU 和内存都没跑满这种情况往往不是资源不够而是锁竞争、线程阻塞、连接数限制这些“隐性瓶颈”。Java 应用可以抓几份线程栈快照看看大量线程阻塞在什么操作上经常一眼就能看出问题所在。这里补充一个比较典型的案例。某业务压测到 300 并发时 TPS 卡在 600 上不去系统 CPU 才 40%内存也正常从表面看好像资源充足。后来抓线程栈发现大量线程都阻塞在数据库连接池获取连接上连接池最大连接数是 50而每个请求同时要拿两个连接处理事务并发一上来连接就被拿光了线程全在排队。调高连接池上限后TPS 直接翻了一倍。这种问题光看客户端响应时间或服务器资源指标都很难直接发现必须结合线程栈和连接池指标综合分析。再补充一点常见的阈值参考。错误率方面低于 0.1% 一般可以接受超过 1% 就要重点关注是否已经超出系统承载能力。响应时间方面观察从低并发到高并发曲线上的“拐点”特别重要一旦出现明显上升趋势对应的并发量就是系统的边界点报告里一定要把这个数据突出。5.2 性能测试报告怎么写才真正有用报告是流程的最终产物也是很多人做得最草率的一环。性能测试报告不是把图表粘贴上去就行它本质上是一份决策文档回答的是“系统到底行不行不行该怎么办”。一份真正有用的性能测试报告核心包含这样几个部分测试概述测的是什么系统、什么场景、什么时间窗口、什么工具和环境。指标汇总目标指标和实际结果的对照表。每个场景的 TPS、响应时间尤其是 P50、P95、P99、错误率、资源利用率都列出来一目了然。结论判定每条指标是否达标不达标的差距是多少。这里要有明确的通过/不通过结论不能含糊地带一句“基本满足”。问题与定位性能瓶颈的详细分析包括现象描述、分析过程、定位到的根因、建议方案。调优建议根据分析给出具体优化方向分优先级。例如先解决连接池配置问题高优先级改动小收益大再优化慢 SQL高优先级最后考虑代码层面的并发优化中等优先级。风险提示哪些数据受环境限制可能不准确哪些场景因为条件受限没能覆盖要如实写出来给评价方一个预期管理。写报告常见的两个问题一是只报数据不报结论领导看半天不知道系统能不能上线二是问题描述过于模糊比如写着“系统在高并发下性能下降”具体下降多少、瓶颈在哪、怎么复现全没有。好的报告要像一份病历现象、检查项目、诊断结果、治疗方案一应俱全而且每一处结论背后都有对应的数据支撑作为依据。报告中建议适当使用对比数据。比如调优前后同一场景的响应时间和 TPS 对比或者基准测试和压力测试的数据对比。有了对比读者能直观看到压测过程的变化趋势也更能理解结论是怎么推导出来的。6. 常见问题与排查技巧实录6.1 常见问题速查表这几类问题是我在不同项目里反复遇到的我整理成一张速查表方便大家排查时对照参考。现象可能原因排查方向解决思路TPS 上不去但压测机 CPU 已满压测机自身成为瓶颈查看压测机 CPU、网络、内存改用分布式压测多台压测机分担压力并发升高后响应时间曲线出现突刺Full GC 或外部依赖抖动查看 GC 日志、外部服务调用耗时调整 GC 参数、优化代码减少对象创建、降低对外部依赖超时时间并发一高就大量连接超时连接池耗尽或线程池打满查看连接池监控、线程栈快照调大连接池上限优化限制并发等待的配置低并发时一切正常高并发时接口报错数据库慢查询或锁竞争开启慢查询日志查看数据库锁等待优化 SQL、合理设计索引、拆分大事务长时间压测后响应时间缓慢增长内存泄漏或线程泄漏观察内存趋势、线程数量是否持续增长使用 JFR 或 heap dump 分析内存泄漏修复问题数据量小测试正常数据量大性能下降索引失效或全表扫描用执行计划分析 SQL优化索引覆盖、调整查询条件、分页优化压测结果与线上表现差异明显测试环境配置或数据量与生产不一致对比环境和数据差异环境对齐生产配置数据量按生产比例准备这张表只是起一个方向性提示作用实际问题往往混合了多个因素排查时还是要按“逐层拆解”的思路走把客户端、应用、资源、数据库的数据对齐着看用证据链来定位根因。6.2 我踩过的几个坑都是实打实的教训这几年做性能测试项目踩过的坑比看过的教程多得多挑几个高价值的分享出来。第一个是大意失荆州的数据准备问题。早期做某个接口的压测当时顺手把参数化数据池放在了脚本循环里结果大量用户循环使用同一批订单号。系统对这些订单号的数据有缓存压测结果好看得离谱TPS 高得连自己都不敢信。后来把数据池换成了十万级独立订单重新压了一遍TPS 直接掉了 30% 多那个数据才是真实的。从那以后我每次压测前都会用 SQL 查一下数据池的基数确认远超并发数再开跑。第二个是关联没做透导致的假失败。登录接口返回了 token但下订单接口的签名又依赖于响应头里的另一个字段当时只提取了 token 没提取签名参数结果并发一上来大量请求报签名错误。最麻烦的是错误率不高不细看响应报文内容根本发现不了。后来养成了习惯压测前先用小并发跑一遍人工抽样检查 10 到 20 条完整响应体确认业务逻辑正确再放大并发。第三个是监控盲区问题。早期压测只看应用服务器的 CPU 和内存数据库和外部服务完全没监控。有一次压测响应时间异常恶化应用服务器指标看起来还算正常排查了很久才发现是数据库的备份任务在压测时间段抢占了磁盘 I/O。从那以后压测前我会提前确认周边系统、备份任务、定时任务的时间窗口避免他们跟压测窗口重叠。监控也要提前布局好不能等出了问题再临时加。第四个是盲目追求高并发。有段时间团队喜欢把并发数设置得特别大觉得这样能体现系统的“极限能力”。但实际上如果超出真实业务需求两倍以上测出来的东西并没有太大决策价值反而容易把数据库拖出问题来影响正常业务。现在做方案时我会先和业务方对齐峰值预期再决定压测的最大压力避免无意义的破坏性测试。另外有一个小技巧特别想说性能测试期间建议随手保存现场快照。发现问题时把当时的线程栈、网络连接状态、数据库会话信息全部抓一份。等压测结束再回头排查很多时候现场已经没了想复现都很困难。7. 执行层面的几个补充建议聊完了主流程再补充几个执行层面经常被问到的小问题。首先是怎么处理动态 IP 限流和防火墙拦截。很多系统在网关层面会有防刷策略或限流规则压测流量会被当成攻击流量拦掉。压测前要跟运维确认清楚针对压测来源 IP 或压测标识放行流量。更稳妥的做法是用环境隔离的压测入口直接绕开线上网关。其次是思考时间的放置位置。不少人在每个请求之间随机加延迟但真实用户操作往往是“快速连点几个动作然后停顿很久”。更好的建模方式是把思考时间放在业务操作组之间而不是每个请求之间。比如一个用户操作路径是“登录 → 查询商品 → 下单 → 支付”那么查询商品后的思考和支付前的填写表单时间可以分别加不同的思考时间更接近真实行为。还有一个是测试数据的清理策略。压测产生的大量脏数据如果写在业务主表里会影响后续的功能测试甚至下一次压测。强烈建议在环境准备阶段就把数据清理方案确定好要么用独立影子库要么通过脱敏规则生成可识别前缀的数据跑完以后自动清理。有的团队会把压测数据写入单独的库表加个 is_test 标识字段这样清理起来一条 SQL 就搞定。关于压测工具的选型JMeter 依然是目前覆盖面最广的选择Community 活跃、插件多、资料全。Locust 适合对 Python 生态比较熟悉、想用代码灵活控制并发行为的团队。k6 在云原生和 CI/CD 集成上体验更好。工具之间没有绝对优劣选团队上手成本低、满足场景模型需求的那一个就行。工具只是流程的载体流程本身的价值永远排在工具前面。我个人做性能测试这么多年最大的体会是流程不是束缚是保护。它会逼着你在开始之前把问题想清楚在执行过程中把数据记录完整在出报告的时候把结论说透。只要按照这套流程一步步走下来哪怕中间出现意想不到的问题你也能从容应对——因为每个环节的产物都在手边每个异常现象都有迹可循。如果你正准备接手第一个性能测试项目不要急着打开工具先花两天时间把需求、环境和数据准备理清楚再把脚本做扎实。按这套流程跑完你会收获一份数据可信、结论明确、能真正支撑上线决策的报告也比盲目跑几轮压测学到的多得多。