1. 从想压测到真正打开压测大门最近在带团队做一个小型电商项目上线前的稳定性评估Leader丢给我一句“做个性能测试看看瓶颈”我第一反应其实和很多人一样直接去翻之前项目里别人留下的JMeter脚本。但那个脚本是用老版本JMeter配了一堆插件打开全是红叉BeanShell里还留着上上个人写的乱码注释。我花了一个下午在“修脚本”而不是“做测试”那感觉实在太糟糕了。后来我换了思路既然要重写为什么不用Locust反正纯Python代码可控、分布式天然支持、报告直观而且我们本来就是Python技术栈。这一换确实打开了新大门。这篇文章就锁定软件测试领域里最常被问到的性能测试工具之一Locust。我会从“到底是什么”“为什么值得用”“怎么装”“装完怎么快速跑起来”四个维度来拆确保你跟着走一遍就能在本地完整跑起第一个压测demo。适合谁来读准备入行软件测试的应届生、已经会用JMeter但想了解Python系压测工具的测试工程师、开发自测接口性能的后端同学。不需要你有多深的Python功底但最好对HTTP接口有个基本概念。如果你已经能独立用JMeter做一个并发压测并分析聚合报告那这篇文章对你来说更像“无缝迁移指南”。2. Locust到底是做什么的和JMeter比差在哪2.1 核心思路用代码描述用户行为Locust的中文直译是“蝗虫”暗含一群蝗虫式并发压向目标这个意象很直观。它的设计理念如果用一句话概括就是**“压测场景即代码”**。传统工具比如JMeter里你通过图形界面拖拽组件去构建一个线程组再添加HTTP请求、断言、监听器。图形化最大的问题是一旦场景复杂或者团队需要版本管理、多人协作界面里的“脚本”没法像代码一样做diff、做Code Review。而Locust完全反过来它的压测场景就是一个Python文件你定义一个类继承User在里面用task装饰器声明接口行为。整个文件就是普通Python代码可以进Git可以走CI/CD流水线。我个人对这套设计最大的感受是它把“压测”从一个黑盒操作变成了一个白盒编程活动。你可以直接import项目的公共库自定义请求参数生成逻辑动态读取数据甚至写断言逻辑。这在JMeter里往往要靠BeanShell或者JSR223脚本才能实现而Locust本身就用Python写业务逻辑学习曲线其实是平的。2.2 Locust和JMeter的选型对照我把几个关键维度列成一张表方便你根据自己团队情况做选择题维度LocustJMeter脚本形态Python代码XML格式图形界面编辑上手门槛需要基本Python语法纯界面拖拽零代码起步更快分布式支持内置Master/Slave节点天然支持需要额外配置Agent和远程启动稍繁琐扩展性可通过Python自定义一切通过插件体系扩展但插件质量参差报告能力提供Web UI实时图表数据分析靠自定义导出聚合报告成熟插件生态有大量图表方案资源占用基于协程gevent单进程可模拟大量用户每线程占用较高压大规模需要较多机器适用场景接口级、Python技术栈、持续集成友好全场景、复杂协议如JDBC、JMS、已有成熟团队需要注意一个常见误区Locust不是“比JMeter更厉害的工具”而是“不同设计哲学下的工具”。如果你的压测需求很固定、团队没人写Python、或者要压数据库/JMS这类非HTTP协议那JMeter依然是更稳妥的选择。但如果你面对的是微服务接口、Web站点、RESTful API而且你们团队有代码素养Locust这套“性能脚本即代码”的思路会更香。2.3 到底哪些项目适合用Locust从我的项目经验看适合Locust的场景有这么几类第一类接口快速验证型。比如开发说某个接口优化了你要在五分钟内验证一下吞吐量有没有提升。这种时候根本不需要搭建完整的JMeter工程直接写个十来行的Locust脚本压一把就出结果。第二类需要动态压测数据的场景。比如业务请求体里需要签名参数、时间戳、随机用户ID用Python代码处理这类动态参数比用JMeter的“函数助手”更自由。第三类与CI/CD流水线集成。比如每次发布前自动跑一遍轻量冒烟压测如果P95延迟不达标流水线直接标红。代码形态的脚本天然适合挂在Jenkins或GitLab CI上。所以如果你正好在软件测试入门或转岗节点上我的建议是JMeter必须要有一定基础但Locust可以作为你拉开差异化、提高效率的秘密武器。3. 为什么说Locust安装其实是个很讲究的过程3.1 第一步Python环境准备先说明一个我踩过的坑Locust目前对Python版本有明确要求官方长期支持Python 3.9到3.12这些主流版本但你直接用系统自带的Python环境装很容易把依赖搞乱。我强烈建议用一个独立的虚拟环境来跑Locust和你的项目环境隔离这样即使项目依赖冲突也不影响压测环境。在Windows、macOS、Linux各平台上我的推荐姿势是这样# 创建虚拟环境目录名可以自己定 python3 -m venv locust-env # 激活虚拟环境 # Windows: locust-env\Scripts\activate # macOS / Linux: source locust-env/bin/activate装完虚拟环境后再检查一下Python版本python --version pip --version如果输出版本在范围内环境就算“能用”了。别小看这个步骤我曾经见过有人在系统Python全局环境里面直接pip install locust结果跟公司内部某个包冲突连Django都起不来了最后花了半天才排查到是gevent版本被顶掉了。3.2 第二步pip安装Locust虚拟环境激活后安装命令极其简单pip install locust如果你在的企业网速一般或者缺省PyPI源访问慢可以指定国内镜像源pip install locust -i https://pypi.tuna.tsinghua.edu.cn/simple安装完成后验证版本locust --version正常会输出类似locust 2.31.0的版本号。看到这里你的Locust其实已经“装好了”剩下就是怎么确定它真的能正常工作。这里我要额外提一个理念Locust安装完成只是开始真正的“安装工程”还包括确认依赖的gevent版本是否和Python匹配、是否能用Web UI模式启动、以及能不能无头模式跑起来。这也是很多新手装了但跑不起来、然后以为是安装失败的根本原因。所以我下面的内容会用一个最小demo把“装好”这件事彻底落地。3.3 第三步验证安装是否成功安装成功后最直接的验证方式是直接启动一个最简单的压测文件。先新建一个测试目录比如locust-demo在里面新建一个Python文件叫locustfile.pyfrom locust import HttpUser, task class QuickUser(HttpUser): task def visit_index(self): self.client.get(/)然后在同一个目录下运行locust如果你的终端输出了类似这样的信息就说明安装完全没问题Starting web interface at http://0.0.0.0:8089这时候浏览器打开http://localhost:8089能看到一个Web压测控制面板说明你的Locust环境已经OK了。真到这一步安装才算真正“闭环成功”。4. 快速跑通你的第一个压测demo4.1 从写一个真正的压测脚本开始光能启动不算本事能压出报告才算。我们直接写一个稍完整的demo目标是对一个接口做并发测试。假设你的被测系统是本地起的服务比如http://localhost:8000我们再模拟一个常见的业务场景首页访问用户登录。新建一个locustfile.py内容如下from locust import HttpUser, task, between import random class WebsiteUser(HttpUser): # 模拟真实用户在每个任务之间的思考时间 wait_time between(1, 3) task(3) def load_homepage(self): # 权重为3意味着整体请求中首页访问占比更高 self.client.get(/) task(1) def load_login(self): # 模拟登录接口POST一个随机用户名 username fuser_{random.randint(1, 10000)} self.client.post(/login, json{ username: username, password: 123456 })文件里有几个关键点HttpUser代表一类执行任务的“用户”Locust会为每个模拟用户生成一个协程。wait_time用来模拟用户思考时间这里的between(1, 3)是1到3秒随机。思考时间直接决定你的压测“真实度”压一个真实场景如果完全没有思考时间结果往往会偏乐观。task装饰器声明任务支持传入权重。权重越高被选中执行的概率越高。这个脚本就是我们的压测入口。不需要写复杂的配置文件也不需要像JMeter那样为每个请求配一堆监听器。4.2 启动压测的两种方式Locust启动方式主要有两种Web UI模式和无头模式。Web UI模式最直观直接运行locust然后打开http://localhost:8089你会看到一个表单填写三样东西被测地址Host比如http://localhost:8000并发用户数Number of users比如100每秒启动用户数Spawn rate比如10点击“Start swarming”压力就开始顶上去了。Web UI里能看到实时RPS、响应时间、失败率等曲线。这种模式适合探索性压测因为你可以一边看指标一边调并发数非常有“现场感”。无头模式适合自动化比如集成到CI里跑locust --headless -u 100 -r 10 -H http://localhost:8000 --run-time 30s参数含义--headless无界面模式-u 100模拟100个并发用户-r 10每秒启动10个用户逐渐达到100-H指定被测系统地址--run-time 30s总共运行30秒无头模式跑完终端会输出一段统计汇总包括请求总数、每秒请求数、平均响应时间、P50/P90/P95/P99等。这些数据已经足够做一轮快速判断我建议你在自动化场景下直接用它然后把结果以结构化格式导出方便后续生成报告。4.3 用阈值判断你的接口到底行不行很多刚做压测的同学有个问题看了一堆指标却不知道什么算“好”什么算“坏”。其实性能测试讲究的是“有目标地测”没有SLA的压测等于瞎压。我一般会在压测前和业务方、开发定好三个阈值并发数目标支撑多少用户同时在线使用P95响应时间比如要求95%的请求在500ms内返回错误率比如低于0.1%如果你压测结果P95超过2000ms哪怕接口没报错站在用户体验角度这已经算“性能瓶颈”了。反过来如果P95在300ms内错误率几乎为0那么当前并发数下系统就是稳的。用这个标准判断你的压测结果就能直接指导上线上决策。我习惯在无头模式下加上--csvresult参数让Locust额外产出CSV文件再用Python脚本或Excel透视表做汇总。这个习惯帮我避免过很多“凭感觉下结论”的情况。5. 新手最常踩的5个坑和排查思路5.1 安装时gevent编译报错Locust底层依赖gevent在某些Python版本或系统环境下gevent需要本地编译可能出现缺少编译器的错误。比如Windows上提示error: Microsoft Visual C 14.0 is required。解决办法有两种一是安装之前先升级pip和setuptoolspip install --upgrade pip setuptools二是直接使用预编译的二进制包pip install --only-binary :all: gevent如果你用的是Python 3.12现在Locust官方已经适配得比较好基本不会遇到编译问题。但如果你的项目还在用Python 3.8以下老版本我建议直接换成3.10或3.11省心得多。5.2 启动locust提示找不到locustfile这个坑我见过不止一次。Locust默认会找当前目录下的locustfile.py文件如果你的文件叫别的名字比如test_something.py或者文件在子目录里直接运行locust就会提示找不到任务文件。启动时显式指定文件路径就可以locust -f test_something.py另外注意如果你在子目录里运行locust命令而locustfile.py在父目录也可以用相对路径定位。我个人的习惯是所有压测脚本统一放一个目录启动命令里写清楚-f参数不依赖默认命名。5.3 压测目标响应太慢导致本地机器卡死当你的压测目标接口响应很慢而你又开了大并发Locust本机会积累大量等待中的协程内存占用会一直往上涨。我曾经压一个第三方接口响应时间超过30秒并发开到500自己的笔记本风扇直接起飞最后把Web UI都卡死了。这种场景下建议做两件事第一把wait_time调低减少本地模拟用户“排队”时间第二用无头模式压测并限制运行时长至少不要让压测任务无限期跑下去。另外分布式压测是一个方向但对你当前阶段来说先把单机压测的“度”把握好更重要。5.4 结果数据差异过大不知道信谁的有一次我分别用JMeter和Locust压同一个接口得出的RPS差了将近一倍。很多人遇到这种情况会怀疑工具不准但其实根本不是工具的问题而是压测策略不同。JMeter的线程组默认是全部启动完成后同时开跑Locust的并发用户启动速率则由spawn rate控制会有一个爬坡期。如果压测时长太短比如只跑5秒启动爬坡就占掉了大半时间结果自然偏保守。我的建议是压测持续时间要至少是启动时间的三倍以上才有足够的数据积累。比如用-r 10每秒启动10个用户100个用户需要10秒启动完那运行时间至少给到30到60秒。另一个常见差异点是Think Time的设定。JMeter里可能用固定延迟Locust用随机延迟这也会对最终RPS和响应时间产生影响。所以如果要跨工具对比结果务必统一策略再比。5.5 CtrlC后进程没有干净退出在Web UI模式下如果压测进行中你直接关闭终端有时会发现端口被占用或者后端的压测进程还活着。我遇到的场景是本地开发机上压到一半想停终端卡住按CtrlC没反应最后只能开新窗口把进程杀掉。其实Locust在Web UI界面上有“Stop”按钮可以优雅地停止压测。无头模式下按两次CtrlC可以强制退出。如果你在自动化脚本里需要以非阻塞方式启动或停止Locust建议用--run-time设置好自动结束时间或者通过API接口来控制而不是用暴力kill。6. 从安装到跑通其实只差一个“带着目标动手”我在最开始提到这个项目标题是“软件测试 1 性能测试 Locust简介安装”其实这背后藏着一条很清晰的学习路线先理解性能测试在软件测试体系中的位置再选定一个工具最后把它真正装起来跑起来。Locust只是这条路的第一块敲门砖但它能帮你建立起“压测是一个可编码、可沉淀、可自动化的工程活动”的认知。以我个人经验来说装Locust最大的价值不在于“装了个新工具”而在于让我开始不自觉地区分“用什么工具”和“为什么要压”这两个问题。工具只是手段判断系统能不能撑住业务压力、瓶颈在哪、怎么优化才是性能测试的核心。如果你照着这篇文章把环境搭好、把demo跑起来我建议下一步再往前走一步找一个你自己负责的系统选一个关键接口定好阈值用无头模式跑一轮并导出CSV试着分析一下P95和错误率。等你亲手完成这一圈你对软件测试中性能测试的认知就不停留在面试八股上了。
从安装到实战：Locust性能测试工具入门指南
1. 从想压测到真正打开压测大门最近在带团队做一个小型电商项目上线前的稳定性评估Leader丢给我一句“做个性能测试看看瓶颈”我第一反应其实和很多人一样直接去翻之前项目里别人留下的JMeter脚本。但那个脚本是用老版本JMeter配了一堆插件打开全是红叉BeanShell里还留着上上个人写的乱码注释。我花了一个下午在“修脚本”而不是“做测试”那感觉实在太糟糕了。后来我换了思路既然要重写为什么不用Locust反正纯Python代码可控、分布式天然支持、报告直观而且我们本来就是Python技术栈。这一换确实打开了新大门。这篇文章就锁定软件测试领域里最常被问到的性能测试工具之一Locust。我会从“到底是什么”“为什么值得用”“怎么装”“装完怎么快速跑起来”四个维度来拆确保你跟着走一遍就能在本地完整跑起第一个压测demo。适合谁来读准备入行软件测试的应届生、已经会用JMeter但想了解Python系压测工具的测试工程师、开发自测接口性能的后端同学。不需要你有多深的Python功底但最好对HTTP接口有个基本概念。如果你已经能独立用JMeter做一个并发压测并分析聚合报告那这篇文章对你来说更像“无缝迁移指南”。2. Locust到底是做什么的和JMeter比差在哪2.1 核心思路用代码描述用户行为Locust的中文直译是“蝗虫”暗含一群蝗虫式并发压向目标这个意象很直观。它的设计理念如果用一句话概括就是**“压测场景即代码”**。传统工具比如JMeter里你通过图形界面拖拽组件去构建一个线程组再添加HTTP请求、断言、监听器。图形化最大的问题是一旦场景复杂或者团队需要版本管理、多人协作界面里的“脚本”没法像代码一样做diff、做Code Review。而Locust完全反过来它的压测场景就是一个Python文件你定义一个类继承User在里面用task装饰器声明接口行为。整个文件就是普通Python代码可以进Git可以走CI/CD流水线。我个人对这套设计最大的感受是它把“压测”从一个黑盒操作变成了一个白盒编程活动。你可以直接import项目的公共库自定义请求参数生成逻辑动态读取数据甚至写断言逻辑。这在JMeter里往往要靠BeanShell或者JSR223脚本才能实现而Locust本身就用Python写业务逻辑学习曲线其实是平的。2.2 Locust和JMeter的选型对照我把几个关键维度列成一张表方便你根据自己团队情况做选择题维度LocustJMeter脚本形态Python代码XML格式图形界面编辑上手门槛需要基本Python语法纯界面拖拽零代码起步更快分布式支持内置Master/Slave节点天然支持需要额外配置Agent和远程启动稍繁琐扩展性可通过Python自定义一切通过插件体系扩展但插件质量参差报告能力提供Web UI实时图表数据分析靠自定义导出聚合报告成熟插件生态有大量图表方案资源占用基于协程gevent单进程可模拟大量用户每线程占用较高压大规模需要较多机器适用场景接口级、Python技术栈、持续集成友好全场景、复杂协议如JDBC、JMS、已有成熟团队需要注意一个常见误区Locust不是“比JMeter更厉害的工具”而是“不同设计哲学下的工具”。如果你的压测需求很固定、团队没人写Python、或者要压数据库/JMS这类非HTTP协议那JMeter依然是更稳妥的选择。但如果你面对的是微服务接口、Web站点、RESTful API而且你们团队有代码素养Locust这套“性能脚本即代码”的思路会更香。2.3 到底哪些项目适合用Locust从我的项目经验看适合Locust的场景有这么几类第一类接口快速验证型。比如开发说某个接口优化了你要在五分钟内验证一下吞吐量有没有提升。这种时候根本不需要搭建完整的JMeter工程直接写个十来行的Locust脚本压一把就出结果。第二类需要动态压测数据的场景。比如业务请求体里需要签名参数、时间戳、随机用户ID用Python代码处理这类动态参数比用JMeter的“函数助手”更自由。第三类与CI/CD流水线集成。比如每次发布前自动跑一遍轻量冒烟压测如果P95延迟不达标流水线直接标红。代码形态的脚本天然适合挂在Jenkins或GitLab CI上。所以如果你正好在软件测试入门或转岗节点上我的建议是JMeter必须要有一定基础但Locust可以作为你拉开差异化、提高效率的秘密武器。3. 为什么说Locust安装其实是个很讲究的过程3.1 第一步Python环境准备先说明一个我踩过的坑Locust目前对Python版本有明确要求官方长期支持Python 3.9到3.12这些主流版本但你直接用系统自带的Python环境装很容易把依赖搞乱。我强烈建议用一个独立的虚拟环境来跑Locust和你的项目环境隔离这样即使项目依赖冲突也不影响压测环境。在Windows、macOS、Linux各平台上我的推荐姿势是这样# 创建虚拟环境目录名可以自己定 python3 -m venv locust-env # 激活虚拟环境 # Windows: locust-env\Scripts\activate # macOS / Linux: source locust-env/bin/activate装完虚拟环境后再检查一下Python版本python --version pip --version如果输出版本在范围内环境就算“能用”了。别小看这个步骤我曾经见过有人在系统Python全局环境里面直接pip install locust结果跟公司内部某个包冲突连Django都起不来了最后花了半天才排查到是gevent版本被顶掉了。3.2 第二步pip安装Locust虚拟环境激活后安装命令极其简单pip install locust如果你在的企业网速一般或者缺省PyPI源访问慢可以指定国内镜像源pip install locust -i https://pypi.tuna.tsinghua.edu.cn/simple安装完成后验证版本locust --version正常会输出类似locust 2.31.0的版本号。看到这里你的Locust其实已经“装好了”剩下就是怎么确定它真的能正常工作。这里我要额外提一个理念Locust安装完成只是开始真正的“安装工程”还包括确认依赖的gevent版本是否和Python匹配、是否能用Web UI模式启动、以及能不能无头模式跑起来。这也是很多新手装了但跑不起来、然后以为是安装失败的根本原因。所以我下面的内容会用一个最小demo把“装好”这件事彻底落地。3.3 第三步验证安装是否成功安装成功后最直接的验证方式是直接启动一个最简单的压测文件。先新建一个测试目录比如locust-demo在里面新建一个Python文件叫locustfile.pyfrom locust import HttpUser, task class QuickUser(HttpUser): task def visit_index(self): self.client.get(/)然后在同一个目录下运行locust如果你的终端输出了类似这样的信息就说明安装完全没问题Starting web interface at http://0.0.0.0:8089这时候浏览器打开http://localhost:8089能看到一个Web压测控制面板说明你的Locust环境已经OK了。真到这一步安装才算真正“闭环成功”。4. 快速跑通你的第一个压测demo4.1 从写一个真正的压测脚本开始光能启动不算本事能压出报告才算。我们直接写一个稍完整的demo目标是对一个接口做并发测试。假设你的被测系统是本地起的服务比如http://localhost:8000我们再模拟一个常见的业务场景首页访问用户登录。新建一个locustfile.py内容如下from locust import HttpUser, task, between import random class WebsiteUser(HttpUser): # 模拟真实用户在每个任务之间的思考时间 wait_time between(1, 3) task(3) def load_homepage(self): # 权重为3意味着整体请求中首页访问占比更高 self.client.get(/) task(1) def load_login(self): # 模拟登录接口POST一个随机用户名 username fuser_{random.randint(1, 10000)} self.client.post(/login, json{ username: username, password: 123456 })文件里有几个关键点HttpUser代表一类执行任务的“用户”Locust会为每个模拟用户生成一个协程。wait_time用来模拟用户思考时间这里的between(1, 3)是1到3秒随机。思考时间直接决定你的压测“真实度”压一个真实场景如果完全没有思考时间结果往往会偏乐观。task装饰器声明任务支持传入权重。权重越高被选中执行的概率越高。这个脚本就是我们的压测入口。不需要写复杂的配置文件也不需要像JMeter那样为每个请求配一堆监听器。4.2 启动压测的两种方式Locust启动方式主要有两种Web UI模式和无头模式。Web UI模式最直观直接运行locust然后打开http://localhost:8089你会看到一个表单填写三样东西被测地址Host比如http://localhost:8000并发用户数Number of users比如100每秒启动用户数Spawn rate比如10点击“Start swarming”压力就开始顶上去了。Web UI里能看到实时RPS、响应时间、失败率等曲线。这种模式适合探索性压测因为你可以一边看指标一边调并发数非常有“现场感”。无头模式适合自动化比如集成到CI里跑locust --headless -u 100 -r 10 -H http://localhost:8000 --run-time 30s参数含义--headless无界面模式-u 100模拟100个并发用户-r 10每秒启动10个用户逐渐达到100-H指定被测系统地址--run-time 30s总共运行30秒无头模式跑完终端会输出一段统计汇总包括请求总数、每秒请求数、平均响应时间、P50/P90/P95/P99等。这些数据已经足够做一轮快速判断我建议你在自动化场景下直接用它然后把结果以结构化格式导出方便后续生成报告。4.3 用阈值判断你的接口到底行不行很多刚做压测的同学有个问题看了一堆指标却不知道什么算“好”什么算“坏”。其实性能测试讲究的是“有目标地测”没有SLA的压测等于瞎压。我一般会在压测前和业务方、开发定好三个阈值并发数目标支撑多少用户同时在线使用P95响应时间比如要求95%的请求在500ms内返回错误率比如低于0.1%如果你压测结果P95超过2000ms哪怕接口没报错站在用户体验角度这已经算“性能瓶颈”了。反过来如果P95在300ms内错误率几乎为0那么当前并发数下系统就是稳的。用这个标准判断你的压测结果就能直接指导上线上决策。我习惯在无头模式下加上--csvresult参数让Locust额外产出CSV文件再用Python脚本或Excel透视表做汇总。这个习惯帮我避免过很多“凭感觉下结论”的情况。5. 新手最常踩的5个坑和排查思路5.1 安装时gevent编译报错Locust底层依赖gevent在某些Python版本或系统环境下gevent需要本地编译可能出现缺少编译器的错误。比如Windows上提示error: Microsoft Visual C 14.0 is required。解决办法有两种一是安装之前先升级pip和setuptoolspip install --upgrade pip setuptools二是直接使用预编译的二进制包pip install --only-binary :all: gevent如果你用的是Python 3.12现在Locust官方已经适配得比较好基本不会遇到编译问题。但如果你的项目还在用Python 3.8以下老版本我建议直接换成3.10或3.11省心得多。5.2 启动locust提示找不到locustfile这个坑我见过不止一次。Locust默认会找当前目录下的locustfile.py文件如果你的文件叫别的名字比如test_something.py或者文件在子目录里直接运行locust就会提示找不到任务文件。启动时显式指定文件路径就可以locust -f test_something.py另外注意如果你在子目录里运行locust命令而locustfile.py在父目录也可以用相对路径定位。我个人的习惯是所有压测脚本统一放一个目录启动命令里写清楚-f参数不依赖默认命名。5.3 压测目标响应太慢导致本地机器卡死当你的压测目标接口响应很慢而你又开了大并发Locust本机会积累大量等待中的协程内存占用会一直往上涨。我曾经压一个第三方接口响应时间超过30秒并发开到500自己的笔记本风扇直接起飞最后把Web UI都卡死了。这种场景下建议做两件事第一把wait_time调低减少本地模拟用户“排队”时间第二用无头模式压测并限制运行时长至少不要让压测任务无限期跑下去。另外分布式压测是一个方向但对你当前阶段来说先把单机压测的“度”把握好更重要。5.4 结果数据差异过大不知道信谁的有一次我分别用JMeter和Locust压同一个接口得出的RPS差了将近一倍。很多人遇到这种情况会怀疑工具不准但其实根本不是工具的问题而是压测策略不同。JMeter的线程组默认是全部启动完成后同时开跑Locust的并发用户启动速率则由spawn rate控制会有一个爬坡期。如果压测时长太短比如只跑5秒启动爬坡就占掉了大半时间结果自然偏保守。我的建议是压测持续时间要至少是启动时间的三倍以上才有足够的数据积累。比如用-r 10每秒启动10个用户100个用户需要10秒启动完那运行时间至少给到30到60秒。另一个常见差异点是Think Time的设定。JMeter里可能用固定延迟Locust用随机延迟这也会对最终RPS和响应时间产生影响。所以如果要跨工具对比结果务必统一策略再比。5.5 CtrlC后进程没有干净退出在Web UI模式下如果压测进行中你直接关闭终端有时会发现端口被占用或者后端的压测进程还活着。我遇到的场景是本地开发机上压到一半想停终端卡住按CtrlC没反应最后只能开新窗口把进程杀掉。其实Locust在Web UI界面上有“Stop”按钮可以优雅地停止压测。无头模式下按两次CtrlC可以强制退出。如果你在自动化脚本里需要以非阻塞方式启动或停止Locust建议用--run-time设置好自动结束时间或者通过API接口来控制而不是用暴力kill。6. 从安装到跑通其实只差一个“带着目标动手”我在最开始提到这个项目标题是“软件测试 1 性能测试 Locust简介安装”其实这背后藏着一条很清晰的学习路线先理解性能测试在软件测试体系中的位置再选定一个工具最后把它真正装起来跑起来。Locust只是这条路的第一块敲门砖但它能帮你建立起“压测是一个可编码、可沉淀、可自动化的工程活动”的认知。以我个人经验来说装Locust最大的价值不在于“装了个新工具”而在于让我开始不自觉地区分“用什么工具”和“为什么要压”这两个问题。工具只是手段判断系统能不能撑住业务压力、瓶颈在哪、怎么优化才是性能测试的核心。如果你照着这篇文章把环境搭好、把demo跑起来我建议下一步再往前走一步找一个你自己负责的系统选一个关键接口定好阈值用无头模式跑一轮并导出CSV试着分析一下P95和错误率。等你亲手完成这一圈你对软件测试中性能测试的认知就不停留在面试八股上了。
