Resumen
Las páginas web lentas o que no responden tienen un impacto en los ingresos financieros porque los usuarios frustrados probablemente no volverán una vez que se resuelva 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 ofrecen una amplia gama de métodos de simulación de carga, como HTTP, navegadores sin interfaz gráfica (headless) y navegadores reales. En este documento, describiremos los principales aspectos de estos métodos, seguidos de una matriz comparativa que puedes utilizar para elegir el 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 las tecnologías de cliente web enriquecido, los enfoques de simulación basados en HTTP se han vuelto cada vez más obsoletos. Un controlador de pruebas típico basado en HTTP ejecuta solicitudes de servicio y analiza las respuestas. Las aplicaciones modernas web 2.0 consisten en muchos scripts del lado del cliente, que son completamente ignorados y no se miden en este tipo de ejecución de prueba. En los peores casos, los casos de uso complejos no se pueden simular a nivel de protocolo debido a la falta de identificadores generados en el lado del cliente.
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 típico de pruebas de carga 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 manejar cookies, IDs de sesión y otros parámetros dinámicos. Dependiendo del tipo de sistema que se esté probando, algunos nombres de formularios web a menudo cambian una vez que se implementa una nueva versión, lo que hará que el script basado en HTTP falle.
Simulación de carga basada en navegador sin interfaz gráfica (headless)
Con el auge de las tecnologías web 2.0, el negocio de las pruebas se enfrentó a desafíos serios. Las aplicaciones ricas en navegador ya no podían ser probadas o simuladas a nivel de protocolo debido a la falta de lógica del lado del cliente durante la reproducción del script. Por lo tanto, se introdujeron varios navegadores sin interfaz gráfica como HtmlUnit, PhantomJS o SlimerJS. A menudo están construidos sobre WebKit, el motor detrás de Chrome y Safari.
Los navegadores sin interfaz gráfica son similares a los navegadores reales pero sin la interfaz visual. Muchas plataformas de automatización de pruebas y pruebas de rendimiento utilizan navegadores headless para simular tráfico.
Los navegadores headless tienen sus propias desventajas; a medida que nuevos navegadores entran al mercado, los kits de navegadores headless deben ponerse al día con todas las mejoras de rendimiento y características de los navegadores reales.
La simulación del renderizado del lado del cliente no es gratuita. Un servidor típico de inyección de carga puede simular hasta 10-12 sesiones simultáneas de navegadores headless, frente a 500 sesiones basadas en HTTP.
La implementación y personalización de scripts de prueba no es demasiado difícil. Si tienes habilidades básicas de programación podrás crear scripts simples. No todos los navegadores headless proporcionan funciones de reproducción visual y sin ella, la depuración de scripts o el análisis de errores puede ser muy complicado.
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 basadas en navegador real te permiten verificar la funcionalidad y la velocidad del sitio tal como las percibe el usuario final.
Una solución típica de prueba de rendimiento con navegador real 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 carga de un navegador real es ligeramente mayor. Considerando que la simulación con navegador headless no entrega tiempos de respuesta 100% realistas, es justo decir que se debe preferir la simulación basada en navegador real. En escenarios reales, los navegadores headless solo rinden un 20% mejor que los navegadores reales. Así que, si un inyector de carga promedio puede ejecutar 10-12 sesiones headless, ese mismo inyector puede ejecutar 8-10 sesiones de navegador real.
La implementación y el mantenimiento de los 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 a continuación, el navegador abre una URL, introduce usuario y contraseña y hace clic en el botón de inicio de sesión.
Tipos de pruebas de rendimiento
Pruebas de velocidad de componentes
En los últimos años, los métodos de desarrollo de software se han orientado hacia lo ágil. Los lanzamientos cortos son esenciales. Los desarrolladores e ingenieros de prueba automatizan su aseguramiento de calidad y las verificaciones de rendimiento. Normalmente, implementan pruebas de rendimiento basadas en servicios a nivel de protocolo o simulan verificaciones de rendimiento con navegador real para comparar los tiempos de respuesta de extremo a extremo con los límites de rendimiento acordados.
Objetivos
- + Repetibilidad
- + Verificaciones automatizadas de interfaz y rendimiento de extremo a extremo
- + Comparar tiempos de respuesta con umbrales acordados
Pruebas de carga
Por varias razones, las pruebas de carga son el método ideal para verificar requisitos no funcionales. Una de ellas es que los tiempos de respuesta se pueden verificar en condiciones reproducibles. Otra es que estas pruebas permiten la verificación de los umbrales de tiempo de respuesta. La medición realista del tiempo de respuesta es esencial en los escenarios de prueba de carga. Por lo tanto, los ingenieros de prueba utilizan simulación de usuario con navegador headless o real para sus configuraciones de pruebas de carga.
Objetivos
- + Simulación de carga reproducible
- + Verificación de los umbrales de tiempo de respuesta
- + Identificar cuellos de botella en condiciones de carga similares a producción
- + Escenarios realistas de prueba de extremo a extremo
Pruebas de estrés
Si necesitas probar la fiabilidad de tu aplicación bajo condiciones de carga máxima, ejecuta una prueba de estrés. En este tipo de prueba especificas principalmente el número máximo de usuarios y el tiempo durante el cual el aumento y la carga estable deben mantenerse en tu aplicación. El objetivo es identificar los puntos de quiebre de tu aplicación bajo prueba.
Objetivos
- + Comprobar escalabilidad y estabilidad
- + Simular condiciones de carga máxima
- + La reproducibilidad exacta no es importante
Comparación
Obviamente, existen buenas razones para utilizar simulación de usuario basada en protocolo, headless o navegador real. La siguiente matriz proporciona una guía para elegir el enfoque adecuado.
| Criterio | HTTP | Navegador Headless | Navegador Real |
|---|---|---|---|
| Simulación de usuario | Sin renderizado del lado del cliente | Se simulan algunos elementos del lado del cliente | Simulación real del usuario |
| Implementación y personalización del script | Difícil cuando los sitios web son complejos | Se requieren habilidades de desarrollador para construir scripts robustos | Scripts simples, fáciles de personalizar |
| Reproducción del script | Se requiere análisis de bajo nivel | Dependiendo del motor usado, es posible la reproducción visual | Ves exactamente lo que ocurre |
| Mantenibilidad del script | Se requieren habilidades de programación | Los errores en secciones no renderizadas son difíciles de resolver | Fácil porque ves los fallos durante la reproducción |
| Soporte multinavegador | Algunas herramientas emulan navegadores, pero no es comparable | Sí, pero a menudo faltan algunos elementos | Algunos soportan otras versiones y distintos 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 | No, los scripts suelen ser complejos | Sí, fácil de usar y cifras realistas |
| Recomendado para pruebas de carga | No, se omite el procesamiento del lado del cliente | Sí, mejor que la simulación HTTP | Sí, simulación realista del usuario |
| Recomendado para pruebas de estrés | Sí, porque hay poca sobrecarga en la máquina generadora de carga | No, la sobrecarga en la máquina generadora es demasiado alta | No, la mayor sobrecarga en la máquina generadora |
| Costes | Bajo | Alto | Alto |
| Recomendado para pruebas de alto volumen y bajo coste de servidores web (cuando sea posible) | No recomendado | Recomendado para simulaciones complejas de aplicaciones reales |
Páginas web utilizadas para este documento:
- 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/