Las p\u00e1ginas web lentas o que no responden tienen un impacto en los ingresos financieros porque los usuarios frustrados probablemente no volver\u00e1n 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.<\/p>\n
Las plataformas de pruebas de rendimiento ofrecen una amplia gama de m\u00e9todos de simulaci\u00f3n de carga, como HTTP, navegadores sin interfaz gr\u00e1fica (headless) y navegadores reales. En este documento, describiremos los principales aspectos de estos m\u00e9todos, seguidos de una matriz comparativa que puedes utilizar para elegir el enfoque de simulaci\u00f3n adecuado.<\/p>\n
En los primeros d\u00edas de la era digital, las pruebas basadas en HTTP eran muy populares. Con el auge de las tecnolog\u00edas de cliente web enriquecido, los enfoques de simulaci\u00f3n basados en HTTP se han vuelto cada vez m\u00e1s obsoletos. Un controlador de pruebas t\u00edpico 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\u00f3n 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.<\/p>\n
Debido a su naturaleza basada en solicitudes y respuestas, la sobrecarga en la m\u00e1quina de inyecci\u00f3n de carga es muy baja. Un servidor t\u00edpico de pruebas de carga puede simular hasta 800 sesiones simult\u00e1neas. Los casos de uso complejos basados en protocolos pueden ser dif\u00edciles de implementar. Un ingeniero de rendimiento debe manejar cookies, IDs de sesi\u00f3n y otros par\u00e1metros din\u00e1micos. Dependiendo del tipo de sistema que se est\u00e9 probando, algunos nombres de formularios web a menudo cambian una vez que se implementa una nueva versi\u00f3n, lo que har\u00e1 que el script basado en HTTP falle.<\/p>\n
Con el auge de las tecnolog\u00edas web 2.0, el negocio de las pruebas se enfrent\u00f3 a desaf\u00edos serios. Las aplicaciones ricas en navegador ya no pod\u00edan ser probadas o simuladas a nivel de protocolo debido a la falta de l\u00f3gica del lado del cliente durante la reproducci\u00f3n del script. Por lo tanto, se introdujeron varios navegadores sin interfaz gr\u00e1fica como HtmlUnit, PhantomJS o SlimerJS. A menudo est\u00e1n construidos sobre WebKit, el motor detr\u00e1s de Chrome y Safari.<\/p>\n
Los navegadores sin interfaz gr\u00e1fica son similares a los navegadores reales pero sin la interfaz visual. Muchas plataformas de automatizaci\u00f3n de pruebas y pruebas de rendimiento utilizan navegadores headless para simular tr\u00e1fico.<\/p>\n
Los navegadores headless tienen sus propias desventajas; a medida que nuevos navegadores entran al mercado, los kits de navegadores headless deben ponerse al d\u00eda con todas las mejoras de rendimiento y caracter\u00edsticas de los navegadores reales.<\/p>\n
La simulaci\u00f3n del renderizado del lado del cliente no es gratuita. Un servidor t\u00edpico de inyecci\u00f3n de carga puede simular hasta 10-12 sesiones simult\u00e1neas de navegadores headless, frente a 500 sesiones basadas en HTTP.<\/p>\n
La implementaci\u00f3n y personalizaci\u00f3n de scripts de prueba no es demasiado dif\u00edcil. Si tienes habilidades b\u00e1sicas de programaci\u00f3n podr\u00e1s crear scripts simples. No todos los navegadores headless proporcionan funciones de reproducci\u00f3n visual y sin ella, la depuraci\u00f3n de scripts o el an\u00e1lisis de errores puede ser muy complicado.<\/p>\n
Las aplicaciones web 2.0 est\u00e1n 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\u00e1gina 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.<\/p>\n
Una soluci\u00f3n t\u00edpica de prueba de rendimiento con navegador real recopila tiempos de carga de im\u00e1genes, JavaScript, CSS y m\u00e1s. A menudo proporcionan gr\u00e1ficos de cascada que visualizan el tiempo de carga de esos componentes.<\/p>\n
La carga de un navegador real es ligeramente mayor. Considerando que la simulaci\u00f3n con navegador headless no entrega tiempos de respuesta 100% realistas, es justo decir que se debe preferir la simulaci\u00f3n basada en navegador real. En escenarios reales, los navegadores headless solo rinden un 20% mejor que los navegadores reales. As\u00ed que, si un inyector de carga promedio puede ejecutar 10-12 sesiones headless, ese mismo inyector puede ejecutar 8-10 sesiones de navegador real.<\/p>\n
La implementaci\u00f3n y el mantenimiento de los scripts de prueba es f\u00e1cil porque las acciones del usuario se reflejan directamente y la reproducci\u00f3n visual facilita la depuraci\u00f3n. En el script de ejemplo a continuaci\u00f3n, el navegador abre una URL, introduce usuario y contrase\u00f1a y hace clic en el bot\u00f3n de inicio de sesi\u00f3n.<\/p>\n
En los \u00faltimos a\u00f1os, los m\u00e9todos de desarrollo de software se han orientado hacia lo \u00e1gil. 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\u00edmites de rendimiento acordados.<\/p>\n
Objetivos<\/p>\n
Por varias razones, las pruebas de carga son el m\u00e9todo 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\u00f3n de los umbrales de tiempo de respuesta. La medici\u00f3n realista del tiempo de respuesta es esencial en los escenarios de prueba de carga. Por lo tanto, los ingenieros de prueba utilizan simulaci\u00f3n de usuario con navegador headless o real para sus configuraciones de pruebas de carga.<\/p>\n
Objetivos<\/p>\n
Si necesitas probar la fiabilidad de tu aplicaci\u00f3n bajo condiciones de carga m\u00e1xima, ejecuta una prueba de estr\u00e9s. En este tipo de prueba especificas principalmente el n\u00famero m\u00e1ximo de usuarios y el tiempo durante el cual el aumento y la carga estable deben mantenerse en tu aplicaci\u00f3n. El objetivo es identificar los puntos de quiebre de tu aplicaci\u00f3n bajo prueba.<\/p>\n
Objetivos<\/p>\n
Obviamente, existen buenas razones para utilizar simulaci\u00f3n de usuario basada en protocolo, headless o navegador real. La siguiente matriz proporciona una gu\u00eda para elegir el enfoque adecuado.<\/p>\n