La carga lenta o las páginas web no receptivas tienen un impacto directo en los ingresos financieros. Es fundamental asegurarse de configurar sus pruebas de rendimiento con la simulación de carga correcta. Si no se hace correctamente, podría tener efectos desastrosos. Lo más probable es que los usuarios frustrados abandonen lo que estaban haciendo y no regresen. Incluso si usted y su equipo han resuelto este problema, es probable que sea demasiado tarde. Probablemente ya han encontrado una solución alternativa. Y una vez que lo han hecho, es poco probable que cambien de nuevo.
No sólo tiene que preocuparse por la pérdida de ingresos, pero otros factores, como la confianza del consumidor, la integridad de la marca, etc., son probablemente más perjudiciales para el negocio. Cuanto más dure el problema, más difícil será recuperar la confianza del consumidor. No sólo eso, el retorno de las inversiones que hizo en su producto, equipo y organización va a tomar más tiempo para darse cuenta, si es que lo hace. Por lo tanto, las pruebas de rendimiento (y el monitoreo) se han convertido en una parte fundamental y crítica de la cadena de desarrollo de software y aplicaciones. La necesidad de una solución que pueda ejecutar pruebas de rendimiento de forma adecuada y precisa de cerca de la experiencia del usuario es muy demandada.
Las plataformas de pruebas de rendimiento proporcionan una amplia gama de métodos de simulación de carga, como HTTP/S, pruebas sin cabeza y basadas en navegador 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 tecnología de cliente web enriquecido, este enfoque se ha vuelto cada vez más obsoleto (y las pruebas de rendimiento con herramientas como JMeter también se han vuelto un poco obsoletas). 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 formularios 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.
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 reescribir todo el script, que es más fácil decirlo que hacerlo.
//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 de nivel de componente en entornos de integración continua y, debido a su baja huella en las máquinas de inyección de carga, son el escenario perfecto 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 quedado con dificultades de mantenimiento porque deben mantenerse al día con las nuevas versiones del navegador. En esta situación, se recomienda encarecidamente utilizar cualquier kit de navegador sin cabeza disponible gratuitamente porque hay una amplia comunidad que trabaja 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 ocho sesiones simultáneas de 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 conocimientos 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();
});
Con esta consideración en mente, los navegadores sin cabeza son el camino a seguir si usted tiene habilidades de programación y usted está utilizando 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, CSS, etc. Sin un navegador completo, no es posible medir los tiempos reales de respuesta de extremo a extremo de toda la aplicación o página web. Las pruebas de rendimiento reales basadas en el navegador le permiten verificar la funcionalidad y la velocidad del sitio según lo percibido por el usuario final, que como discutimos anteriormente, es donde realmente cuenta.
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 tiempos de respuesta 100% realistas, es justo decir que la simulación basada en navegador real 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 (y, a veces, pruebas de API) a nivel de protocolo, o simulan comprobaciones de rendimiento reales basadas en navegador para comparar los tiempos de respuesta de extremo a extremo con los límites de rendimiento acordados.
Objetivos de las pruebas de velocidad de componentes:
- Verifique y repita el comportamiento de entrada/salida.
- Comprobación automatizada de la interfaz y del rendimiento de extremo a extremo.
- Comparación de tiempos de respuesta con 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 de las pruebas de carga:
- Simulación de carga reproducible.
- Verificación de 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 de extremo a extremo realistas.
Pruebas de estrés
Si debe demostrar la fiabilidad de la aplicación en condiciones de carga máxima, ejecute una prueba de esfuerzo para determinar el punto de ruptura del sistema.
Objetivos de las pruebas de estrés:
- Demostrar escalabilidad y estabilidad en las condiciones máximas del tráfico.
- Observe cómo el sistema falla y vuelve a estar en línea.
- La reproducibilidad no es importante.
Comparación
Obviamente, hay buenas razones y situaciones para el protocolo, sin cabeza, y simulaciones de usuario basadas en navegador real. La siguiente matriz proporciona algunas instrucciones sobre cuándo elegir el enfoque de prueba 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 |
Con suerte, este artículo sobre simulación de carga y tipos de pruebas de rendimiento le ha dado una idea adicional de sus pruebas de rendimiento. Si tiene alguna pregunta sobre la ejecución de pruebas de carga y esfuerzo, o sobre la solución LoadView en general, póngase en contacto con nuestro equipo o regístrese para obtener una demostración con uno de nuestros ingenieros de rendimiento.