En la actualidad, la tasa de ocupación de mercado de JMeter en pruebas de interfaz y pruebas de rendimiento es muy alta. La razón principal es que es de código abierto, fácil de expandir y liviano (que Loadrunner no tiene), y puede cumplir con la interfaz y la interfaz. de múltiples protocolos al mismo tiempo Pruebas de rendimiento (algo que otras herramientas de código abierto no tienen). Metersphere es una plataforma de prueba de software basada en la tecnología del motor JMeter. Básicamente, puede reemplazar a JMeter sin considerar factores ligeros, y es más fácil de llevar a cabo el trabajo de prueba en línea (casos de uso de gestión en línea, scripts de edición y depuración en línea, prueba de presión en línea y informes de análisis).
1. Ventajas de la arquitectura distribuida de Metersphere
Aunque JMeter es flexible y liviano, se basa en las características de las herramientas fuera de línea y no puede administrarse ni operar de manera sistemática y basada en la plataforma. Al mismo tiempo, el modo independiente de JMeter estará limitado por el propio mecanismo y hardware de JMeter según las normas generales. presione la configuración.Configuración, puede admitir hasta varios cientos a miles de subprocesos de solicitud simulados, y llevar a cabo una gran cantidad de implementaciones de esclavos distribuidos también traerá dificultades en la gestión de operación y mantenimiento.Al mismo tiempo, el modo maestro-esclavo de JMeter Además, el nodo maestro genera mucha presión interactiva y nadie puede implementar una prueba de estrés de clúster distribuida a gran escala.
1. Análisis de estructura distribuida de JMeter
Analizamos este diagrama de estructura y sacamos las siguientes conclusiones:
(1) La programación y transmisión de datos desde el nodo maestro depende de los puertos estables. Los puertos server.rmi.localport y client.rmi.localport son aleatorios de forma predeterminada (también se pueden configurar para que sean fijos como se muestra arriba), y el puerto server_port generalmente se fija como 1099, siempre que no se libere el firewall (si se requiere el puerto aleatorio para cerrar el firewall), el modo distribuido maestro-esclavo maestro-esclavo no se programará.
(2) Los datos enviados por el nodo maestro al nodo esclavo son relativamente pequeños (porque además de la programación maestro-esclavo y la sincronización de datos, cada nodo esclavo actúa como una prensa independiente y es responsable de enviar y recibir su propia parte de la información). Solicitud), pero el nodo esclavo envía al nodo esclavo. Los datos de resultados de la prueba del nodo maestro son generalmente relativamente grandes. Cuando se encuentra una gran cantidad de nodos esclavos, la presión sobre el nodo maestro (computadora maestra) será grande, y los cuellos de botella son propensos a ocurrir.
(3) Cada vez que se inicia un nodo esclavo (Agente), el puerto Server_Port está básicamente ocupado y solo se puede probar para una sola tarea. Incluso si una tarea finaliza, el proceso no se liberará cuando todavía esté en el puerto, que es exclusivo del recurso.
(4) La implementación de la solución maestro-esclavo es engorrosa. Además de considerar el factor del puerto, también es necesario considerar la consistencia de la versión y la consistencia del paquete de dependencia del complemento. Uno de los nodos falla, lo que puede causar todo el estrés. falla la tarea de prueba (porque es necesario asegurarse de que la programación y los datos maestro-esclavo sean consistentes en sexo).
(5) Si el CSV de la prueba de esfuerzo de JMeter requiere que cada nodo lea datos diferentes (máquina de prueba de esfuerzo del agente), debe dividirse, recortarse y colocarse manualmente con anticipación, porque el control maestro-esclavo no tiene una transmisión remota de archivos y mecanismo de sincronización.
(6) Si el rendimiento del hardware de los nodos esclavos difiere mucho, es imposible controlar la distribución de presión de diferentes nodos para reducir la presión de algunos nodos, porque el agente de la máquina del nodo solo tiene la función de enviar presión, y no hay función de control de diferencia Reutilizar la misma configuración.
(7) Además, JMeter puede ver informes de pruebas de estrés en tiempo real a través de complementos de terceros en modo GUI (bajo rendimiento, generalmente no se usa), mientras que en modo sin GUI, solo se pueden generar informes de resultados. una forma común es pasar El oyente de back-end envía los datos de resultados a InfluxDB y usa Grafana para la visualización en tiempo real, pero InfluxDB también fallará bajo pruebas de estrés a gran escala de esta manera, a menos que sea un clúster de InfluxDB (el la versión del clúster no es de código abierto).
(8) JMeter no admite la supervisión del rendimiento de forma predeterminada. Solo se puede implementar en modo GUI ampliando el complemento de escucha (como PerfMon Metrics Collector), pero solo puede monitorear indicadores básicos como CPU, memoria y red. Escalabilidad está limitado. Además, en términos de rendimiento, también es muy irrazonable. Originalmente, la presión sobre el nodo maestro es grande y la recopilación de datos de monitoreo empeorará aún más el rendimiento. Por lo tanto, no hay otra forma que usar un nodo implementado de forma independiente. plataforma de monitoreo de desempeño.
2. Análisis de arquitectura distribuida de Metersphere
Analizamos el diagrama de arquitectura anterior y sacamos las siguientes conclusiones:
(1) MeterSphere se basa en la tecnología Docker, que es fácil de implementar en clústeres distribuidos. Si coopera con Kubernetes, es más fácil expandir e implementar nodos, y también es fácil de implementar en la nube.
(2) MeterSphere no utiliza el método tradicional JMeter Slave (divisor de voltaje del agente) para expandir los nodos, pero cada nodo es un JMeter Master independiente. La ventaja es que no es necesario construir una conexión maestro-esclavo a través del puerto Server_Port. Cada nodo es una versión de Docker del proceso JMeter, controlado por NodeController, que se detiene cuando se agota (se inicia y se desconecta a través de Docker).
(3) Ya no es necesario recopilar los resultados de las pruebas y los informes para el Maestro a través del Esclavo, sino que los nodos respectivos devuelven los datos de los resultados de las pruebas a Kafka a través del componente de escucha JMeter-Kafka, lo que evita la presión de recopilación del maestro en el maestro. modo esclavo, y Kafka también puede considerar la implementación en clúster, que puede cumplir con la presión de rendimiento de grandes volúmenes de datos en términos de rendimiento.
(4) MeterSphere recopila y calcula los datos de resultados pasados a Kafka mediante DataStreaming y los escribe en la base de datos MySQL, lo que garantiza el rendimiento en la generación de informes en tiempo real e informes resumidos. Todos sabemos que el rendimiento de JMeter para generar informes ha sido relativamente pobre. , especialmente durante mucho tiempo, la prueba de estrés escribe una gran cantidad de datos de resultados en el archivo, es casi imposible convertirlo sin problemas en un informe html.
(5) MeterSphere establece los parámetros de la prueba de estrés de rendimiento (simultaneidad, tiempo, gradiente, grupo de recursos de prueba de estrés, segmentación de archivos, etc.) en función de la interfaz, administra los recursos del nodo a través del grupo de recursos y distribuye scripts y archivos de prueba de estrés a los usuarios especificados. recursos de acuerdo con el grupo de recursos. nodo, inicie automáticamente Docker JMeter para completar la prueba de presión.
(6) Los casos de prueba (interfaces) y los escenarios de prueba (guiones) se almacenan y administran, y los datos de prueba, los resultados de prueba y los informes también se almacenan y administran, lo cual es conveniente para el análisis, el intercambio y la comparación posteriores.
(7) Prometheus se puede ampliar en la supervisión del rendimiento. Si se configura la supervisión de Prometheus relacionada, MeterSphere recopilará automáticamente datos de supervisión del rendimiento del sistema bajo presión durante la medición de la presión.
2. Ventajas basadas en la plataforma web de Metersphere
Aunque JMeter es muy elogiado por muchas personas, como una pequeña herramienta de prueba, no puede administrar scripts de prueba, programar escenarios de prueba en línea y ver el proceso de prueba y los resultados de la prueba en tiempo real.Y las pruebas de rendimiento funcionan, sin mencionar las pruebas continuas en tiempo real. -tiempo basado en iteraciones del proyecto. Además, aquellos que han realizado pruebas de rendimiento durante mucho tiempo saben que existe una cierta correlación entre las pruebas de interfaz y las pruebas de rendimiento. Por ejemplo, el escenario de prueba mixta de las pruebas de rendimiento es una combinación de algunas interfaces. Es completamente posible directamente consulte las interfaces probadas y no es necesario volver a escribirlas. Una vez definidas y editadas, la planificación del escenario para las pruebas de rendimiento también se puede avanzar a la fase de pruebas de interfaz, en lugar de preparar scripts de prueba hasta la fase de ejecución de pruebas de rendimiento. Estas cosas son comunes para los sistemas de plataforma web, pero no para JMeter.
Se puede decir que Metersphere resuelve los problemas que mencionamos anteriormente, es decir, se ejecuta y administra completamente en línea, lo que equivale a mover JMeter de fuera de línea a en línea. Por supuesto, algunas personas preguntarán, ¿puede editar y depurar scripts de prueba en línea? Después de todo, muchas plataformas de prueba de código abierto basadas en Jmeter generalmente no tienen problemas con las pruebas de estrés en línea, pero es un poco difícil editar scripts en línea, porque no es tan fácil hacer que una herramienta de edición de scripts sea tan flexible como Jmeter en la web. lado. Para esto, Metersphere ha hecho un buen trabajo, y creo que absorberá más ventajas de Jmeter en el futuro. Echemos un vistazo a las capacidades de desarrollo de edición y definición de interfaz basadas en interfaz web de Metersphere:
1. Función de definición de interfaz perfecta
(1) Crear una interfaz
Actualmente, las interfaces admitidas incluyen Http, TCP, SQL y DUBBO, pero hay algunos tipos. Por ejemplo, websocket aún no es compatible (la configuración de la interfaz no tiene esta función, pero la prueba de rendimiento se puede lograr cargando scripts jmx y paquetes jar de dependencia relacionados con websocket). Para aquellos que han estado en contacto con Jmeter o Postman, es relativamente fácil crear una interfaz en él, porque muchos elementos son los mismos, y lo que es aún más sorprendente es que los servicios Mock se pueden crear sincrónicamente, y no hay nada que hacer. decir acerca de la facilidad de uso.
Además, la interfaz que creamos se puede burlar y documentar (equivalente a Swagger), lo cual también es genial:
(2) Importar interfaz externa
Admite la importación de archivos de interfaz en múltiples formatos. Actualmente, el protocolo http es compatible con Postman, Swagger y JMeter. Nadie más (dijiste qué plataforma de prueba de interfaz admite tantos).
Tome el script de JMeter como ejemplo, después de importar, los elementos básicos son los mismos que los de JMeter, es decir, el preprocesador, el posprocesador, la aserción, etc. desaparecieron, pero no importa, puede ingresar el caso o agregarlo a el modo de escena de la interfaz de automatización. Por ejemplo, agregando una expresión regular para extraer el parámetro de cookie en la operación de procesamiento posterior:
La depuración se puede realizar para ver el efecto de nuestra extracción:
Puede ver que esta expresión regular (si el cuerpo de la respuesta está en formato JSON, además de la regularidad, se recomienda usar JSONPath para extraerlo, lo cual es más conveniente y preciso. Estoy extrayendo la cookie en el encabezado de la respuesta, por lo que Uso la expresión regular) para extraer una matriz de tres valores. Solo necesitamos tomar el segundo valor como nuestro parámetro de cookie, luego podemos referirnos directamente a la variable ${cookie_2}, ¿es similar a la operación en Jmeter? Entonces dije que conozco Jmeter, y es muy fácil aceptar este Metersphere (es un conjunto de juegos). Puede referir esta cookie al encabezado de solicitud de la siguiente interfaz:
Nota: De hecho, la función de importar interfaces externas tiene otro significado práctico, es decir, podemos usar otras herramientas, como Postman, grabación de proxy JMeter, complemento de grabación de Chrome y otras herramientas para grabar scripts de interfaz, y luego importar Metersphere , que es útil para las pruebas de rendimiento. La construcción de la escena proporciona medios auxiliares, lo que es muy útil para los amigos a los que les gusta grabar.
2. Configuración flexible de escenarios de automatización de interfaz
¿Por qué tanta gente está dispuesta a usar Jmeter para probar la interfaz? Además de los muchos protocolos que admite, lo más importante es que es fácil organizar escenarios. Por ejemplo, después de iniciar sesión, obtengo el token y lo paso a la interfaz de consulta, y luego la interfaz de consulta se utiliza para consultar, y la consulta es Como resultado, se pasa a la interfaz de operación para modificarla o eliminarla. Tal escenario es una característica comercial, que requiere que las interfaces se organicen en secuencia y asociados entre sí por parámetros. Una vez que se organiza una interfaz basada en escenarios de este tipo, se puede hacer referencia directamente al escenario de prueba de rendimiento posterior, por lo que la interfaz basada en escenarios es muy importante, lo que Metersphere también hace bien (después de todo, se basa en la tecnología Jmeter).
Si tiene un conocimiento profundo de la tecnología Jmeter, es útil comprender y utilizar Metersphere, especialmente los escenarios de automatización de interfaz y los escenarios de prueba de rendimiento, que básicamente pertenecen a la misma tecnología:
X1~X5: Es un proceso de simulación de carga, utilizando estos componentes para completar la simulación de carga;
X1: seleccione el protocolo, simule la solicitud del usuario, verifique si la respuesta del servicio es correcta y recopile la información del resultado, que pertenece a la parte de definición de Api;
X2: Mejorar la parte del script de prueba, incluyendo parametrización, asociación, etc., que pertenecen a la parte de definición de Caso;
X3: Controlar la lógica empresarial del script de prueba, que pertenece a la parte de definición del escenario empresarial;
X4: punto de encuentro, que simula la concurrencia de usuarios, que participa en las pruebas de rendimiento;
X5: la cantidad de usuarios, un subproceso representa un usuario, la interfaz de depuración generalmente es de un solo subproceso y la prueba de rendimiento utilizará varios subprocesos;
Y1: Puede entenderse como un protocolo de selección, incluyendo la parte de simulación de carga, que se encarga de simular las solicitudes de los usuarios;
Y2: Puede entenderse como un punto de control, la parte de verificación de resultado, que se encarga de verificar la corrección del resultado, y pertenece a la parte de definición de caso de interfaz;
Z: Puede entenderse como un monitor, que es responsable de la recopilación de resultados.Para Jmeter, el oyente no solo puede ubicarse en el grupo de hilos, sino también fuera del grupo de hilos;
Para la plataforma Metersphere, ya sea que se trate de pruebas de interfaz o pruebas de rendimiento, es inseparable de la estructura de elementos anterior, pero el oyente se ha integrado en gran medida y se ha integrado en el informe o monitoreo en la plataforma, por lo que no es intuitivo. reflexión.
(1) Crea una escena
Podemos crear una escena y luego copiarla y agregarla directamente desde la interfaz definida anteriormente (importarla desde la lista de interfaces):
Además de las interfaces importadas, también podemos agregar nuevas interfaces directamente en la escena, y también como Jmeter, agregar controladores de transacciones, controladores de bucle, controladores condicionales, scripts personalizados (beanshell, Python, etc.), como las siguientes adiciones Script para generar aleatoriamente un número de identificación:
Se puede decir que la función de edición automática de escenas de esta interfaz sigue siendo muy poderosa, y para mí, un probador que es bueno en Jmeter, puede aceptarse sin problemas.
(2) Escena de guión de importación
Lo probé, importé el script de JMeter y descubrí que incluso el grupo de subprocesos, la transacción y cada elemento de Jmeter se importaron juntos, de la siguiente manera:
Actualmente, muchos componentes no admiten la visualización en la interfaz, pero se mostrarán en forma de xml, y el xml se puede editar, como el administrador de cookies:
Cuando se trata de la administración de cookies, puede usar el Administrador de cookies HTTP con JMeter (la interfaz de Metersphere actualmente no proporciona este componente, y la pantalla importada es xml), o puede usar el método de extracción de expresiones regulares que mencioné anteriormente, y luego agregarlo a otras interfaces En el encabezado de la solicitud (similar al método de procesamiento de tokens), por supuesto, Metersphere también tiene su propio método, es decir, compartir cookies Verificar esto es en realidad equivalente a usar el almacenamiento de cookies del Administrador de cookies en JMeter :
Ya sea creando una nueva escena o importando una escena, de hecho, Metersphere ha hecho un muy buen trabajo, básicamente absorbiendo muchas características de Jmeter, y en términos de expansión, puede continuar expandiendo algunos componentes de Jmeter, desde la perspectiva de desarrollo secundario de código abierto Dicho esto, no creo que sea demasiado difícil.
(3) Variables y parametrización
En cuanto a la parametrización, existen principalmente los métodos de extracción de asociación mencionados anteriormente, actualmente se soportan la regularización, JSONPath y XPath, que son básicamente suficientes:
En cuanto a las variables globales, puede configurarlas en la configuración del entorno del proyecto. El método de configuración es muy flexible. Puede agregar variables directamente, o puede agregar scripts para generar variables en el pre-script global:
La importación de variables desde un archivo es similar a la configuración del archivo de datos CSV en Jmeter. Hay un enlace de variable de escena en la parte superior de la página de edición de escena. La interfaz de configuración es la siguiente:
3. Escenarios de prueba de rendimiento configurados de manera eficiente
La mayor ventaja de Metersphere en comparación con Jmeter es que el proceso de prueba de rendimiento se opera completamente a través de la interfaz web, incluida la carga y administración de scripts, la parametrización y la administración de carga de archivos de recursos, la configuración en línea de las pruebas de estrés, la visualización en tiempo real del proceso de pruebas de estrés, y monitoreo del rendimiento de las prensas Resultados de pruebas de rendimiento y gestión de informes, que no están disponibles en Jmeter independiente.
(1) Recursos de prueba
La mejor parte de Metersphere es administrar los recursos de prueba a través de grupos de recursos, y un grupo de recursos puede crear múltiples nodos de prueba de estrés Cada nodo aquí no es un esclavo tradicionalmente entendido por Jmeter (como un nodo proxy con un puerto vinculado a 1099), pero está asociado a un nuevo proceso de Jmeter Master, este proceso crea dinámicamente un contenedor durante la prueba de estrés a través de la imagen de Docker, después de la prueba de estrés, muere automáticamente para liberar los recursos de la prueba de estrés. El siguiente es un ejemplo de un grupo de recursos que crea dos nodos:
Cada controlador de nodo NodeController es responsable de crear y destruir el contenedor Jmeter Master. NodeController también es un contenedor. El puerto predeterminado correspondiente es 8082. Los resultados de docker ps | grep node-controller son los siguientes:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3d8cbeab1861 registry.cn-qingdao.aliyuncs.com/metersphere/ms-node-controller:v1.19.0 "/deployments/run-ja…" 4 days ago Up 4 days (healthy) 0.0.0.0:8082->8082/tcp, 0.0.0.0:9100->9100/tcp ms-node-controller(2) Monitoreo del desempeño
El modo de implementación de nodos de Metersphere (install.conf configura MS_INSTALL_MODE=node-controller durante la instalación), después del inicio, verá tres contenedores relacionados, de los cuales el contenedor Jmeter Master es dinámico (morirá después de la prueba de presión) y el los otros dos son fijos. Uno es NodeController mencionado anteriormente, y el otro es nodo-exportador. Mucha gente no conoce la función de nodo-exportador. De hecho, es un colector de monitoreo de rendimiento, que es equivalente a nodo-exportador en el Plataforma de monitoreo Prometheus. , en el informe, puede ver los datos de monitoreo del rendimiento del nodo de presión recopilados:
Los datos de monitoreo y recopilación anteriores son básicamente los mismos que Prometheus. Es seguro que Metersphere ha realizado alguna integración con él. Dado que el exportador de nodos puede admitir la recopilación de indicadores de rendimiento de Linux, además de monitorear la máquina del nodo de estrés, también podemos Para monitorear el servidor bajo prueba, agregue el servidor que necesitamos monitorear a través de Performance Test->Test->Advanced Configuration->Monitoring:
El método anterior puede personalizar los indicadores de seguimiento de acuerdo con la sintaxis promQL de Prometheus. Entonces no hay duda de que también podemos extender el monitoreo de otros servicios en la forma de Prometheus general, como Mysql, monitoreo de Postgresql, etc., solo es necesario implementar el recopilador correspondiente en la máquina monitoreada, como Mysql Exporter, Postgres_Exporter , Exportador de JMX Espere, las personas que realmente entienden las pruebas de rendimiento y el monitoreo del rendimiento no deberían tener dificultades para comprender los requisitos de expansión en este sentido. El diagrama de relación de monitoreo es el siguiente:
(3) Cargue el script de prueba
Hay principalmente dos formas, una es el archivo JMX (que incluye los scripts recién cargados o hace referencia a los scripts existentes en la plataforma), la otra es hacer referencia al escenario de automatización de la interfaz mencionado anteriormente (esta es también la ventaja de la gestión de la plataforma):
En esencia, el proceso de automatización de la interfaz mencionado anteriormente es un proceso de scripting de Jmeter. La prueba de estrés final llama al archivo JMX (que se distribuirá a cada nodo), por lo que el script de carga de la prueba de rendimiento y la configuración de la escena de la interfaz están relacionados.
(4) Configuración de presión
La configuración de presión basada en la interfaz es más simple e intuitiva que JMeter.Actualmente, admite dos modos de presión de grupo de subprocesos, uno es la presión incremental lineal de ThreadGroup y el otro es la presión incremental escalonada de ConcurrencyThreadGroup:
En términos de configuración, admite la selección de grupos de recursos (cada grupo de recursos puede corresponder a múltiples nodos de prueba de esfuerzo), admite múltiples escenarios (ejecuta múltiples scripts de forma simultánea o secuencial) e incluye configuración de RPS (límite de capacidad) además de concurrente convencional. elementos de configuración:
La medición de presión se puede personalizar para asignar la relación de presión de diferentes nodos (distintas máquinas tienen un rendimiento diferente, a veces deben tratarse de manera diferente):
Para archivos parametrizados, también es compatible con la división de CSVDataSet (en configuración avanzada), que puede separar los datos de medición de presión según los subnodos. Esta es una función que JMeter no tiene de forma predeterminada, pero que a menudo se requiere en escenarios comerciales. La página de configuración es como sigue:
Para mí, en la actualidad, Metersphere no admite el ajuste dinámico de TPS/RPS, lo cual es bastante inconveniente, porque a veces no queremos interrumpir la prueba cuando necesitamos seguir presurizando durante mucho tiempo, y esperamos poder para presurizar dinámicamente.
(5) informe de prueba
El informe de prueba de Metersphere se encuentra entre los mejores, pero en comparación con JMeter, tiene ventajas obvias. En primer lugar, puede ver la situación de medición de presión en tiempo real e intuitivamente. Los TPS, indicadores RT, estadísticas de solicitud y error más importantes. los registros son todos claros. Si JMeter no introduce complementos de terceros, es imposible verificar visualmente los cambios de presión. Por supuesto, una vez finalizada la prueba de JMeter, el informe Html exportado también es muy detallado. En este sentido, Metersphere es un poco insuficiente. , pero no afecta nuestras actividades de prueba. Después de todo, estos son los indicadores más preocupantes. Si necesita más vistas de informes, puede desarrollarlas en base a extensiones de código abierto. Un informe de prueba de muestra de Metersphere es el siguiente:
Otro aspecto destacado es la función de comparación de informes.Podemos comparar los informes de múltiples rondas de pruebas, como comparar la mejora de TPS, que puede explicar claramente la mejora del rendimiento.
3. Las ventajas de escalabilidad de Metersphere
La mayor ventaja de JMeter es su código abierto, y la mayor ventaja de Metersphere es su código abierto.Otra ventaja de Metersphere es que se basa en la tecnología JMeter.
1. Ventajas ampliadas basadas en la tecnología JMeter
La mayor ventaja de JMeter es que admite pruebas de múltiples protocolos, en este sentido, no debería haber una tercera herramienta de prueba excepto Loadrunner (las herramientas de los fabricantes de Internet no se cuentan, después de todo, los extraños no pueden disfrutarlo gratis), por lo que La mayor ventaja de Metersphere se basa en JMeter para extender la prueba de varias interfaces de protocolo, como la prueba de WebSocket. De forma predeterminada, JMeter no es compatible con WebSocket, pero se puede ampliar con complementos de terceros para obtener compatibilidad. Para Metersphere, tenemos la misma idea. Podemos cargar todos los complementos de terceros de WebSocket que dependen de paquetes Jar para Admite secuencias de comandos de protocolo WebSocket.Prueba de presión:
Después de que el paquete de dependencia anterior se cargue una vez, se puede hacer referencia directamente en el mismo proyecto. El efecto de depuración es el siguiente:
Por lo tanto, Metersphere básicamente puede soportar todos los protocolos e interfaces soportados por JMeter, dependiendo de cómo lo configures y uses.Además, Metersphere también es una plataforma de código abierto basada en Java, y podemos obtener más extensiones a través del desarrollo secundario.
2. Extensión e integración basadas en plataformas
(1) En términos de monitoreo, Prometheus puede ampliarse y Prometheus es una plataforma de monitoreo de sistema de código abierto. Las instrucciones relevantes también se mencionan anteriormente. Para aplicaciones específicas, puede visitar el sitio web oficial de Prometheus para obtener asistencia. Hay configuraciones externas relacionadas en la configuración del sistema de Metersphere:
En términos de pruebas de interfaz de usuario, se estima que pronto habrá expansiones correspondientes, como expandir el soporte y la aplicación de Selenium.
(2) También se ha realizado la conexión e integración correspondientes con las plataformas de gestión de defectos populares actuales. Por ejemplo, usamos mucho Zen Tao, por lo que podemos considerar aplicaciones integradas en este sentido. Esta es la ventaja de las extensiones de código abierto:
En cuarto lugar, las deficiencias actuales de Metersphere
Personalmente, para mí, la mayor deficiencia de Metersphere es que no es compatible con el control dinámico de TPS/RPS/conteo de subprocesos. En la práctica, esperamos ajustar el rendimiento en cualquier momento o cambiar dinámicamente el límite superior de la presión cada vez que se realiza la medición de presión.
- Escenario 1: Realizar una prueba de capacidad continua en línea, si no hay problema con la capacidad de servicio bajo cierta presión, esperamos aumentar la capacidad sin detener la prueba de presión, o encontrar que la presión ha pasado en un cierto período de tiempo. grande, el rendimiento debe reducirse temporalmente. En este momento, si el TPS/RPS no se puede cambiar dinámicamente, solo podemos detener la tarea y comenzar de nuevo.
- Escenario 2: Cuando no podamos estimar el TPS máximo del sistema, continuaremos aumentando la presión (el número de usuarios/el número de hilos) para prestar atención al cambio de la curva TPS (el número de hilos es necesario para aumentar continuamente el gradiente sin interrupción y mantener la misma relación proporcional: TPS * RT = número de subprocesos), si aumenta el número de presión (número de usuarios), pero TPS no aumenta, puede ser un cuello de botella de rendimiento, pero si esta tendencia no ha aparecido, y la herramienta de presión se ha presionado hasta el número máximo de usuarios/subprocesos, entonces necesitamos aumentar dinámicamente el número de usuarios/subprocesos, de lo contrario, la prueba puede interrumpirse.
Los dos casos anteriores tienen poco impacto en situaciones generales de prueba, y es un gran problema reiniciar la ejecución de la prueba, pero si se prueba en un entorno de producción, o si se requiere mucho trabajo previo (preparar una gran cantidad de datos de prueba o trabajo de inicialización de entorno complejo), cualquier interrupción de la prueba significa un aumento en la carga de trabajo, por lo que es necesario cambiar dinámicamente la presión durante la medición de presión.
Para cambiar dinámicamente la presión en JMeter, las variables de parámetros se cambian dinámicamente a través de BeanShellClient y BeanShellServer.Por ejemplo, en el nodo jmeter.properties, establezca beanshell.server.port en 9000 y cambie dinámicamente los parámetros a través de comandos:
java -jar <jmeter_path>/lib/bshclient.jar localhost 9000 update.bsh <参数>En la actualidad, es difícil llevar a cabo la transformación basada en Metersphere, por un lado, abrir beanshell.server.port rompe la ventaja del JMeter-Master original sin llamadas de puerto (las ventajas mencionadas anteriormente), y JMeter solo admite DynamicThread. tecnología de subprocesos dinámicos ConcurrencyThreadGroup, grupo de subprocesos ArrivalsThreadGroup, temporizador de rendimiento constante, etc., cambian dinámicamente las variables de los parámetros y su aplicabilidad es limitada. Sin embargo, todavía espero que los ingenieros de Metersphere puedan encontrar la mejor solución a este problema, incluso si se trata de un compromiso a través de la configuración manual externa.
Para las tecnologías relacionadas con la presión dinámica de JMeter, puede prestar atención a mi otro artículo: Implementación del rendimiento dinámico de JMeter La presión se controla de acuerdo con la cantidad de subprocesos, pero el indicador en el objetivo de prueba de presión que establecemos suele ser el rendimiento (QPS/TPS) , lo que genera inconvenientes para los evaluadores. El número de subprocesos debe ajustarse mientras se observa qué nivel de QPS/TPS ha alcanzado. Para resolver este problema, JMeter proporciona un complemento para el controlador de rendimiento. Podemos limitar QPS/TPS estableciendo el límite superior de rendimiento para lograr el efecto de control de cantidad. https://blog.csdn.net/smooth00/article/details/121655220?spm=1001.2014.3001.5501
Por supuesto, las ideas anteriores no son adecuadas para todos. Es posible que muchas personas no usen esta función. La implementación ciega del Metersphere producido puede conducir a una mala facilidad de uso, implementación y mantenimiento. Sin embargo, como sistema de medición de la presión de la nube, es importante Una característica debe ser considerada tan pronto como sea posible.
Después de escribir esto, descubrí que he escrito mucho, así que no diré más. De hecho, para las pruebas o el trabajo técnico, el elemento más importante son las personas, seguidas de las herramientas. Después de todo, las herramientas están muertas y las personas están vivas. No importa cuán buena sea una herramienta, solo las personas que la entienden pueden aprovechar su valor, y solo personas Con el fin de promover la evolución de la herramienta en una buena dirección.
Metersphere consulte el sitio web oficial: MeterSphere - Open Source Continuous Testing Platform - Sitio web oficial
Código fuente abierto: https://gitee.com/fit2cloud-feizhiyun/MeterSphere