Pruebas de carga: HTTP vs Headless vs Real Browser

Un esquema de los principales aspectos de los métodos de simulación de carga, como HTTP, sin cabeza y basado en navegador real seguido de una matriz de comparación, para ayudarle a elegir un enfoque de simulación adecuado.

Pruebas de carga:

HTTP vs Headless vs Real Browser

Visión general:

La carga lenta o las páginas web que no responden tienen un impacto en los ingresos financieros porque lo más probable es que los usuarios frustrados no regresen una vez que se haya resuelto el problema. Por lo tanto, las pruebas de rendimiento se han convertido en una parte fundamental de la cadena de desarrollo y la demanda sigue creciendo.

Las plataformas de pruebas de rendimiento proporcionan una amplia gama de métodos de simulación de carga, como HTTP, sin cabeza y basados en explorador real. En este documento, describiremos los aspectos principales de los siguientes seguidos de una matriz de comparación, que puede utilizar para elegir un enfoque de simulación adecuado.

Simulación de carga basada en HTTP

En los primeros días de la era digital, las pruebas basadas en HTTP eran muy populares. Con el auge de la rica tecnología de cliente web, los enfoques de simulación basados en HTTP se han vuelto cada vez más obsoletos. Un controlador de prueba típico basado en HTTP ejecuta solicitudes de servicio y analiza las respuestas. Las aplicaciones web 2.0 modernas constan de muchos scripts del lado cliente, que se ignoran totalmente y no se miden en este tipo de ejecución de prueba. En los peores escenarios, los casos de uso complejos no se pueden simular en el nivel de protocolo debido a una escasez de identificadores generados por el lado cliente.

Debido a su naturaleza basada en la solicitud y la respuesta, la sobrecarga en la máquina de inyección de carga es muy baja. Un servidor de prueba de carga típico puede simular hasta 800 sesiones simultáneas. Los casos de uso complejos basados en protocolos pueden ser difíciles de implementar. Un ingeniero de rendimiento debe lidiar con cookies, ID de sesión y otros parámetros dinámicos. Dependiendo del tipo de sistema que se está probando, algunos nombres de formulario web a menudo cambian una vez que se ha implementado una nueva versión, lo que provocará un error en el script basado en HTTP.

script de nivel de protocolo de ejemplo

transacción TMain

Var

hContext: número;

Comenzar

WebPageUrl(“http://lab3/st/”, “Greetings”);

WebPageStoreContext(hContext);

WebPageLink(“Unirse a la experiencia!”, ” – Nuevo visitante”);

WebPageSubmit(“Continuar”, CONTINUE001, “Menú principal”);

WebPageLink(“Productos”, “ShopIt – Productos”);

WebPageLink(NULL, “ShopIt – Product”, 3);

WebPageSubmit(“Search”, SEARCH001, ” – Search”, 0, NULL, hContext);

fin de TMain;

dclform

CONTINUAR001:

“nombre”: “jack”,

“New-Name-Button” :- “Continuar”;

BUSCAR001:

“búsqueda” :” “arranque”;

El script de ejemplo que se ve aquí es un escaparate de la naturaleza muy técnica de esos scripts. Si cambia un atributo técnico de la aplicación, debe volver a escribir todo el script.

Después de todo, los scripts de nivel de protocolo son buenos para las pruebas de nivel de componente en entornos de integración continua y la configuración perfecta para las pruebas de esfuerzo debido a su bajo espacio en las máquinas de inyección de carga.

Simulación de carga basada en navegador sin cabeza

Con el auge de las tecnologías web 2.0, el negocio de pruebas se enfrentó a serios desafíos. Las aplicaciones de explorador enriquecido ya no se podían probar o simular en el nivel de protocolo debido a la lógica del lado cliente que faltaba durante la reproducción del script. Por lo tanto, se han introducido varios navegadores sin cabeza como HtmlUnit, PhantomJS o SlimerJS. A menudo se construyen sobre WebKit, el motor detrás de Chrome y Safari.

Los navegadores sin cabeza son similares a los navegadores reales sin la GUI. Muchas plataformas de automatización de pruebas y pruebas de rendimiento utilizan navegadores sin cabeza para simular el tráfico.

Los navegadores sin cabeza tienen sus propios escollos; a medida que los nuevos navegadores entran en los mercados, los kits de navegador sin cabeza necesitan ponerse al día con todo el rendimiento y las mejoras de características de los navegadores reales.

La simulación de la representación del lado del cliente de no es gratis. Un servidor de inyección de carga típico puede simular hasta 10-12 sesiones simultáneas de explorador sin cabeza, frente a 500 de sesiones basadas en HTTP.

La implementación y personalización del script de prueba no es demasiado difícil. Si tienes habilidades básicas de codificación podrás crear scripts sencillos. No todos los navegadores sin cabeza proporcionan características de reproducción visual y sin depuración de script de reproducción visual o análisis de errores podría llegar a ser muy complicado.

ejemplo de script phantomjs
“uso estricto”;
var page á require(‘webpage’).create(),

servidor: ‘http://posttestserver.com/post.php?dump’,
datos : ‘universo-expansión&respuesta-42’;

page.open(server, ‘post’, data, function (status) ?

si (estado !’éxito’) ?

console.log(‘¡No se puede publicar!’);

Si no, no, el lugar de la casa.

console.log(page.content);

}
phantom.exit();

});

En el script de ejemplo que se ve aquí se ejecuta una simple solicitud de publicación. Necesita habilidades de programación Java para personalizar dichos scripts de prueba.

Simulación de carga basada en navegador real

Las aplicaciones Web2.0 están llenas de JavaScript, Flash, Ajax y CSS. Sin un navegador completo, no es posible medir los tiempos de respuesta reales de extremo a extremo de toda la página web. Las pruebas de rendimiento reales basadas en explorador le permiten verificar la funcionalidad y la velocidad del sitio según lo percibido por el usuario final.

Una solución de prueba de rendimiento del navegador real típica recopila tiempos de carga de imágenes, JavaScript, CSS y más. A menudo proporcionan gráficos de cascada, que visualizan el tiempo de carga de esos componentes.

La huella de un navegador basado en navegador real es ligeramente mayor. Teniendo en cuenta el hecho de que la simulación del navegador sin cabeza no ofrece tiempos de respuesta 100% realistas es justo decir que la simulación basada en navegador real debe ser preferible. En escenarios de la vida real, los navegadores sin cabeza funcionan sólo un 20% mejor que los navegadores reales. Por lo tanto, si el inyector de carga única de tamaño medio puede ejecutar 10-12 sesiones de explorador sin cabeza, el mismo inyector de carga puede ejecutar 8-10 sesiones de explorador reales.

La implementación y el mantenimiento de scripts de prueba es fácil porque las acciones del usuario se reflejan directamente y la reproducción visual facilita la depuración. En el script de ejemplo debajo del explorador abre una dirección URL, inserta el usuario y la contraseña y hace clic en el botón de inicio de sesión.

ejemplo de script real basado en navegador

transacción TMain

Comenzar

BrowserStart(BROWSER_MODE_DEFAULT, 800, 600);

navegar al sitio de inicio de sesión

BrowserNavigate(“http://demo.com/TestSite/LoginForm.html”);

establecer la autenticación para el sitio seguro

BrowserSetText(“//INPUT[@name’user’]”, “User1”);

BrowserSetPassword(“//INPUT[@name’pwd’]”, “Password1”);

Iniciar sesión

BrowserClick(“//INPUT[@value”Login’]”, BUTTON_Left);

fin de TMain;

Después de todo, la simulación del navegador real es útil para pruebas de carga realistas de extremo a extremo, pero puede resultar costosa para las pruebas de esfuerzo de grandes volúmenes de usuario, porque la huella en el servidor de inyección de carga es demasiado alta.

Tipos de pruebas de rendimiento

Pruebas de velocidad de componentes

En los últimos años, los métodos de desarrollo de software se han movido en la dirección ágil. Los sprints de liberación corta son esenciales. Los desarrolladores e ingenieros de pruebas automatizan sus comprobaciones de calidad y rendimiento. Normalmente, implementan pruebas de rendimiento basadas en servicios en el nivel de protocolo o simulan comprobaciones de rendimiento basadas en explorador es real para comparar los tiempos de respuesta de extremo a extremo con los límites de rendimiento acordados.

Objetivos

+ Repetibilidad

+ Interfaz automatizada y comprobaciones de rendimiento de extremo a extremo

+ Comparar los tiempos de respuesta con los umbrales acordados

Pruebas de carga

Por varias razones, las pruebas de carga son el método de prueba ideal cuando se trata de la verificación de los requisitos no funcionales. Una de las condiciones que los tiempos de respuesta pueden verificarse en condiciones reproducibles. Otra es que esas pruebas permiten la verificación de los umbrales de tiempo de respuesta. La medición realista del tiempo de respuesta es esencial en escenarios de prueba de carga. Por lo tanto, los ingenieros de pruebas utilizan la simulación de usuario basada en navegador real o sin cabeza para su configuración de prueba de carga.

Objetivos

+ Simulación de carga reproducible

+ Verificación de los umbrales de tiempo de respuesta

+ Identificar cuellos de botella en producción como condiciones de carga

+ Escenarios de prueba realistas de extremo a extremo

Prueba de estrés

Si tiene que probar la fiabilidad de la aplicación en condiciones de carga máxima, ejecute una prueba de esfuerzo. En este tipo de prueba se especifica principalmente el número máximo de usuarios y el tiempo durante el cual la rampa hacia arriba y la carga de estado estable deben estar en la aplicación. El objetivo es identificar los puntos de interrupción de la aplicación en prueba.

Objetivos

+ Escalabilidad y estabilidad de prueba

+ Simular condiciones de carga máxima

+ La reproducibilidad exacta no es importante

Comparación

Obviamente, hay buenas razones para el protocolo, sin cabeza o simulación de usuario real basado en navegador. La matriz siguiente proporciona algunas instrucciones para elegir el enfoque adecuado.

Criterios

HTTP

Navegador sin cabeza

Navegador real

Simulación de usuario

Sin

renderizado del lado del cliente

Algunos elementos del lado del cliente se simulan

Simulación de usuario real

Script

Implementación y personalización de scripts

Difícil cuando los sitios web son complejos

Habilidades de desarrollador necesarias para crear scripts robustos

Scripts simples, fáciles de personalizar


S

cript repetición

Se requiere un análisis de bajo nivel

Dependiendo del motor utilizado, la reproducción visual es posible

Ves lo que obtienes

Mantenibilidad del script

Habilidades de programación requeridas

Los errores en las secciones no renderizadas son difíciles de resolver

Fácil porque ves fallos durante la reproducción

Soporte multinavegador

Algunas herramientas emulan los navegadores web, pero esto no es comparable

Sí, pero a menudo faltan algunos elementos

Algunos admiten otras versiones y diferentes navegadores

F

ootprint en la máquina de inyección de carga


Bajo

, hasta 800 sesiones por servidor

Medio,

hasta

10-12

sesiones por servidor


Alto

, hasta 6 sesiones por servidor

Recomendado

para

DevOps

Depende del escenario de prueba real

No, a menudo guiones complejos

Sí, figuras fáciles de usar y realistas

Recomendado para pruebas de carga

No,

se omite elprocesamiento del lado cliente

Sí, mejor que la simulación HTTP

Sí, simulación de usuario realista

Recomendado para pruebas de estrés

Sí, porque hay una sobrecarga baja en la máquina generadora de carga

No, la sobrecarga de la máquina generadora de carga es demasiado alta

No,

la mayor sobrecarga en la máquina generadora de carga

Costos

Bajo

Alto

Alto

Recomendado para pruebas de alto volumen y bajo costo pruebas de esfuerzo del servidor web (siempre que sea posible)

No recomendado

Recomendado para simulaciones de aplicaciones complejas de la vida real.

Prueba de estrés

Si tiene que probar la fiabilidad de la aplicación en condiciones de carga máxima, ejecute una prueba de esfuerzo. En este tipo de prueba se especifica principalmente el número máximo de usuarios y el tiempo durante el cual la rampa hacia arriba y la carga de estado estable deben estar en la aplicación. El objetivo es identificar los puntos de interrupción de la aplicación en prueba.

Objetivos

+ Escalabilidad y estabilidad de prueba

+ Simular condiciones de carga máxima

+ La reproducibilidad exacta no es importante

Comparación

Obviamente, hay buenas razones para el protocolo, sin cabeza o simulación de usuario real basado en navegador. La matriz siguiente proporciona algunas instrucciones para elegir el enfoque adecuado.

Criterios HTTP Navegador sin cabeza Navegador real
Simulación de usuario Sin renderizado del lado del cliente Algunos elementos del lado del cliente se simulan Simulación de usuario real
Implementación y personalización de scripts Difícil cuando los sitios web son complejos Habilidades de desarrollador necesarias para crear scripts robustos Scripts simples, fáciles de personalizar
Reproducción de guiones Se requiere un análisis de bajo nivel Dependiendo del motor usado es posible la reproducción visual Ves lo que obtienes
Mantenibilidad del script Habilidades de programación requeridas Los errores en secciones no renderizadas son difíciles de resolver Fácil porque ves fallos durante la reproducción
Soporte multinavegador Algunas herramientas emulan el navegador web, pero esto no es comparable Sí, pero a menudo faltan algunos elementos Algunos admiten otras versiones y diferentes navegadores
Huella en la máquina de inyección de carga Baja, hasta 800 sesiones por servidor Media, hasta 10-12 sesiones por servidor Alta, hasta 6 sesiones por servidor
Recomendado para DevOps Depende del escenario de prueba real No, a menudo guiones complejos Sí, figuras fáciles de usar y realistas
Recomendado para pruebas de carga No, el procesamiento del lado del cliente se omite Sí, mejor que la simulación HTTP Sí, simulación de usuario realista
Recomendado para pruebas de estrés Sí, porque hay una baja sobrecarga en la máquina generadora de carga No, la sobrecarga de la máquina generadora de carga es demasiado alta No, la mayor sobrecarga en la máquina generadora de carga
Costos Bajo Alto Alto
Recomendado para pruebas de alto volumen y bajo costo pruebas de esfuerzo del servidor web (siempre que sea posible) No recomendado Recomendado para simulaciones de aplicaciones complejas de la vida real.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email
Share on print
Impresión