性能测试 on 测试开发刚哥

Locust性能测试工具核心技术@task和@events

Sun, 18 Jan 2026 00:00:00 +0000

Tasks和Events是Locust性能测试工具的核心技术，有了它们，Locust才能称得上是一个性能工具。

locustfile中的User类和HttpUser类

Sat, 17 Jan 2026 00:00:00 +0000

locustfile是什么？

locustfile是Locust性能测试工具的用户脚本，描述了单个用户的行为。

locustfile是个普通的Python模块，如果写作locustfile.py，那么路径切换到文件所在目录，直接执行命令就能运行：

$ locust

如果换个名字，那么只能通过-f参数指定文件名运行：

$ locust -f locust_files/my_locust_file.py

与一般Python模块不同的是：locustfile必须至少定义一个类，且继承自User类。

User类

User类表示性能测试的模拟用户，Locust会在运行时创建User类的实例。

wait_time属性

设置等待时间，默认值不等待，立即执行。

Locust支持4种方式设置wait_time属性。

constant函数，常量，任务执行完毕等待X秒开始下一任务。

def constant(wait_time):
    """
    Returns a function that just returns the number specified by the wait_time argument

    Example::

        class MyUser(User):
            wait_time = constant(3)
    """
    return lambda instance: wait_time

between函数，区间随机值，任务执行完毕等待X-Y秒（中间随机取值）开始下一任务。

def between(min_wait, max_wait):
    """
    Returns a function that will return a random number between min_wait and max_wait.

    Example::

        class MyUser(User):
            # wait between 3.0 and 10.5 seconds after each task
            wait_time = between(3.0, 10.5)
    """
    return lambda instance: min_wait + random.random() * (max_wait - min_wait)

constant_pacing函数，自适应，若任务耗时超过该时间，则任务结束后立即执行下一任务；若任务耗时不超过该时间，则等待达到该时间后执行下一任务。

def constant_pacing(wait_time):
    """
    Returns a function that will track the run time of the tasks, and for each time it's
    called it will return a wait time that will try to make the total time between task
    execution equal to the time specified by the wait_time argument.

    In the following example the task will always be executed once every second, no matter
    the task execution time::

        class MyUser(User):
            wait_time = constant_pacing(1)
            @task
            def my_task(self):
                time.sleep(random.random())

    If a task execution exceeds the specified wait_time, the wait will be 0 before starting
    the next task.
    """

    def wait_time_func(self):
        if not hasattr(self, "_cp_last_run"):
            self._cp_last_wait_time = wait_time
            self._cp_last_run = time()
            return wait_time
        else:
            run_time = time() - self._cp_last_run - self._cp_last_wait_time
            self._cp_last_wait_time = max(0, wait_time - run_time)
            self._cp_last_run = time()
            return self._cp_last_wait_time

    return wait_time_func

自定义wait_time方法，比如每次等待时间1秒2秒3秒递增：

class MyUser(User):
    last_wait_time = 0

    def wait_time(self):
        self.last_wait_time += 1
        return self.last_wait_time

    ...

Python技术栈性能测试工具Locust入门

Fri, 16 Jan 2026 00:00:00 +0000

Locust是一款Python技术栈的开源的性能测试工具。Locust直译为蝗虫，寓意着它能产生蝗虫般成千上万的并发用户：

性能测试指标TP99，比平均响应时间更需要关注

Thu, 15 Jan 2026 00:00:00 +0000

什么是TP99？

TP是Top Percentile的首字母缩写，TP99是指“前百分之九十九”，用来表示满足百分之九十九的网络请求所需的最低耗时。

该怎么理解？举个简单例子，下图是100次请求的响应时间走势图：

第23次请求的响应时间为600ms，其他请求的响应全部为1ms，这个走势图也就是常说的“尖刺”。我们来计算一下：

①平均响应时间

平均响应时间 = 所有请求响应时间之和 / 请求次数，等于6.99ms

②TP99

TP99 = 把响应时间从小到大排列，取第99%那个位置的值，等于1ms

为什么TP99更需要关注？

平均响应时间受极端值的影响较大，因为出现1个尖刺，平均响应时间几乎是TP99的7倍！

TP99更能反映大多数请求的情况，通过TP99为1ms可以知道，应用系统对于大多数请求，都能在1ms内响应，整体性能达标。而对于尖刺，我们可以通过走势图的MAX来发现，单独进行分析。

在JMeter的Aggregate Report中，有3个字段：90% Line、95% Line、99%Line

其实就是指TP90、TP95、TP99。此外，在实际工作中，我们还会关注TP999，三个九，也就是99.9%。关注TP多少，取决于我们对性能的要求怎么样，我们希望应用系统满足多少请求。如果对性能要求不高，关注TP90就够了，允许10%请求出现波动。如果对性能要求很高，则需要关注TP999，99.9%请求都能够快速响应。

你的下一个压测工具可以是nGrinder

Wed, 14 Jan 2026 00:00:00 +0000

nGrinder小众而实用

nGrinder在GitHub的star有1.6k，相比于JMeter6.4k来说，要少很多。在测试资料中，关于压测工具也是以JMeter居多，几乎没有专门针对nGrinder的学习资料。nGrinder既然这么小众，那为什么还要学它呢？因为听说咱们公司的压测平台，底层就是用的nGrinder，对于企业级应用来说，nGrinder还是很实用的，正如它的介绍：“Enterprise level performance testing solution based on The Grinder”。

nGrinder有以下特点：

我们编写压测脚本用到的就是第一个特点提到的Groovy脚本，跟Java语法类似，可以无成本切换。

设计理念

nGrinder架构

nGrinder系统架构如下：

nGrinder的底层是Grinder，基于Grinder的console和agent，nGrinder封装成了controller和agent：

controller 提供了Web页面创建测试脚本和配置运行策略，这是nGrinder比较突出的特色了。
agent 虚拟用户生成器，创建压测负载。

当用户创建test后，会先创建一个console，AgentControllerServer会根据console分配相应的agent，AgentControllerServer管理着agent pool，负责agent的创建和释放。然后console将test脚本和资源多个已分配的agent，并控制整个test flow直到测试结束。测试结束后，agent会回收至AgentControllerServer以便其他test使用，console也会回收至ConsoleManager。

nGrinder和Ginder最大的不同之处在于，nGrinder在controller中保留了多个console实例和agent。每个console都是跟其他console隔离的，能并发运行。

不像其他压测工具在测试时，会保留agent以确保用户执行test时agent是可用的，也就是“预占”agent。nGrinder只有在真正测试执行时，动态分配agent，这个方案是nGrinder最独特的架构设计。它保证了多个压测任务能并发执行，并发上限只取决于空闲的agent数量。

nGrinder3.1版本以前是单机架构的，如下图所示：

1、nGrinder使用SVNkit，即svn server，来管理脚本文件。svn仓库存放在${NGRINDER_HOME}目录。

2、nGrinder使用EhCache缓存，提升DB和SVN查询性能。

3、nGrinder使用Spring Security保证安全，并使用Atlassian支持扩展。

nGrinder3.1版本之后，支持集群：

1、集群中所有console共享同样的DB和文件系统，并指向NFS共享的同一个${NGRINDER_HOME}。

2、每个controller有它自己的${NGRINDER_EX_HOME}，存放特殊配置和日志。

3、所有controller相互复制EhCache，让某些数据在集群中都是可见的。

nGrinder技术栈

Client层

Bootstrap、Bootstrap-slider、Jquery、Jquery Validate、Datatables、Select2、JqPlot、CodeMirror。

Controller层

FreeMarker、Spring Security、Spring MVC、GSon、SVNKit Dav。

Service层

The Grinder、Atlassian Plugin Framework、Spring、EhCache。

Data层

Spring Data、H2、Cubrid、Liquibase、SVNKit。

快速入门

安装

在GitHub Release下载war包：

https://github.com/naver/ngrinder/releases

执行命令：

java -jar ngrinder-controller-{version}.war

访问http://localhost:8080/即可。

但是由于nGrinder需要占用大量内存，最好加上额外参数：

JMeter扩展Java请求

Tue, 13 Jan 2026 00:00:00 +0000

本文将通过WebRTC本地音视频流压测脚本，来说明JMeter如何扩展Java请求。

JMeter响应断言够用了

Mon, 12 Jan 2026 00:00:00 +0000

JMeter断言用来对服务器的响应数据进行验证，其中的响应断言基本能完成大多数的验证工作，但是JMeter还是提供了适用于多个不同场景的断言元件，一共16个，如下图所示：

JMeter定时器设置延迟与同步

Sun, 11 Jan 2026 00:00:00 +0000

JMeter定时器一般用来设置延迟与同步。它的作用域和优先级如下：

JMeter逻辑控制器完整介绍

Sat, 10 Jan 2026 00:00:00 +0000

JMeter逻辑控制器可以对元件的执行逻辑进行控制，就像编程一样，实现业务需求。

JMeter36个内置函数及11个新增函数介绍

Fri, 09 Jan 2026 00:00:00 +0000

JMeter内置了36个函数，这些函数可以通过函数助手进行编辑和测试。了解这些函数，不仅能提高JMeter的使用熟练度，也有助于知晓测试工具或测试框架通用的函数有哪些，在自主设计时，作为参考借鉴。

JMeter四种参数化方式

Thu, 08 Jan 2026 00:00:00 +0000

JMeter参数化是指把固定的数据动态化，这样更贴合实际的模拟用户请求，比如模拟多个不同账号。JMeter一共有四种参数化方式，分别是：

JMeter关联陌生又熟悉

Wed, 07 Jan 2026 00:00:00 +0000

JMeter关联是什么

JMeter关联，这几个字看着可能会有点陌生，实际上却是工作中经常会做的一件事情，尤其是接口自动化，它指的是把一个接口的响应作为另一个接口的参数，从而把接口关联起来。

JMeter关联是通过后置处理器来实现的，本文将介绍两个主流提取器：正则表达式提取器和JSON JMESPath提取器。

正则表达式提取器

Name

最好有业务含义的名称。

Comments

可以为空的注释。

Apply to

匹配范围。

Main sample and sub-samples

匹配当前父取样器及其子取样器。

Main sample only

仅匹配当前父取样器。

Sub-samples only

仅匹配子取样器。

JMeter Variable Name to use

匹配JMeter变量。

Field to check

匹配响应的字段，共七个选项。

Body：主体，最常用。

Body(unescaped) ：替换了所有的html转义符的响应主体内容，注意html转义符处理时不考虑上下文，因此可能有不正确的转换，不太建议使用。

Body as a Document：从不同类型的文件中提取文本，注意这个选项比较影响性能。

Response Headers：响应Headers。

Request Headers：请求Headers。

URL：请求URL。

Response Code：响应代码，比如200、404返回码。

Response Message：响应信息，比如“成功”、“OK”字样。

Name of created variable

创建的变量名，比如变量名为token，通过${token}进行访问。

Regular Expression

正则表达式。

Template( $i$ where i is capturing group number, starts at 1)

用$$引用起来，如果在正则表达式中有多个正则表达式（多个括号括起来的），则可以是 $1$ 、 $2$ 等等， $1$ 指第一个模板， $2$ 指第二个模板，依次类推， $0$ 指全文匹配，$1$$2$指同时取第一个和第二个模板。

JMeter100个线程竟然只模拟出1个并发

Tue, 06 Jan 2026 00:00:00 +0000

线程组编辑区如下：

JMeter测试计划配置项解析

Mon, 05 Jan 2026 00:00:00 +0000

测试计划（Test Plan），是JMeter目录树的初始根节点，它的编辑区如下：

JMeter元件作用域实践指南

Sun, 04 Jan 2026 00:00:00 +0000

从一个问题说起

对于以下测试脚本：

为了能调用进入房间接口，需要从考场接口获取考场token。为了调用考场接口，需要从登陆接口获取登陆token。元件说明如下：

学生登录，提取登录${token}传入下个接口参数。
添加HTTP Header Manager：
考场token，提取考场${exam_token}传入下个接口参数。
添加HTTP Header Manager：
进入房间

貌似挺合理，HTTP Header Manager会给下方的接口添加请求头，运行结果真的如我们所料么？

运行顺序

在回答这个问题之前，有必要搞懂JMeter元件的运行顺序，它是由2 个维度来决定的：从上往下和元件类型。

从上往下，即目录树从上往下。元件类型，分为3类：

线程组、逻辑控制器。
取样器。
配置元件、前置处理器、定时器、后置处理器、断言、监听器。

它们的运行顺序如下：

配置元件（如果存在）
前置处理器（如果存在）
定时器（如果存在）
取样器（如果存在）
后置处理器（如果存在且取样器的结果不为空）
断言（如果存在且取样器的结果不为空）
监听器（如果存在且取样器的结果不为空）

换句话说，假设我们新建了1个线程，想用这个线程去发请求。

第一步，初始化配置，比如参数化、设置Header、Cookie等，用到配置元件。

第二步，可能需要给线程加点参数，比如用户参数，用到前置处理器。

第三步，在发送请求前可能会等待一段时间，用到定时器。

第四步，发送请求，用到取样器。

第五步，可能需要提取响应数据，比如正则表达式提取器、JMESPath提取器，用到后置处理器。

第六步，验证结果符合预期，用到断言。

第七步，查看请求响应数据和测试结果，用到监听器。

实践指南

对于以下所列元件：

JMeter会按以下步骤运行：

线程组（如果有多个线程组可以在测试计划设置是顺序执行还是同时执行）
简单控制器（父节点）
HTTP Cookie管理器（配置元件）
用户参数（前置处理器）
Synchronizing Timer（定时器）
HTTP 请求1（取样器）
正则表达式提取器（后置处理器）
响应断言（断言）
HTTP Cookie管理器（配置元件）
用户参数（前置处理器）
Synchronizing Timer（定时器）
HTTP 请求2（取样器）
正则表达式提取器（后置处理器）
响应断言（断言）
HTTP 请求3（取样器）
察看结果树（严格来讲是与第 6 步并行，也就是取样器之后）

作用域

其中有个观察作用域实际效果的关键元件：HTTP请求2，它的前后并没有元件，但是也被作用上了。在JMeter中，同一层级的元件具有相同的作用域！

JMeter英文版界面介绍

Sat, 03 Jan 2026 00:00:00 +0000

JMeter的界面虽然不华丽，但是使用起来还是很便利。本文将基于英文版界面对整个可视区域进行介绍，如果想看中文版，请在菜单栏点击Choose Language切换：

JMeter是如何运行施压的

Fri, 02 Jan 2026 00:00:00 +0000

运行文件

JMeter下载地址为：

https://jmeter.apache.org/download_jmeter.cgi

最新版本为5.4.1，依赖于Java8+，下载后无需安装，解压即用。解压后的目录和文件如下：

bin 二进制文件目录，包括配置文件、启动文件、启动jar包、示例脚本。比如Windows和Linux系统的两个启动脚本：

docs API离线帮助文档。
extras 辅助功能，可用于Ant、Jenkins集成。
lib lib根目录下存放JMeter基础jar包，lib/ext目录下存放第三方或自定义扩展jar包。
licenses 证书文本文件。
printable_docs 离线帮助文档。
LICENSE 证书说明。
NOTICE 版权声明。
README 简介。

测试计划

JMeter以图形界面方式启动后，首先映入眼帘的是左侧的TestPlan，测试计划：

JMeter的UI界面只能同时编辑一个测试计划，如果想再编辑另外一个测试计划，必须再打开一个JMeter界面。这是因为测试计划对应的是.jmx文件！不同的.jmx文件只能在不同的界面中编辑。

JMeter界面是通过组件拖拽的方式来编写脚本的，脚本的根目录是测试计划。根节点只能有一个，作为根节点，测试计划很适合来做全局配置，比如在User Defined Variables处添加键值对格式的全局变量。

测试计划是默认节点，JMeter还有另外一个不可缺少的次节点：Thread Group，线程组。

多线程

性能测试工具的目的是用少量电脑产生成百上千个并发请求。多进程和多线程正好能用来实现这个需求，书上有句关于进程和线程的至理名言：“进程是操作系统分配资源的最小单位，线程是程序执行的最小单位”。该如何理解呢？前一句的意思是说，每个应用程序都有对应的进程，按照进程来分配资源，可以使得资源利用最大化，避免浪费。后一句的理解得从一个故事讲起，很久以前，进程拿着资源找CPU执行。CPU一看进程太大，说我处理不了。进程只能拆成多个线程给CPU，不但能执行了，还能在线程之间灵活切换。

多进程和多线程都可以用来模拟并发请求。JMeter是用Java语言写的程序，运行在JVM虚拟机之上，进程的开销比线程大很多，JVM为了保证足够性能，控制了进程的数量。如果用多线程，单台电脑能提供了负载有限，那么就只能用多线程。JMeter只支持多线程！

用户即线程

JMeter除了Thread Group，其他地方都是用的另外一个词：User。实际上它们是一个意思，用户就是线程。JMeter的运行原理就是用多个线程来模拟多个用户！以下是简单示例：

从图中可以看出，有两个线程组，Thread Group 1和Thread Group 2，它们分别定义了自己组内的用户要做的事情。不同线程组做的事情是不一样的，但是同一线程组内部做的事情是一模一样的。我们在写JMeter脚本的时候，实际上是在定义每个用户要做哪些事。当运行脚本的时候，JMeter会启动多个线程，都来执行这个脚本，按照我们写的进行执行。

远程运行

一台机器提供了线程数量有限，如果想要施压更大的并发，那么就需要多台机器。JMeter天然支持多台机器并发：

控制机和负载机本质上没有区别，同一台机器既可以做控制机，也可以做负载机，取决于你的负载设计。控制机的作用是管理多台远程负载机，控制远程负载机脚本运行，收集远程负载机测试结果。负载机是实际产生并发的机器，它们向被测应用系统发起负载。

运行逻辑如下：

远程负载机启动Agent客户端，等待控制机连接。
控制机连接上远程负载机。
控制机发送指令到远程负载机启动线程。
远程负载机运行脚本，回传结果数据。
控制机收集结果并显示。

操作步骤如下：

远程负载机启动jmeter-server.bat。
在控制机bin\JMeter.properties文件中，修改remote_hosts，添加远程负载机的ip和port，多个远程负载机ip 用逗号分隔，如remote_hosts=192.168.0.1:1664,192.168.0.2:1664。1664是默认RMI端口号（Remote Method Invocation，远程方法调用）。
在控制机菜单栏Run执行Remote命令：

小结

本文先从JMeter运行文件讲起，启动后默认有测试计划，建线程组，线程即用户，用多线程来模拟多用户，这就是JMeter运行起来施压的原理。为了解决单台机器负载能力有限的问题，JMeter还提供了远程运行方式，既可以在局域网用多台机器来控制，也可以部署到云服务器上，进行云压测。

JMeter全部组件概览

Thu, 01 Jan 2026 00:00:00 +0000

JMeter是性能测试工具，在使用JMeter变多以后，越来越觉得之所以它能成为当今时代最主流测试工具，是因为它太成熟了，举个小例子，编写GET请求的时候，需要把查询参数，也就是?号后面的请求参数添加进去，JMeter竟然有个Add from Clipboard功能，在浏览器复制以后，点这个按钮就填充好了: