Pruebas de carga:
HTTP vs Headless vs Real Browser
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.
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”;
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.
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.
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.
Performance Test Types
Component Speed Tests
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
Load Tests
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
Stress Test
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 esfuerzo
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.
|
- https://developers.google.com/web/tools/chrome-devtools/device-mode/testing-other-browsers
- https://watirmelon.blog/2015/12/08/real-vs-headless-browsers-for-automated-acceptance-tests/
- http://news.softpedia.com/news/what-is-a-headless-browser-and-what-s-it-good-for-485162.shtml
- https://github.com/dhamaniasad/HeadlessBrowsers
- https://circleci.com/
