fbpx

Tipos de pruebas de rendimiento y simulación de carga

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 vuelvan una vez 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/S, sin cabeza y basados en exploradores reales. En este artículo, describiremos los aspectos principales de cada uno, seguido 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 nuestra era digital, las pruebas basadas en HTTP eran muy populares. Con el auge de la rica tecnología de cliente web, este enfoque se ha vuelto cada vez más obsoleto. 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. Debido a la escasez de ID de sesión generados del lado cliente, los casos de uso complejos no se pueden simular en el nivel de protocolo.

Debido a su naturaleza basada en solicitudes y respuestas, 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 tratar las cookies, los ID de sesión y otros parámetros dinámicos. Dependiendo de la tecnología del 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 hará que el script basado en HTTP falle.

El script de ejemplo siguiente muestra 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.


//sample protocol level script
transaction TMain
var
hContext: number;
begin
WebPageUrl("https://lab3/st/", "Greetings");
WebPageStoreContext(hContext);
WebPageLink("Join the experience!", " - New Visitor");
WebPageSubmit("Continue", CONTINUE001, "Main menu");
WebPageLink("Products", "ShopIt - Products");
WebPageLink(NULL, "ShopIt - Product", 3);
WebPageSubmit("Search", SEARCH001, " - Search", 0, NULL, hContext);
end TMain;

dclform
CONTINUAR001:
«name» :- «jack»,
«Botón de Nombre Nuevo» :- «Continuar»;

SEARCH001:
«search» :- «boot»;

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

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

Los navegadores sin cabeza tienen todas las ventajas de los navegadores reales y se ejecutan más rápido sin la interfaz gráfica de usuario pesada. Muchas plataformas de automatización de pruebas y pruebas de rendimiento utilizan navegadores sin cabeza, ya que permiten la simulación de usuario realista.

Algunos proveedores han construido sus propios motores de navegador sin cabeza, pero se han convertido en trampas de mantenimiento porque tienen que mantenerse al día con las nuevas versiones del navegador. En esta situación, es muy recomendable utilizar cualquier kits de navegador sin cabeza disponibles libremente porque hay una amplia comunidad que funciona en mejoras.

La simulación de la representación del lado cliente no es gratuita. Un servidor de inyección de carga típico puede simular hasta 8 sesiones simultáneas del navegador sin cabeza.

La implementación y personalización del script de prueba no es demasiado difícil. Si tiene habilidades básicas para desarrolladores, podrá crear scripts simples. No todos los navegadores sin cabeza proporcionan características de reproducción visual y sin reproducción visual, la depuración de scripts y el análisis de errores pueden llegar a ser muy complicados.

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


//sample phantomjs script
"use strict";
var page = require('webpage').create(),
server = 'https://posttestserver.com/post.php?dump',
data = 'universe=expanding&answer=42';

page.open(servidor, ‘post’, datos, función (estado)
if (status !- ‘success’)
console.log(‘No se puede publicar!’);
•otra cosa?
console.log(page.content);
}

phantom.exit();
});

Teniendo en cuenta esto, los navegadores sin cabeza son el camino a seguir si tienes habilidades de programación y usas una solución, que permite la reproducción de scripts visuales.

 

Simulación de carga basada en navegador real

Las aplicaciones Web 2.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 navegador 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 explorador 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 real basado en navegador es ligeramente mayor. Debido a que la simulación del navegador sin cabeza no ofrece 100percent tiempos de respuesta realistas, es justo decir que la simulación real basada en navegador debe ser el método preferido para las pruebas.

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 siguiente, el explorador abre una dirección URL, inserta la contraseña del usuario y hace clic en el botón de inicio de sesión.


//sample real browser-based script
transaction TMain
begin
BrowserStart(BROWSER_MODE_DEFAULT, 800, 600);

navegar al sitio de inicio de sesión
BrowserNavigate(«https://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 real del navegador es útil para pruebas de carga realistas de extremo a extremo. Sin embargo, no lo use para pruebas de esfuerzo porque la huella en el servidor de inyección de carga es demasiado alta.

 

Diferentes tipos de pruebas de carga y 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 su garantía de calidad y comprobaciones de rendimiento. Normalmente, implementan pruebas de rendimiento basadas en servicios en el nivel de protocolo o simulan comprobaciones de rendimiento reales basadas en explorador para comparar 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
  • Comparación de los tiempos de respuesta con los umbrales acordados

Pruebas de carga

La carga prueba la configuración ideal cuando se trata de la verificación de los requisitos no funcionales. Una razón es que los tiempos de respuesta se pueden verificar 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 sin cabeza o basada en navegador real para su configuración de prueba de carga.

Objetivos

  • Simulación de carga reproducible
  • Verificación de los umbrales de tiempo de respuesta
  • Identificación de cuellos de botella en condiciones de carga similares a la producción
  • Creación de escenarios de prueba realistas de extremo a extremo

Pruebas de estrés

Si tiene que demostrar la fiabilidad de la aplicación en condiciones de carga máxima, ejecute una prueba de esfuerzo para determinar el punto de interrupción del sistema.

Objetivos

  • Demuestra escalabilidad y estabilidad
  • Simular condiciones de carga máxima
  • La reproducibilidad no es importante

 

Comparación

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

Criterios HTTP Navegador sin cabeza Navegador real
Simulación de usuario (1) No hay representación del lado del cliente (2) Algunos elementos del lado cliente se simulan (3) Simulación de usuario real
Implementación y personalización de scripts (1) Difícil cuando los sitios web son complejos (2) Habilidades de desarrollador necesarias para crear scripts robustos (3) scripts simples, fáciles de personalizar
Reproducción de guiones (1) Análisis de bajo nivel requerido (2) Dependiendo del motor usado es posible la reproducción visual (3) Ves lo que obtienes
Mantenimiento del script (1) Habilidades de programación requeridas (2) Los errores en las secciones no renderizadas son difíciles de resolver (3) Fácil porque ves fallas durante la repetición
Soporte multi navegador (1) Algunas herramientas emulan los navegadores web, pero esto no es comparable (2) Sí, pero a menudo faltan algunos elementos (2) Algunos soportan otras versiones y diferentes navegadores
Huella en la máquina de inyección de carga (3) Bajo, hasta 800 sesiones por servidor (2) Medio, hasta 8 sesiones por servidor (1) Alto, hasta 6 sesiones por servidor
Recomendado para DevOps (2) Depende del escenario real de la prueba (1) No, a menudo scripts complejos (3) Sí, figuras fáciles de usar y realistas
Recomendado para pruebas de carga (1) No, el procesamiento del lado del cliente se omite (2) Sí, mejor que la simulación HTTP (3) Sí, simulación de usuario realista
Recomendado para pruebas de estrés (3) Sí, porque hay una baja sobrecarga en la máquina generadora de carga (2) No, la sobrecarga de la máquina generadora de carga es demasiado alta (1) No, la sobrecarga más alta en la máquina generadora de carga
Costos (3) Bajo (2) Medio (1) Alto
Puntuación total 17 19 24