1. Teoría de las pruebas de rendimiento
1.1 ¿Qué tipo de sistema necesita pruebas de rendimiento?
- Un sistema con gran número de usuarios y alto PV
- Módulos/interfaces centrales del sistema
- La lógica/algoritmo empresarial es relativamente complejo
- Plan de promoción/promoción de eventos
- Nuevos sistemas, nuevos proyectos.
- Verificación y ajuste de problemas de rendimiento en línea
- Selección de nueva tecnología.
- Evaluación y planificación de la capacidad de desempeño (para la evaluación de la capacidad, estime la capacidad específica)
- Regresión diaria del rendimiento del sistema
1.2 Indicadores de prueba de desempeño
- asuntos
- En el campo de las pruebas de rendimiento, medir el rendimiento de un sistema depende principalmente de cuánto negocio puede manejar el sistema por unidad de tiempo.
- Una transacción representa una operación comercial. Una transacción puede representar un negocio o múltiples operaciones comerciales.
- TPS/QPS: Número de transacciones procesadas por segundo
- Tiempo de respuesta
- Tiempo de respuesta = tiempo total de transmisión de la red + tiempo de procesamiento comercial de cada componente
- Tiempo medio de respuesta: el tiempo medio que tardan todas las solicitudes durante la prueba. (PD: cuando el número de muestras es pequeño, use el valor promedio para observar los datos y las conclusiones extraídas serán anormales, por ejemplo: una interfaz es de 1 ms y la otra es de 1 s, y el valor promedio no es razonable)
- Tiempo de respuesta SUPERIOR
- Tp90 (90% tiempo de respuesta): el 90% de las solicitudes tardan menos de un tiempo determinado
- Tp95 (95% de tiempo de respuesta): el 95% de las solicitudes tardan menos de un tiempo determinado
- Tp99 (99% de tiempo de respuesta): el 99% de las solicitudes tardan menos de un tiempo determinado
- Algoritmo: ordene los tiempos de respuesta de todas las solicitudes de mayor a menor y calcule la proporción especificada de solicitudes que duran menos de un tiempo determinado. Esta métrica mide el tiempo que tardan la mayoría de las solicitudes.
Tome Tp90 como ejemplo
| La interfaz A responde 10 veces seguidas | Solicitar número de serie | Tiempo de respuesta ms |
|---|---|---|
| 1 | 800 | |
| 2 | 600 | |
| 3 | 500 | |
| 4 | 900 | |
| 5 | 950 | |
| 6 | 750 | |
| 7 | 400 | |
| 8 | 500 | |
| 9 | 300 | |
| 10 | 500 |
Paso 1: ordenar la lista en orden descendente
| La interfaz A responde 10 veces seguidas | Solicitar número de serie | Tiempo de respuesta ms |
|---|---|---|
| 5 | 950 | |
| 4 | 900 | |
| 1 | 800 | |
| 6 | 750 | |
| 2 | 600 | |
| 3 | 500 | |
| 8 | 500 | |
| 10 | 500 | |
| 7 | 400 | |
| 9 | 300 |
90%*10=9, del último al noveno están todos por debajo de 900 ms, por lo que se utiliza 900 ms como línea divisoria
- El tiempo de respuesta general de las interfaces de alta frecuencia es de 200 ms, el tiempo de respuesta general de las interfaces de baja frecuencia es de 100 ms y las interfaces en el último segundo deben optimizarse; no es necesario probar los recursos estáticos y se almacenan en CDN
- Número de usuarios virtuales/concurrentes: el número de subprocesos/procesos simultáneos establecidos en la herramienta de prueba de estrés
- Tasa de éxito: la tasa de éxito de la solicitud.
- PV (vista de página): el número de visitas a la página/interfaz
- UV (Unique Visitor): el visitante único diario de la página/interfaz
- Rendimiento: la suma del tráfico ascendente y descendente en la red.
- El rendimiento representa el tráfico de la red: cuanto mayor sea el TPS (solicitudes por segundo), mayor será el rendimiento.
1.2.1 La relación entre TPS, tiempo de respuesta y número de concurrencias
- Antes de que el sistema alcance un cuello de botella en el rendimiento, el TPS es directamente proporcional al número de concurrencias.
- El tiempo de respuesta (unidad: segundos) es la premisa:
- TPS = 1 / tiempo de respuesta * número de concurrencias
- TPS = número de concurrencias/tiempo de respuesta
- Después de ejecutar la prueba de rendimiento, puede calcular el TPS a partir de los resultados. Si los valores no son muy diferentes, los resultados son apropiados.
- Si hay varias interfaces al mismo tiempo, es necesario sumar el tiempo de respuesta de cada interfaz.
-
1.3 Indicadores de seguimiento del desempeño
- Nivel de monitoreo del sistema operativo
- Uso de CPU, uso de memoria, IO de red (entrada/salida), disco (lectura/escritura/utilidad)
- Monitoreo de software intermedio
- Número de conexiones, conexiones largas y cortas, uso de memoria
- Monitoreo de la capa de aplicación
- Estado del hilo, parámetros de JVM, frecuencia de GC, bloqueos
- monitoreo de capa de base de datos
- Número de conexiones, bloqueos, caché, memoria, eficiencia de SQL
1.4 Proceso de prueba de rendimiento
- solicitando investigación
- Alcance de la investigación
- Antecedentes del proyecto
- Rango de prueba
- Lógica empresarial y dirección del flujo de datos (datos: de dónde provienen los datos, si hay algún caché y si se debe llamar a interfaces de terceros; comprender esto ayudará a solucionar problemas)
- Arquitectura del sistema (arquitectura implementada y componentes utilizados, como equilibrio de carga, middleware de mensajes, equilibrio de carga, etc.)
- Información de configuración (configuración de hardware, como núcleos de CPU y memoria, algunas empresas tendrán entornos de prueba de rendimiento, intente mantenerlos consistentes con los en línea)
- Cantidad de datos de prueba (la magnitud debe ser consistente)
- Dependencias externas (simulacro)
- Escenarios de uso del sistema, proporción comercial (como las interfaces de inicio de sesión y registro, definitivamente habrá escenarios simultáneos en escenarios reales, por lo que la proporción comercial puede entenderse como cuántas personas inician sesión y cuántas personas se registran al mismo tiempo)
- Volumen de negocio diario (PV)
- indicadores esperados
- tiempo en línea
- Alcance de la investigación
- Plan de prueba
- Descripción del Proyecto
- Modelo de negocio e indicadores de desempeño (indicadores esperados en la investigación de la demanda)
- Descripción del entorno de prueba
- Recursos de prueba
- Métodos de prueba y principios de diseño de escenarios.
- Prueba de referencia: para encontrar una referencia de rendimiento, generalmente se trata de una serie de operaciones en ejecución únicas y simultáneas a largo plazo; es decir: después de optimizar la interfaz, compárela con los datos antes de la optimización y podrá ver cómo funciona la optimización. Lo es; pero si desea ver el punto de inflexión en el rendimiento, aún necesita usar alta concurrencia para las pruebas de estrés.
- Prueba de carga de transacción única (de uso común) : se refiere a la prueba de negocio único e interfaz única
- Prueba de escenario mixto (de uso común) : como las interfaces de inicio de sesión y registro, primero debe ejecutar una prueba de carga de transacción única para asegurarse de que cada interfaz no tenga ningún problema y luego realizar una prueba de presión de acuerdo con una determinada proporción (obtenida en la investigación de demanda). )
- Pruebas de alta disponibilidad (generalmente para clústeres en línea)
- Método de prueba: cuelgue un nodo en el clúster para verificar si el clúster puede ejecutarse normalmente; luego ejecute el nodo colgado para verificar si el clúster se puede usar normalmente después de reiniciar el nodo
- Prueba de escenario anormal: por ejemplo, en un escenario de red débil, enviar una solicitud, aunque sea una red débil, aún generará una alta concurrencia; hay algunas situaciones anormales, como transacciones en una red débil, la interfaz no se ejecuta durante la primera vez, debido a algún mecanismo y vuelva a ejecutar la interfaz, lo que puede resultar en que se generen dos órdenes.
- Prueba de estabilidad (de uso común) : se requiere una prueba de esfuerzo a largo plazo (como 12 horas) para comprobar si hay problemas como pérdidas de memoria, etc.
- Otras escenas especiales
- Configuración del hardware de configuración del entorno
- Precauciones
- Trate de ser consistente con lo que está en línea
- La versión del sistema es consistente con la versión en línea.
- El entorno de prueba implementa el módulo de unidad en línea más pequeño
- Las configuraciones de aplicaciones, middleware y bases de datos deben ser consistentes con aquellas en línea.
- Otras configuraciones especiales
- Precauciones
- preparación de datos
- Los datos de prueba se dividen en: datos básicos, datos parametrizados
- Método de construcción de datos:
- Interfaz empresarial
- Adecuado para relaciones complejas de tablas de datos
- Ventajas: mejor integridad de los datos
- procedimiento almacenado
- Adecuado para un número reducido de mesas y simplicidad.
- Ventajas: más rápido
- Importación de guiones
- Adecuado para lógica de datos compleja
- El grado de libertad es relativamente alto.
- secuencias de comandos
- Elija una herramienta (Loadrunner, Jmeter, Locust, etc.)
- Seleccionar protocolo (HTTP, TCP, RCP)
- parametrizar
- asociación
- punto de control
- juicio empresarial
- Ejecución de la prueba de estrés
- ejecución distribuida
- monitor
- linux
- JVM
- base de datos
- Resultados de la prueba del teléfono móvil
- análisis de los datos
- Ubicación del cuello de botella
- Regresión de sintonización
- El ajuste del rendimiento requiere que todo el equipo lo complete
- Inténtalo una y otra vez
- Verificación de regresión
- Herramientas de monitoreo
- Solución de problemas de enlace completo
- Análisis de registros
- Aislamiento del módulo
- informe de prueba
1.5 protocolo HTTP
1.5.1 Introducción a http
1. Admite modo cliente/servidor.
2. Simple y rápido: cuando un cliente solicita servicios al servidor, solo necesita transmitir el método y la ruta de la solicitud. Los métodos de solicitud más utilizados incluyen GET, POST, PUT y DELETE. Cada método especifica un tipo diferente de contacto entre el cliente y el servidor.
Debido a la simplicidad del protocolo HTTP, el tamaño del programa del servidor HTTP es pequeño y la velocidad de comunicación es muy rápida.
3. Flexible: HTTP permite la transmisión de cualquier tipo de objeto de datos. El tipo que se transfiere está marcado por Content-Type.
4. Sin conexión: el significado de sin conexión es limitar cada conexión para procesar solo una solicitud. Después de que el servidor procesa la solicitud del cliente y recibe la respuesta del cliente, se desconecta. Este método ahorra tiempo de transmisión.
5. Sin estado: el protocolo HTTP es un protocolo sin estado. Sin estado significa que el protocolo no tiene capacidad de memoria para el procesamiento de transacciones. La falta de estado significa que si el procesamiento posterior requiere la información anterior, ésta debe ser retransmitida, lo que puede resultar en un aumento en la cantidad de datos transferidos por conexión. En cambio, el servidor responde más rápido cuando no necesita información previa.
1.5.2 estructura del protocolo http
consejos:
Preguntas sobre la distinción entre los conceptos de pruebas de estrés, pruebas de carga y pruebas de rendimiento
1. Para los tres conceptos anteriores, no existe un estándar ni una definición unificados en la industria, y existen varios materiales y opiniones diferentes.
2. Para principiantes, estos conceptos se puede ignorar primero.
3. Solo recuerde: todas las pruebas que realiza son pruebas de rendimiento. En las empresas reales,
todas se llaman [pruebas de estrés]. Los propósitos son diferentes y se diseñan diferentes escenarios de prueba debido a los diferentes propósitos.
2.Jmetro
2.1 Instalación y configuración
Sitio web oficial: https://jmeter.apache.org/
1. Configure las variables de entorno Java en esta máquina.
2. Descargue el paquete comprimido del sitio web oficial y descomprímalo en cualquier directorio.
3. Modifique el archivo de configuración y abra jmeter. .properties en el directorio bin de Jmeter Modificar
idioma=zh_CN #Entorno chino e inglés
sampleresult.default.encoding=utf-8 #Evitar caracteres confusos
Ajustar el tamaño del icono
jmeter.toolbar.icons.size=32x32
jmeter.tree.icons.size=32x32
Modificar el tamaño de los datos del cuerpo del mensaje
jsyntaxtextarea.font.family= Hackear
jsyntaxtextarea.font.size=36
Cambie el tamaño del elemento de la interfaz
a verdadero para permitir que
jmeter.hidpi.mode=true
controle el tamaño
jmeter.hidpi.scale.factor=2.0
Si la configuración modificada no tiene efecto, agregue el siguiente código a jmeter.bat
set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.controlFont=Dialog-20
set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.systemFont=Dialog-20
set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.userFont=SansSerif-20
set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.smallFont=SansSerif-20
4. Ingrese al directorio bin de Jmeter y haga doble clic en jmeter.bat para comenzar
2.2 secuencias de comandos
2.2.1 Entrada
Tres tipos de entrada
| Nombre de la interfaz | Tipo de interfaz | parámetro |
|---|---|---|
| El parámetro es clave = valor. | CORREO | nombre de usuario = “123” y contraseña = “123” |
| El parámetro es de tipo json. | CORREO | {nombre de usuario = “123”, contraseña = “123”} |
| El parámetro es clave = tipo json. | CORREO | clave = {nombre de usuario = “123”, contraseña = “123”} |
El segundo tipo: tipo json.
Los parámetros de entrada de tipo json están todos completados [datos del cuerpo del mensaje]. Si los datos del cuerpo del mensaje tienen datos, no puede operar [parámetro] Nota:
el parámetro es de tipo json y debe ser administrado por agregar un encabezado de información http. Para los componentes de configuración, también es necesario prestar atención al dominio efectivo de los componentes de configuración. No todos los parámetros de entrada de la interfaz son de este tipo 
gestión del encabezado de información http: 
PD: informe de error 415, verifique si el encabezado de información está agregado
El tercer método: método conveniente de tipo key=json
: puede pegar directamente desde [Agregar desde el Portapapeles] en la parte inferior
2.2.2 Afirmación
El estado de éxito que se ve en el árbol de resultados es solo para el éxito de la llamada a la interfaz (porque el código de respuesta = 200), pero no puede juzgar si el negocio se ha ejecutado, por lo que se necesita una afirmación.
2.2.2.1 Aserción JSON
1. Agregue una aserción:
Expresión de ruta JSON: $.code representa el nombre del campo de código en JSON (consulte: https://github.com/json-path/JsonPath para obtener más detalles).
Debe verificar adicionalmente el valor de afirmación, la coincidencia como expresión regular 
PD: las afirmaciones también prestan atención a la ubicación donde se almacena el archivo de afirmaciones. Los diferentes niveles de almacenamiento tienen diferentes dominios efectivos. Por ejemplo, si se almacena en la interfaz de inicio de sesión en el camino, solo tendrá efecto para el inicio de sesión. interfaz Si se coloca en la capa más externa, tendrá efecto para todo el dominio.
2. JSON contiene matrices , que se pueden procesar de la siguiente manera:
Ejemplo json:
{
"store": {
"book": [
{
"category": "reference",
"author": "Nigel Rees",
"title": "Sayings of the Century",
"price": 8.95
},
{
"category": "fiction",
"author": "Evelyn Waugh",
"title": "Sword of Honour",
"price": 12.99
},
{
"category": "fiction",
"author": "Herman Melville",
"title": "Moby Dick",
"isbn": "0-553-21311-3",
"price": 8.99
},
{
"category": "fiction",
"author": "J. R. R. Tolkien",
"title": "The Lord of the Rings",
"isbn": "0-395-19395-8",
"price": 22.99
}
],
"bicycle": {
"color": "red",
"price": 19.95
}
},
"expensive": 10
}
Método de procesamiento:
| JsonPath | Resultado |
|---|---|
| $.store.book[*].autor | Los autores de todos los libros. |
| $…autor | Todos los autores |
| $.tienda.* | Todas las cosas, tanto libros como bicicletas. |
| $.tienda…precio | El precio de todo |
| $…libro[2] | el tercer libro |
| $…libro[-2] | El penúltimo libro. |
| $…libro[0,1] | Los dos primeros libros |
| $…libro[:2] | Todos los libros desde el índice 0 (inclusive) hasta el índice 2 (exclusivo) |
| $…libro[1:2] | Todos los libros desde el índice 1 (inclusive) hasta el índice 2 (exclusivo) |
| $…libro[-2:] | dos ultimos libros |
| $…libro[2:] | Todos los libros desde el índice 2 (inclusive) hasta el último |
| $…libro[?(@.isbn)] | Todos los libros con un número ISBN |
| $.tienda.libro[?(@.precio < 10)] | Todos los libros en tienda por menos de 10 |
| Fuera de lugar @ |
$…libro[?(@.precio <= $['caro'])] | Todos los libros en tienda que no son “caros” |
| $…libro[?(@.autor =~ /. REES/i)] | Todos los libros que coinciden con expresiones regulares (ignorar mayúsculas y minúsculas) |
| $… | Dame todo |
| $…libro.longitud() | El número de libros |
2.2.2.2 Aserción de respuesta
Aplicar a :
- Solo muestra principal: esta afirmación es para la solicitud principal.
- main sample and sub-sample：该断言针对主、次请求，例如重定向的场景，可能会使用到该选项
测试字段：选择需要对哪个数据做判断
- 忽略状态：忽略jmeter默认的状态判断，来跑响应断言中对于状态的断言
响应断言模式匹配规则：
- 包括（Contains）：如果响应中包含了指定的字符串，判断为成功，支持正则表达式
- 匹配（Matches）：如果响应完全匹配指定的字符串，判断为成功，支持正则表达式
- 相等（Equals）：如果响应完全匹配指定的字符串，判断为成功，不支持正则表达式
- 字符串（Substring）：如果响应中包含了指定的字符串，判断为成功，不支持正则表达式
- 最常用的是字符串，性能测试只需要判断业务是否跑通，无需写过于复杂的断言
2.2.3 测试计划
定义全局变量，例如域名及端口号
接口中可通过${变量名称}配置
2.2.4 参数化
2.2.4.1 通过【函数助手】生成各种函数
功能位置：工具栏倒数第二个
常用的函数例如：
- 生成随机数：Random函数
输入完范围后，点击【生成】按钮，复制【当前JMeter变量】的语句，粘贴至【参数】的【值】中
- 随机字符串：RandomString
点击【生成】按钮后，${__RandomString(8,abcdefghijklmQ39589fsafdgAAA,)} 函数字符串会自动复制到剪切板
- 时间戳
两个参数皆为可选填，都不填也可，直接点击生成就可以直接用
填了参数
- uuid：
2.2.4.2 文件参数化
1、**CSVRead：**从文本文件中读取数据
优点：该函数适用于使用登录后，仍然需要用这些账号进行一系列操作的压测
第一个参数填文件的绝对路径，第二个参数填第几列，例如下图中：第一列是登录接口的用户名，第二列是密码
注意：接口轮询中使用txt文件中的用户数据数量，取决于线程数的数量
线程数=1时，无论循环次数为几，皆使用文件中的第一条用户数据
线程数=2时，调了两条txt中的用户数据
线程数=4时，重复调用了两遍文件中的两条数据
使用函数生成的参数来替换接口中的参数，如下图中的mobile、password字段
PS：存储函数的变量名
2、CSV Data Set Config
功能添加路径：线程组→添加→配置元件→CSV Data Set Config
- Allow quoted data（是否允许带引号）：选择true，读取中文时会导致参数值出现乱码
文件编码：可以不填
-
如果接口中的参数是用西文逗号隔开的（例如：“user”：“username，password”），那么txt数据就不可以再用逗号隔开,可以用【\t】代替，在txt中为用tab键隔开，也可以用别的符号隔开
| Recycle on EOF（遇到文件结束符再次循环？） | Stop thread onEOF（遇到文件结束符停止线程？） | 参数效果 |
| — | — | — |
| True | False | 重复 |
| False | True | 唯一 | -
参数效果=唯一 举例：txt有四条数据，线程数=2，循环次数=3，此时接口只会跑四次，取的txt中四条数据，第五条因需重头取，导致数据重复，所以不会继续运行
-
参数替换方式
注意：使用CSV Data Set Config读取数据，无论线程数与循环次数是几，每次查询都是查询下一条数据，若所有数据都读取了一遍，则会从头读取第二遍
线程数=1，循环次数=2时，会使用文件中的两条用户数据
假设txt中是四条用户数据，线程数=2，循环次数=2，在轮询时，会依次读取文件中的四条用户数据
2.2.5 线程组
线程数：假设有多少用户正在同时使用
多用户场景时，无需参考查看结果树中的接口顺序，其实是同时发生的
2.2.6 数据关联
2.2.6.1 方法一：后置处理器———JSON提取器
apply to：一般选main sample only （主请求）
Name of created values：对提取的变量起名
JSON Path expression：要提取的变量（用jsonpath写）
- 切记，如遇到数据在json中的数组下，记得指定取数组中的第几个，不然会取不出来数据
- 1、提取最深层某字段的其中一个数据：$.docGroups[0].documents[0].docId
{
"responseStatus": {
},
"docGroups": [
{
"documents": [
{
"docId": 38604724,
"startTime": 1673406999
},
{
"docId": 2,
"startTime": 1673406998
}
],
"events": []
}
- 2、提取某字段在该响应中的所有数据$.docGroups[0].documents[*].docId
{
"responseStatus": {
},
"docGroups": [
{
"documents": [
{
"docId": 1,
"startTime": 1673406999
},
{
"docId": 2,
"startTime": 1673406998
}
],
"events": []
}
Match No：想提取第几个数据
- Match No = 0，则会随即返回其中一个数据
- 填几，则会返回几个
- Match No =-1，返回所有的数据
若其他接口想调用取到的值，如下图catalogId字段一样使用即可
2.2.6.2 调试取样器
调试取样器可以打印出来Jmeter运行过程中保存下来的参数，需要配合查看结果树使用，无需配置任何数据
结果树中可看到获取到的get_docID值
2.2.6.3 方法二：后置处理器——正则表达式提取器
可以通过正则表达式来获取http请求返回的数据 
引用名称：匹配后的结果，保存到一个参数中，如param
正则表达式：
三步走:
1、拷贝目标数据和左右边界
2、把目标数据用括号括起来
3、把目标数据用.+?代替
模板： 1 1 1表示取匹配到的第一组数据， 2 2 2为第二组
匹配数字：当某组数据中包含多少个参数时，0代表随机，1代表该组的第一个参数，2表示第二 个。。。-1代表获取全部的参数，这个时候，引用名称就变成了参数数组，可以通过param_n来 获取指定的参数，当有多组数据时，第一组为param_1_g1，第二组为param_1_g2
结果：看倒数第四行的re_docid字段，是通过正则提取器提取到的第一个文章id
2.2.7 聚合报告
模拟用户使用时，循环次数要选【永久】
聚合报告结果：
#样本: 表示一共发出了多少个请求Average:平均响应时间
中位数：类似于50% Line90% Line: 假设该值为20，那么90%用户的响应时间小于等于20msMin:最小响应时间
Max/最大值: 最大响应时间
Error%/异常%: 错误率，出现错误的请求数量/请求的总数Throughput:吞吐量KB/Sec: 每秒从服务器端接收到的数据量
吞吐量：默认情况下表示每秒完成的请求数（Request per Second） 对于接口测试来说，Jmeter里的吞吐量=TPS
保存结果：聚合报告底部可保存结果数据
tip：
1、若两接口在同一线程组下，TPS值一致，但响应时间不一定一致
2、有关联关系的接口放在同一个线程组下，无关联的接口们需独立存放在不同的线程组下
2.2.8 定时器
1、Jmeter中的定时器类似于loadrunner中的pacing值和think_time
1）定时器是在每个sampler（采样器）之前执行的，而不是之后
2）定时器是有作用域的；当执行一个sampler之前时，所有当前作用域内的定时器都会被执行。且所有的sampler执行前都会执行定时器
3）如果希望定时器仅应用于其中一个sampler，则把该定时器作为子节点加入
2、常用的定时器
- 固定定时器：设置一个固定的延迟时间，单位ms
- 同步定时器（synchronizing timer）：在该定时器处，使线程等待，一直到指定的线程个数达到 后，再一起释放。可以在瞬间制造出很大的压力。它和loadrunner的集合点差不多的功能
- 集合点
- 集合点是为了增加瞬间并发压力的一种机制，在脚本中增加一个标记，所有虚拟用户执行到标记 处会进行等待，等所有用户都到达后，再同时继续执行下一步操作。
- 优点：对服务器来说，会产生一种瞬间高并发
- 缺点：对服务器来说，平均压力会降低
- 需要加集合点的场景 ：
- 根据业务来选择，如果业务场景是瞬间高并发类型的，如抢购、秒杀等，需要加集合点； 其他的场景都不需要加，一般加了集合点后，就不使用tps来衡量系统性能 集合点功能要慎重选择，因为加了集合点后，系统的平均压力会降低
- 超时时间=0，则不会发生超时；超时时间>0，等待X毫秒后，已处理完上一步的的线程组数进行并发
- 集合点
- 常量控制器：可以控制每分钟tps的总量，限制最高tps （线上测试最好加该控制器，以防压爆线上）
2.2.9 逻辑控制器
常用的逻辑控制器：
1、循环控制器：可以设置该控制器内的sampler执行的次数，循环次数与线程的循环次数各自独立
- 主要作用于多个请求时
此条件下，【获取专栏详情页的资讯列表】接口仅执行1次，【请求2】接口执行会执行6次
2、if控制器：根据判断条件决定是否执行该控制器内的请求，如果是字符串比较条件，参数和字符串 都需要加引号
条件格式：
KaTeX parse error: Expected group after '_' at position 2: {_̲_jexl3(条件表达式)}<…{__jexl3(KaTeX parse error: Expected 'EOF', got '}' at position 11: {num} > 5)}̲、 <br />2、若相比较的…{__jexl3(“${ip}”） == “xxxxx”)}
3、仅一次控制器：该控制器内的请求只执行一次，无论线程循环多少次
- 针对单个线程
此种情况下本应【请求2】【请求3】皆执行6次，但因为【请求3】在【仅一次控制器】下，最终结果为：
【请求2】执行6次【请求3】执行1次
4、foreach控制器，可以遍历某个参数数组，循环获取数组中的参数
参数是通过其他接口通过提取器提取出来的参数数组，再把参数循环附入需要这些参数的接口
结束循环字段：${get_docId_matchNr}取字数组末尾的get_docId_matchNr=12，方便标记，也不会产生写死的情况（只能获取到get_docId_9的情况）
输入变量法前缀：取自于结果树中get_docId(名字是自己在提取器中设置的变量名）
2.2.10 Http cookie管理器
2.2.10.1 cookie和session
cookie数据保存在客户端，session数据保存在服务器端。cookie有安全隐患，但是Session过多的时候会消耗服务器资源
- Cookie 机制：正统的 Cookie 分发是通过扩展 HTTP 协议来实现的，服务器通过在 HTTP 的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的 Cookie。然而纯粹的客户端脚本如 JavaScript 或者 VBScript也可以生成 Cookie。而 Cookie 的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的 Cookie，如果某个 Cookie 所声明的作用范围大于等于将要请求的资源所在的位置，则把该 cookie 附在请求资源的 HTTP 请求头上发送给服务器。
- Session 机制：Session 机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。
Cookie 存在一定的全安隐患。Cookie 像我们以前用的存折，用户的存钱、取钱都会记录在这张存折上（即浏览器中会保存所有用户信息），那么对于有非分想法的人可能会去修改存折上的数据（这个比喻忽略掉银行同样会记录用户存取款的金额）。相对于存折，银行卡要全安的得多，客户拿到的只是一个银行卡号（即浏览器只保留一个 Sessionid），那么用户的存钱、取钱都会记录在银行的系统里（即服务器端），只得到一个 sessionid 是没有任何意义的，所以相对于 Cookie 来说就会安全很多。
cv文章~~
2.2.10.2 cookie管理器
位置：
使用：
1、名称：取自抓包接口中cookie下，对应的cookie名称，具体其中哪个字段作为cookie需问开发
2、值：即对应的cookie值，配置的cookie必须是有效的，无效接口会有对应的提示：比如用户无效啊，用户未登录~之类的
3、域：接口的域名，全局配置的话，可用 i p 对应的名称 写，配置如下图中，可写为 {ip对应的名称}写，配置如下图中，可写为 ip对应的名称写，配置如下图中，可写为{ip}
无需每次通过抓包获取cookie的便捷方法：
调用login接口获取cookie，http cookie管理器无需填写内容、接口中无需调用，管理器会自动获取接口中cookie塞到需要cookie的接口中
2.2.11 token接口处理
简单了解一下token的使用~
- 前端登陆的时候向服务器发送请求，服务器验证成功，会生成一个token
- 前端会存储这个token，放在session或cookie中，用于之后的业务请求身份验证
- 拿着这个token，可以在当前登录的账号下进行请求业务，发送请求时，token会放在请求头里，服务器收到这个业务请求，验证token，成功就允许这个请求获取数据
- token可以设置失效期
token知识~
从登录接口中提取token，若是在请求头里需要增加该参数，则在HTTP信息头管理器中添加对应的key、value
2.2.12 上传、下载文件（可以忽略该小节）
内容不全也无真实实例可展示（手头接口不支持）需要细了解请自行搜索
上传文件小点~：
1、文件上传原理：浏览器将本地文件内容通过HTTP发送到服务器，服务器收到数据后重新创建一个文件
2、文件上传的HTTP请求content-type:multipart/form-data，MIME类型为application/octet-stream
3、文件上传一般有表单上传和ajax上传两种方式
实现步骤：
1、需要用到的图片本地地址填在txt文本里
2、把需要读取的txt文件配置在【CSV数据文件设置】中
3、
下载：
1、文件下载的原理：服务器将文件内容通过HTTP发送到浏览器，浏览器接受到数据后在本地创建一个文件
2、创建文件是浏览器的自沈从文，测试文件下载不需要在本地创建文件
3、文件下载是一个普通的HTTP GET类型请求
2.2.13 WebService接口脚本编写
1、接口配置为http请求
- 提供http接口的网站：http://www.webxml.com.cn/zh_cn/web_services.aspx
- PS：http访问接口默认端口为80；https访问接口默认端口为443
2、添加header：Content-Type:text/xml;chartset-
2.2.14 TCP接口脚本编写
要发送的文本：可能是xml、也可能是十六进制的一串数据，具体数据格式需要找开发了解
2.2.15 JDBC请求脚本编写
1、添加数据库jar包
- mysql-connector-java-8.0.29.jar阿里盘地址： https://www.aliyundrive.com/s/cW8XgHNyF98
- 方式一：拷贝mysql驱动包到jmeter/lib目录下
- 方式二：测试计划处添加驱动jar包（仅针对该测试计划添加某jar包）
3、配置JDBC Connect Configuration
红框中为需要填写的参数；
Database URL：jdbc:mysql://{ip}:{port}/{dbname}?useUnicode=true&characterEncoding=utf8
JDBC Driver class：选择所需使用的数据库
4、**JDBC Request **
- Variable Name of Pool declared in JDBC Connection Configuration：该字段填写【JDBC Connection Configuration】中【Variable name of createdpool】字段值
- Query Type:语句类型
- Select statement：查询语句类型（select），只支持一条查询语句，多条查询语句只执行第一条
- Update statement：更新语句类（insert，update，delete），只支持一条更新语句，多条更新语句只执行第一条
- Prepared Select statement：支持多条查询（select）语句，查询响应数据只展示第一条SQL的查询结果
- Prepared Update statement：支持多条更新（insert，update，delete）语句，响应数据展示多条更新提示（做参数化最好选择该类型）
- Callable Statement：支持多条查询、更新（insert，update，delete，select）语句，响应数据展示展示多条数据更新结果。如果是多条select语句同时查询，建议使用Callable Statement，响应数据可以展示多条查询结果值
- Parameter values：填写参数的具体的值，或者参数的名称（代替sql语句中问号的值）。可以利用此字段对SQL语句进行参数化
- Parameter types：指Parameter Values参数的数据类型，例如：integer，String，double类型
- Parameter values 和Parameter types：必须成对出现，且SQL语句中有多个参数，就必须有多少个parameter values 和Parameter types。
- Variable names：自己设置的变量名称，用于存放select操作返回的查询结果。有多个字段返回时，需用逗号隔开
- Result variable name:用于存放select操作返回的查询结果集
- Query timeout：查询超时时间
- Handle result set：定义如何处理由callable statements 语句返回的结果
若想保存查询出的数据
1、添加【调试取样器】
2、【JDBC Request】中【Variable names】赋值
调试取样器中可查看到保存下来的结果
2.3 插件便捷管理
http://jmeter-plugins.org/downloads/all
1、下载jmeter-plugins.jar
2、把jar文件放入%Jmeter_Home%\lib\ext，重启jmeter
3、点击工具栏中的图标
，可对插件进行管理
可能会用到的插件：
- 3 Gráfico básico: tps en tiempo real y complementos de tiempo de respuesta disponibles en Windows
- Funciones personalizadas de JMeter
- Configuración de conjunto de datos CSV aleatorio
- PerfMon: complemento de monitoreo en tiempo real del rendimiento del lado del servidor
Instalación:
1. Busque y verifique el complemento requerido 
2. Haga clic y espere. Se reiniciará automáticamente después de que se complete la descarga.