Un Popurrí de Pruebas de Rendimiento Frontend y Backend

Rate this content
Bookmark

En esta charla, quiero presentarte tanto las pruebas de rendimiento frontend como backend y por qué es necesario un popurrí de estas actividades de prueba para asegurarte de que tu sitio web tenga un buen rendimiento. También daré una breve explicación de cómo herramientas como xk6-browser pueden ayudar a ejecutar pruebas tanto a nivel de protocolo (cómo se suelen ejecutar las pruebas de rendimiento a través de interacciones simultáneas en la capa de protocolo) como a nivel de navegador (pruebas con navegadores reales para proporcionar una prueba de rendimiento más realista).

Al final de esta charla, deberías estar equipado con nuevos conocimientos sobre las pruebas de rendimiento frontend y backend que puedes aplicar a tus proyectos de trabajo.

34 min
03 Nov, 2022

Video Summary and Transcription

Las pruebas de rendimiento son la práctica de medir y evaluar la respuesta del sistema. Las pruebas de rendimiento frontend y backend son cruciales para identificar cuellos de botella. XK6 Browser es una nueva herramienta que permite la automatización del navegador y pruebas web de extremo a extremo. K6 es una herramienta de prueba versátil que cubre varios casos de uso. La combinación de pruebas a nivel de navegador y protocolo proporciona una visión integral del rendimiento.

Available in English

1. Introducción a las pruebas de rendimiento

Short description:

Bienvenidos a mi charla llamada Un Popurrí de Pruebas de Rendimiento Front-end y Back-end. Las pruebas de rendimiento son la práctica de medir y evaluar cómo responde su sistema bajo ciertas condiciones. Las pruebas de carga son solo un tipo de prueba de rendimiento. Durante los momentos de mayor demanda, como el Viernes Negro, los tiempos de respuesta pueden aumentar significativamente y causar errores.

♪♪♪ ¡Hola a todos! Mi nombre es Marie. Y bienvenidos a mi charla llamada Un Popurrí de Pruebas de Rendimiento Front-end y Back-end. Antes de comenzar con mi charla, quiero contarles una historia primero. Esta historia trata sobre Overcooked. He estado jugando este juego con mi hija de 5 años. Y si no están muy familiarizados con Overcooked, es un juego cooperativo en el que tienes que superar diseños de cocina diferentes e inusuales y servir la mayor cantidad de comida posible a los clientes.

Cuando comienza el juego, todo es bastante normal. Los pedidos llegan sin problemas y recibes tips porque sirves los pedidos de sushi a tiempo. A medida que el juego se vuelve más difícil y recibes más pedidos de los esperados, la cocina se ve abrumada. Y sin una coordinación y trabajo en equipo adecuados, la cocina se incendia. Además, ya no recibes tips. Y tienes clientes hambrientos esperando impacientes su comida. Debido a que la cocina no puede mantenerse al día con los pedidos abrumadores de los clientes, toda la cocina se incendia. Por supuesto, esto es muy dramático, pero al final, te haces una idea. Los clientes están muy descontentos, recibes tips negativos, y la cocina es un desastre que ni siquiera puedes cocinar una sola papa.

Volviendo a mi tema de pruebas de rendimiento, imagina que estás tratando de comprar algunos artículos durante las ventas del Viernes Negro o el Cyber Monday. Encontraste un artículo que realmente te gusta, pero de repente, el sitio web que estabas usando se ha caído. No puede mantenerse al día con las solicitudes abrumadoras de diferentes usuarios simultáneamente. Esto es un fenómeno muy común durante las ventas del Viernes Negro. También puedes ver en este ejemplo de gráfico que durante los momentos de mayor demanda de las ventas del Viernes Negro, los tiempos de respuesta son significativamente más altos en comparación con los períodos normales. Esto ha resultado en errores de tiempos de respuesta que pueden dañar tu sitio web. La mayoría de las veces, la respuesta de las empresas es comprar más servidores, pensando que esto solucionará sus problemas de rendimiento, pero esto podría terminar costándote más dinero. Una mejor inversión es comprender, probar, monitorear y realizar mejoras de rendimiento en tu aplicación interna.

2. Pruebas de rendimiento y herramientas

Short description:

Ahora pasemos a la parte más seria de esta charla. Las pruebas de rendimiento son la práctica de medir y evaluar cómo responde su sistema bajo ciertas condiciones. Las pruebas de carga son solo un tipo de prueba de rendimiento. Las pruebas de rendimiento se dividen típicamente en dos áreas: rendimiento en el front-end o lado del cliente y rendimiento en el back-end o lado del servidor. La regla de oro del rendimiento web establece que el 80 al 90% del tiempo de carga se gasta en el front-end, mientras que el 10 al 20% se gasta en el back-end. Las pruebas de rendimiento en el front-end se limitan en alcance y se centran en la experiencia del usuario final, mientras que las pruebas de rendimiento en el back-end ayudan a identificar cuellos de botella de rendimiento. Existen diversas herramientas de pruebas de rendimiento disponibles, como Lighthouse, Google PageSpeed, SiteSpeed.io y WebPagetest.

Ahora pasemos a la parte más seria de esta charla. Para asegurarnos de que nuestros usuarios tengan una experiencia positiva, necesitamos realizar pruebas de rendimiento. Las pruebas de rendimiento son la práctica de medir y evaluar cómo responde su sistema bajo ciertas condiciones. Cuando pensamos en pruebas de rendimiento, nos preocupamos por la velocidad, confiabilidad y estabilidad de la aplicación que estamos probando.

Con las pruebas de rendimiento, a menudo hay una idea errónea de que se trata solo de pruebas de carga. Las pruebas de rendimiento son el término general para cualquier tipo de prueba de rendimiento, mientras que las pruebas de carga son solo un tipo de prueba de rendimiento. En resumen, las pruebas de carga verifican cómo se comporta su aplicación cuando se expone a un gran número de usuarios virtuales concurrentes, enviando múltiples solicitudes al mismo tiempo. Dentro de las pruebas de carga, también existen diferentes variaciones como pruebas de estrés, pruebas de saturación o pruebas de picos.

Las pruebas de rendimiento se dividen típicamente en dos áreas. Tenemos el rendimiento en el front-end o lado del cliente, que se enfoca en probar qué tan rápido un usuario puede ver las respuestas web al instante. Se preocupa por la experiencia del usuario final de una aplicación, que generalmente involucra un navegador. Las pruebas de rendimiento en el front-end tienen métricas distintas de las pruebas de rendimiento en el back-end. Ejemplos de métricas podrían ser, ¿cuánto tiempo tardó el navegador en renderizar la página completa o cuánto tiempo tardó en ser completamente interactiva la página? Por otro lado, tenemos el rendimiento en el back-end o lado del servidor, que se enfoca en asegurarse de que cuando se envían múltiples solicitudes de diferentes usuarios de manera simultánea, su back-end pueda manejar la carga adecuadamente. Ejemplos de métricas podrían ser, ¿cuánto tiempo tardó en recibir una respuesta de una solicitud específica o ¿cuántas solicitudes fallidas encontramos?

Como pueden ver, las pruebas de rendimiento no se limitan solo a las pruebas de carga. Con diferentes tipos de pruebas de rendimiento, podrían preguntarse cuál es más importante. La respuesta, como siempre, es que depende. Si volvemos a la regla de oro del rendimiento web, establece que el 80 al 90% del tiempo de carga de una página web o aplicación se gasta en el front-end, mientras que el 10 al 20% se gasta en el back-end. Pueden ver en esta imagen, que tomé del blog de Steve Souder, que el tiempo promedio en el front-end es significativamente mayor en comparación con los tiempos en el back-end. Si seguimos esta regla de oro, y queremos realizar mejoras de rendimiento, siempre es una gran idea comenzar por el front-end y hacer pequeñas recomendaciones a su equipo. Las pruebas de rendimiento en el front-end también están mucho más cerca de la experiencia de nuestros usuarios. Sin embargo, la regla de oro del rendimiento web no siempre es necesariamente precisa. Si tienen mucho tráfico llegando a su sitio web, el tiempo de respuesta en el front-end puede permanecer aproximadamente igual. Pero una vez que su back-end lucha con la mayor concurrencia, el tiempo en el back-end crecerá exponencialmente. Las pruebas de rendimiento en el front-end se ejecutan en el lado del cliente y, por lo tanto, están limitadas en alcance. No proporcionan suficiente información sobre toda su aplicación. Las pruebas de rendimiento en el back-end son realmente útiles cuando se trata de identificar cuellos de botella de rendimiento cuando sus servidores de aplicación han estado expuestos a altos niveles de carga. Al mismo tiempo, las pruebas de rendimiento en el front-end pueden detectar problemas relacionados solo con los navegadores, que pueden omitirse por completo desde el nivel de protocolo. Por eso es clave combinar ambos enfoques.

Continuando, quiero hablar un poco sobre las herramientas de pruebas de rendimiento porque hay una variedad de herramientas disponibles que pueden ayudarlo con sus necesidades de pruebas de rendimiento. Desde una perspectiva de front-end, herramientas como Lighthouse, Google PageSpeed, SiteSpeed.io, WebPagetest e incluso sus herramientas de desarrollo pueden ser útiles.

3. XK6 Browser: Simulando Pruebas Basadas en el Navegador

Short description:

Otras herramientas de prueba como Playwright y Cyprus ofrecen formas de medir el rendimiento en el front-end. XK6 Browser es una extensión de K6 que permite la automatización del navegador y pruebas web de extremo a extremo, al mismo tiempo que admite las funciones principales de K6. Agrega APIs de scripting a nivel de navegador para interactuar con navegadores reales y recopilar métricas del front-end como parte de las pruebas de K6. XK6 Browser todavía está en sus primeras etapas y actualmente es una extensión de K6. Para comenzar, instala XK6 a través de Go y crea una versión personalizada de K6 con XK6 Browser. Las pruebas se escriben en JavaScript y se pueden ejecutar usando XK6 browser run.

Otras herramientas de pruebas, como Playwright y Cyprus, también pueden ofrecer formas de medir el rendimiento en el front-end. Luego, si nos referimos a las herramientas del back-end, también tenemos JMeter, K6, Gatling, Torus, Locus y también Artillery, solo por mencionar algunas. Estas herramientas realizan predominantemente pruebas de rendimiento, comúnmente pruebas de carga a nivel de protocolo. Como pueden ver, necesitarían una combinación de diferentes herramientas para probar su front-end y back-end.

Pero, ¿qué pasa si hay una sola herramienta que se puede usar para ambas cosas? ¿Qué pasa si hay una herramienta que puede simular una prueba basada en el navegador con una prueba a nivel de protocolo para comprender cómo se comporta el front-end durante varios eventos de rendimiento? Aquí es donde entra XK6 Browser. XK6 Browser es una extensión de K6, que brinda automatización del navegador y pruebas web de extremo a extremo a K6 al mismo tiempo que admite las funciones principales de K6. Agrega APIs de scripting a nivel de navegador para interactuar con navegadores reales y recopilar métricas del front-end como parte de las pruebas de K6. Con XK6 Browser, esto te brinda la capacidad de medir cómo se comporta tu front-end durante ciertos eventos, lo cual sería difícil de captar desde el nivel de protocolo.

XK6 Browser, al igual que K6, está escrito en Go, pero las pruebas se escriben en JavaScript. También es una excelente noticia para los usuarios de Playwright porque XK6 Browser tiene como objetivo proporcionar una compatibilidad aproximada con la API de Playwright. XK6 Browser todavía está en sus primeras etapas, por lo que se ha creado como una extensión de K6, lo que significa que aún no está incluido como parte del núcleo de K6. Para comenzar con XK6 Browser, primero debes instalar XK6 a través de Go. Luego debes crear una versión personalizada de K6 con el binario de XK6 Browser agregado. Dado que las pruebas de K6 se escriben en JavaScript, ya habrá cierta familiaridad.

Para demostrar una prueba realmente simple, solo quiero visitar una URL de prueba. Para crear eso, primero necesito importar Chromium de XK6 Browser. Por el momento, XK6 Browser solo admite navegadores basados en Chromium, pero también tenemos planes para admitir Firefox y WebKit. A continuación, tengo mi función de exportación predeterminada, que es nuestro código de usuario virtual. Todo lo que está dentro de la función predeterminada se ejecutará una y otra vez por un usuario virtual, según tu configuración. Por ahora, esto solo se ejecutará una vez. Le estoy diciendo a Chromium que inicie un navegador, y como quiero ver el navegador, paso headless como falso. Luego le decimos al navegador que cree una nueva página. Para visitar nuestra URL de prueba, uso el método page.goto, pasando mi URL de prueba, y luego espero hasta que la red esté inactiva. Finalmente, solo cierro tanto mi página como mi navegador. Para ejecutar una prueba en XK6 Browser, solo necesitamos usar XK6 browser seguido del comando run y luego el nombre del archivo. Veamos eso en acción escribiendo XK6 browser run, seguido del archivo que quiero ejecutar. En este ejemplo, lo he guardado en una carpeta llamada ejemplos. Puedes ver que se ha abierto mi navegador Chrome y ha visitado la página. Cuando termine, K6 muestra un resumen de varias métricas de pruebas de rendimiento. Además de las métricas específicas de HTTP que K6 ya rastrea, ahora también se agregan algunas métricas de rendimiento del navegador, como descarga del navegador, primer pintado de contenido, primer pintado significativo, y más.

4. Automatización de la Funcionalidad de Inicio de Sesión

Short description:

Métricas como el tiempo promedio, el tiempo de respuesta máximo y el percentil 99 proporcionan información sobre el rendimiento del sitio web. Automatiza la funcionalidad de inicio de sesión lanzando una instancia de Chromium, pausando las acciones de entrada y navegación, creando una nueva página e interactuando con selectores. Admite operaciones asíncronas y espera a que se complete la navegación de la página. Cierra la página y el navegador después de ejecutar las pruebas. Se informan las métricas de rendimiento y los resultados de las afirmaciones.

Para cada una de estas métricas, obtienes una visión general del tiempo promedio, el tiempo de respuesta máximo, o incluso el percentil 99, entre otros. Esto te brinda una idea de qué tan eficiente es tu sitio web desde la perspectiva del navegador.

Hagamos el script un poco más complejo automatizando la funcionalidad de inicio de sesión. Digamos que quiero automatizar la escritura de mi nombre de usuario y contraseña, y luego verificar que haya iniciado sesión correctamente. Lancemos una instancia de Chromium, y observemos que, además de la opción headless, también estoy pausando en una opción llamada slow-mo, que ralentiza las acciones de entrada y navegación por el tiempo especificado. A continuación, creo una nueva página. Visito la misma URL de prueba nuevamente y espero hasta que la red esté inactiva. Después de eso, uso page.locator, que también se puede intercambiar por page.$ para interactuar con los selectores dados y realizar acciones adicionales para escribir el nombre de usuario y la contraseña.

Ahora, para tener un poco de contexto, muchas de las operaciones en Async son sincrónicas. Sin embargo, las operaciones de Playwright son asíncronas. Por lo tanto, también estamos tratando de admitir operaciones asíncronas. Dado que hacer clic en el botón de enviar cargará una página diferente, también necesito esperar esa página y usar page.waitForNavigation porque la página no estará lista hasta que se complete la navegación. Una vez que todas las promesas se hayan resuelto, podemos verificar que se haya cargado una nueva página mediante una afirmación de que el contenido de texto es equivalente a lo que esperamos. Luego, finalmente, cierro la página y el navegador. Para ver esto en acción, ejecutemos nuestras pruebas. Similar a la ejecución anterior, también se informan las métricas de performance. Pero también hay una comprobación aquí que indica que la afirmación se ha superado.

5. XK6 Browser: Mezclando APIs de Navegador y Protocolo

Short description:

XK6 Browser permite mezclar APIs a nivel de navegador y a nivel de protocolo. Puedes simular tráfico masivo con escenarios a nivel de protocolo mientras recopilas métricas de front-end. Configura el comportamiento de las pruebas utilizando opciones y ejecuta escenarios concurrentes para pruebas de navegador y protocolo. La colaboración entre los equipos de front-end y back-end se mejora con la capacidad de utilizar K6 para ambos tipos de pruebas. La combinación adecuada de pruebas de rendimiento de front-end y back-end es crucial para una mejor coordinación y experiencia del cliente. XK6 Browser es una nueva herramienta que da la bienvenida a los comentarios de la comunidad. Pruébala, explora el proyecto en GitHub y aprende de los ejemplos.

Ahora el verdadero poder de XK6 Browser brilla cuando se combina con las características existentes de K6. XK6 Browser permite mezclar APIs a nivel de navegador y a nivel de protocolo. Puedes tener un escenario en el que quieras simular la mayor parte de tu tráfico con escenarios a nivel de protocolo. Y al mismo tiempo, puedes tener uno o dos usuarios virtuales accediendo a tu sitio web a nivel de navegador para recopilar métricas de front-end como la carga de contenido del DOM o la primera pintura de contenido.

Para ver eso en código, primero necesito importar los módulos relevantes de K6 y también de XK6 Browser. A continuación, configuro el comportamiento de mi prueba utilizando opciones, que ya está integrado en K6. Aquí, puedo ejecutar dos escenarios de forma concurrente. Mi primer escenario es para mis pruebas de navegador, mientras que mi segundo escenario es para mis pruebas de protocolo. Estoy utilizando el ejecutor constante vUSE para ambos escenarios, que introducirá un número constante de usuarios virtuales para ejecutar tantas iteraciones como sea posible durante un tiempo especificado. En este ejemplo, he configurado un vUSE para mi prueba de navegador mientras que tengo 20 vUSE para mis pruebas de protocolo.

A continuación, tengo mi función de mensajes, que son mis pruebas de navegador, y también tengo mi función de noticias, que se refiere a mis pruebas de protocolo. Todo está en un solo script, lo que permite una mayor colaboración entre los equipos, porque si ya tienes equipos de back-end utilizando K6, los equipos de front-end pueden colaborar más con ellos y ser más efectivos al realizar pruebas de rendimiento. Aquí tienes una muestra de la ejecución de la prueba, y puedes ver que ambos escenarios se ejecutan de forma concurrente con varias métricas de rendimiento reportadas.

Ahora, como comencé mi charla hablando de Overcooked, también me gustaría terminar esto con Overcooked. Ahora, si queremos tener una mejor coordinación en la cocina, manejar grandes cantidades de pedidos de clientes, asegurarnos de que los clientes no esperen impacientes su comida, y también brindar la mejor experiencia al cliente, necesitamos tener la combinación adecuada de pruebas de rendimiento de front-end y back-end. Solo algunas palabras finales antes de terminar. Dado que XK6 Browser es todavía una herramienta bastante nueva, necesitamos ayuda de la comunidad, así que eres bienvenido a probarla y darnos tu opinión. Echa un vistazo a nuestro proyecto en GitHub, mira nuestros ejemplos y juega con la herramienta. Eso es todo por mi charla en TestJS Summit, espero que hayas aprendido algo nuevo hoy, y muchas gracias por escuchar.

6. K6: Herramienta de Pruebas Versátil

Short description:

K6 es conocido principalmente por las pruebas de carga, pero también puede realizar pruebas de navegador, experimentos de caos y pruebas de contrato en forma de validación de esquemas. Sin embargo, K6 no es adecuado para las pruebas unitarias, ya que es más una herramienta de caja negra. Se recomienda utilizar otras herramientas para las pruebas unitarias. Tener una herramienta versátil como K6 te permite cubrir varios casos de uso sin necesidad de herramientas separadas.

Sin embargo, quiero comenzar discutiendo la respuesta a tu pregunta de la encuesta. Antes de eso, hiciste una pregunta sobre lo que K6 es principalmente, es conocido principalmente por las pruebas de carga, pero puede hacer muchas otras cosas. La respuesta correcta es las pruebas unitarias, por lo que las pruebas unitarias son lo único que no se puede hacer. Sí. Sí, así es, y es realmente interesante ver los resultados porque aunque muchas personas votaron por la respuesta correcta, todavía hay algunas personas que quizás no estén tan conscientes de que K6 también puede realizar pruebas de navegador, que K6 también puede realizar experimentos de caos, e incluso pruebas de contrato en forma de validación de esquemas. Entonces, el principal tipo de pruebas que realmente no puede hacer es las pruebas unitarias porque K6 es más una herramienta de caja negra, mientras que no es adecuado para las pruebas unitarias porque realmente quieres profundizar en las diferentes funciones, por lo que quieres que forme parte de tu código real. Puedes hacerlo, pero realmente no recomendamos que uses K6 para eso porque obviamente hay mejores herramientas disponibles para ese tipo de pruebas. Sí, suena realmente útil poder tener una herramienta tan versátil como K6 y poder cubrir todos esos diferentes casos de uso sin tener que utilizar herramientas separadas para cada uno de esos casos de uso. Así que sí, cosas realmente interesantes.

7. Cypress y Pruebas a Nivel de Protocolo

Short description:

Soy un gran fanático de Cypress, ya que ofrece una gran experiencia para los desarrolladores con su fácil instalación y útil ejecución visual de pruebas. Cypress y K6 son similares en cuanto a casos de uso y experiencia para los desarrolladores. Las pruebas de rendimiento a nivel de navegador se centran en probar el rendimiento y las métricas del navegador, mientras que las pruebas a nivel de protocolo utilizan protocolos como HTTP para simular cargas y probar los tiempos de respuesta del servidor. Las pruebas a nivel de protocolo son populares para las pruebas de carga, ya que requieren menos recursos. La combinación de pruebas a nivel de navegador y a nivel de protocolo permite identificar mejor los errores y comprender los problemas. Simular una gran cantidad de pruebas de carga a nivel de protocolo y utilizar usuarios virtuales a nivel de navegador para obtener información sobre la experiencia del usuario proporciona una visión completa del rendimiento.

Y también quería hacerles una pregunta sobre nuestra primera pregunta de la encuesta para la audiencia sobre cuál es su marco de pruebas favorito Y sin presión, pero me gustaría saber cuál es tu respuesta allí. Sí, no voy a mentir. Mi marco favorito es realmente Cypress. Antes de unirme a K6, fui embajador de Cypress y fue el primer marco que utilicé después de mi baja por maternidad y fue realmente genial en el sentido de que fue fácil para mí comenzar, fácil de instalar y el ejecutor visual de pruebas fue realmente útil si necesitaba depurar la prueba. Creo que para mí, esa experiencia para los desarrolladores es algo realmente genial que Cypress puede ofrecer. Así que sí, soy un gran fanático de Cypress.

Sí, y sí, ya me conoces no puedo ocultarlo. Obviamente, soy un gran fanático de Cypress y hablando de los diferentes casos de uso y la experiencia para los desarrolladores, ¿verdad? Poder aprovechar estas herramientas para tantos tipos diferentes de cosas. Cypress y K6 son similares en ese sentido.

Así que tenemos algunas preguntas de la audiencia. Nos aseguraremos de responderlas para ustedes. La primera es sobre ¿cómo es diferente la prueba de rendimiento a nivel de navegador de la prueba a nivel de protocolo? Sí, creo que si vuelvo a una de las diapositivas que tengo he diferenciado las pruebas de rendimiento como pruebas de rendimiento en el front-end o en el back-end. Entonces, cuando hablamos de nivel de navegador, se trata realmente de probar el front-end y verificar si, por ejemplo, nuestro sitio web es lo suficientemente rápido desde el punto de vista de un solo usuario. También tiene métricas distintas, así que se trata de las métricas de rendimiento del navegador. Por ejemplo, una métrica podría ser cuánto tiempo tardó el navegador en renderizar una página completa, o cuánto tiempo tardó en ser completamente interactiva. Mientras que a nivel de protocolo, ese es el caso más comúnmente utilizado, digamos para las pruebas de carga de una API. Entonces, con el nivel de protocolo, en lugar de usar un navegador real, utilizamos protocolos como HTTP para simular una serie de cargas. Estamos interesados en probar los tiempos de respuesta de nuestro servidor y asegurarnos de que cuando se envíen múltiples solicitudes desde diferentes usuarios simultáneamente, nuestros servidores backend y nuestras bases de datos puedan manejar esa carga. Cuando se trata de las pruebas de carga, obviamente el nivel de protocolo es una opción muy popular porque requiere menos recursos porque si pensamos en las pruebas de carga a nivel de navegador, aunque ahora con XK6 Browser tenemos la capacidad de crear usuarios virtuales similares a un navegador. Aún así, debemos tener en cuenta que con las pruebas de carga a nivel de navegador puede requerir muchos recursos porque no queremos crear, por ejemplo, 1000 navegadores solo para simular una prueba de carga porque eso podría hacer que los servidores que estamos utilizando se bloqueen. Por lo tanto, debemos encontrar un equilibrio entre las pruebas a nivel de navegador y las pruebas a nivel de protocolo también. Correcto, y eso es algo que vemos mucho en las pruebas, que no pueden ser tan realistas como en producción, ¿verdad? Y parece que cuando tienes diferentes métricas para el navegador y el protocolo, y las pruebas de ambos, también puedes identificar mejor los errores o comprender dónde pueden surgir problemas porque ya los has sometido a pruebas, por así decirlo, en un entorno de prueba. Y si algo sale mal en producción, puedes volver atrás y evaluarlo con ese contexto ya establecido. ¿Has visto que eso también es beneficioso? Definitivamente. Entonces, uno de los casos de uso que mencioné durante la charla es el poder, por ejemplo, y ahora puedes simular, por ejemplo, comunicarse con el navegador xk6 puedes ejecutar una gran cantidad de pruebas de carga a nivel de protocolo. Entonces, digamos que quieres crear como mil solicitudes a nivel de protocolo. Pero al mismo tiempo, eso no te daría una idea de tu experiencia de usuario. Entonces, digamos que quieres verificar si algún spinner de carga está tardando mucho tiempo. Entonces, lo que puedes hacer es mientras tienes como mil pruebas de carga a nivel de protocolo, puedes tener un par de usuarios virtuales a nivel de navegador solo para verificar la experiencia de usuario en general. Así que ahora puedes tener, supongo, la imagen completa cuando se trata del rendimiento. Porque en lugar de tener un enfoque aislado, puedes verificar qué está sucediendo en mi front-end si mi backend está expuesto a esta cantidad de solicitudes en un alto número.

QnA

Diagnóstico de CI y Pruebas de Kafka

Short description:

Existe una sobrecarga involucrada en el diagnóstico de fallas de CI en las pruebas de extremo a extremo. K6 backend proporciona acceso al informe de CI para ver las fallas en las verificaciones y umbrales. El equipo planea introducir información de rendimiento en la nube de K6 para identificar cuellos de botella. La configuración de umbrales en K6 permite recibir alertas cuando ciertas métricas aumentan. Existe una extensión disponible en el ecosistema de XK6 para enviar notificaciones. Los productores y consumidores de Kafka pueden ser probados con la extensión de K6.

Sí, eso suena similar a la siguiente pregunta de la audiencia. Puede que hayas mencionado esto un poco, pero dice que hay una sobrecarga involucrada en el diagnóstico de fallas de CI, por ejemplo, en una única prueba de extremo a extremo. Con el backend de K6, tienes acceso al informe de CI y puedes ver las fallas en las verificaciones y umbrales. Pero sabiendo que es posible que no tengas una herramienta de diagnóstico de CI como Replay o el panel de Cypress, ¿cómo puedes facilitar o hacer más fácil el aspecto de diagnóstico de CI con las extensiones de navegador de K6?

Esa es una pregunta realmente buena. Y no estoy al 100% cerca de eso todavía porque XK6 Browser todavía está en una etapa beta muy temprana. Pero una de las cosas que sé que el equipo quiere lograr en el futuro es que dentro de K6 Cloud tenemos una función llamada Información de rendimiento. Por lo tanto, puede brindarte información sobre qué área realmente tiene un alto número de cuellos de botella. Entonces, si estás utilizando, por ejemplo, si tu CPU ha experimentado un número muy alto de utilización, entonces esa información de rendimiento podrá decirte que tal vez puedas intentar agregar algún tiempo de espera, agregar algunas pausas en tu prueba. Porque nuevamente, queremos simular lo que está sucediendo en producción lo más cerca posible. Todavía estamos realizando muchas pruebas beta en nuestro K6 Cloud. Aún no está abierto al público en general, pero eso es algo que tendríamos. Por lo tanto, puede brindarte algún diagnóstico sobre qué áreas tienen problemas reales de cuellos de botella de rendimiento. Actualmente ya tenemos eso con las cosas existentes de K6. Con la información de rendimiento, te brinda información sobre qué servidores, por ejemplo, se han degradado debido al alto número de carga que ejecutas. Entonces queremos usar, o queremos tener la misma función para XK6 Browser también. Pero por ahora aún no está completamente disponible para el público.

Bueno, suena muy interesante poder obtener ese tipo de información desde un entorno de CI, ya sabes, cuando todos luchamos por entender qué está sucediendo en esos espacios. Otra pregunta que tenemos de la audiencia es una pregunta sobre la salida resultante. ¿Hay alguna forma de configurar alertas cuando ciertas métricas aumentan?

Sí, puedes usar umbrales para eso. Entonces, lo que puedes hacer es, digamos, uno de tus SLA es, ya sabes, un tiempo de respuesta específico debe ser inferior, digamos, a 500 milisegundos para el percentil 95. Entonces, en K6, tenemos un concepto de umbral donde es un criterio de aprobación o falla. Entonces, si el umbral falla, tu prueba se informará como fallida. Y luego, en términos de notificaciones, creo que hay una extensión que uno de nuestros colaboradores de K6 ha escrito, tengo que volver con el nombre real, pero porque he visto que hay una lista de extensiones en nuestro ecosistema de XK6, que puedes usar para enviar notificaciones a, supongo, cualquier plataforma que desees, pero sí, la forma de hacerlo con K6 es configurar un umbral. Y luego, después de que la prueba haya terminado de ejecutarse, ese umbral específico dirá si cumple o no con los criterios. Sí.

De acuerdo. Y eso probablemente también ayuda a establecer tus métricas, porque asignas esos umbrales de antemano y todos están en la misma página sobre lo que se considera un rendimiento aceptable. Así que siempre es una buena discusión para tener. Otra pregunta aquí es, ¿puedes probar los productores y consumidores de Kafka con K6? Creo que sí, tenemos una extensión de K6 si deseas realizar pruebas de carga en productores y consumidores de Kafka.

Pruebas de carga de Kafka y XK6 Browser

Short description:

Tendría que remitirte a uno de mis colegas porque mi principal área de experiencia está relacionada con la automatización del navegador, pero sí, también podemos realizar pruebas de carga en Kafka. Tenemos una pregunta muy importante aquí, que es, ¿qué personaje eliges en Overcooked? Oh, no conozco ninguno de los nombres. Simplemente dejo que mi hija elija al azar, pero normalmente son los animales lindos. Así que quería relacionarlo con mi charla sobre pruebas de carga porque una vez que los pedidos comienzan a acumularse, resulta en una mala experiencia de usuario. La principal motivación para introducir el navegador XK6 es proporcionar una imagen completa del rendimiento de tu aplicación y centrarse en resaltar más el rendimiento del front-end. El navegador XK6 complementa otras herramientas de prueba como Playwright y Cypress al proporcionar un enfoque híbrido para las pruebas de rendimiento.

Tendría que remitirte a uno de mis colegas porque mi principal área de experiencia está relacionada con, ya sabes, la automatización del navegador, pero sí, también podemos realizar pruebas de carga en Kafka. Vale, sí, hay una pregunta de seguimiento sobre si se pueden disparar eventos personalizados directamente y probar cómo reacciona el sistema con los productores y consumidores de Kafka, pero tal vez esa sea una mejor pregunta para más adelante. Así que si esta persona me envía un mensaje puedo darte, o puedo indicarte a la persona adecuada del equipo de K6 que estará más capacitada para responder.

Sí, absolutamente. Tenemos una pregunta muy importante aquí, que es, ¿qué personaje eliges en Overcooked? ¿Qué personaje elijo? Sí. ¿Hago o? Sí, ¿qué personaje te gusta jugar en Overcooked? Oh, no conozco ninguno de los nombres. Simplemente dejo que mi hija elija al azar pero normalmente son los animales lindos. Ella no le gusta un personaje que parece un chef enojado. Así que tendemos a evitar usar ese personaje. Pero sí, es un juego muy interesante porque se supone que es un juego cooperativo, pero ya sabes, jugar con una niña de cinco años, es muy estresante, y por eso quería relacionarlo con mi charla sobre pruebas de carga porque una vez que los pedidos comienzan a acumularse, podemos relacionarlo, ya sabes, si no has probado tus servidores correctamente, simplemente obtienes muchas colas, muchas solicitudes que, ya sabes, no se han procesado. Y en última instancia, eso resulta en una mala experiencia de usuario.

Absolutamente. También he jugado a Overcooked, y requiere mucha comunicación, ¿verdad? Entre, si piensas en el front-end y el backend, requiere mucha comunicación entre tú y la otra persona para poder manejarlo realmente. Así que pensé que era muy divertido, pero genial. Así que tampoco tengo un personaje principal. Simplemente elijo diferentes. Así que volviendo a otra pregunta sobre K6, ¿cuál fue la principal motivación para introducir el navegador XK6? Sí, creo que solo para dar a todos un poco de contexto, tenemos esta regla de oro del rendimiento web. También hablé de ello durante mi charla. Y básicamente dice que el 80% de los problemas de cuello de botella ocurren en el front-end. K6 se mantuvo alejado al principio, de los navegadores reales, porque querían asegurarse de que las pruebas de rendimiento del backend fueran muy estables. Y creo que ahora que K6 definitivamente ha alcanzado su madurez máxima, ahora es muy estable. Ahora tenemos mucho apoyo de la comunidad. Ahora queremos cambiar nuestro enfoque hacia las pruebas de rendimiento del front-end, porque sabemos que para tener ese enfoque híbrido en las pruebas de rendimiento, no podemos hacer solo nivel de post-school, tenemos que hacer ambos. Así que la principal motivación realmente es asegurarnos de proporcionar a nuestros usuarios una forma de tener una imagen completa del rendimiento de su aplicación. Y supongo que ya puedes hacer eso conectando diferentes herramientas, usando diferentes herramientas, pero queremos ver si podemos intentar tener una sola herramienta que pueda hacer eso, que podamos usar el mismo script, y que podamos aprovechar las características existentes de K6 que nuestros usuarios ya están utilizando. Y ahora, solo queremos centrarnos en resaltar más el rendimiento del front-end también.

Eso es genial, sí, y gracias por proporcionar ese contexto. Entonces, en cuanto a otras herramientas, o herramientas de pruebas como Playwright y Cypress, ¿cómo el navegador XK6 compite, complementa o trabaja junto a ese tipo de herramientas? Sí, esto es realmente interesante para mí, porque incluso cuando comencé con K6, teníamos esta cosa llamada Semana de las Pruebas del Navegador. Entonces, una de las cosas de las que he hablado es que no queremos competir con Playwright, no queremos competir con Cypress, porque el mensaje que queremos transmitir es que queremos proporcionar un enfoque híbrido para las pruebas de rendimiento. Sí, puedes hacer pruebas de rendimiento con Playwright.

Enfoque híbrido para las pruebas de rendimiento

Short description:

Sí, puedes realizar pruebas de rendimiento específicamente en el front-end con Cypress. Pero, ¿qué pasa si también deseas tener la misma herramienta para el back-end? Entonces necesitarías utilizar otras herramientas. El enfoque que estamos tratando de comunicar aquí es que si deseas tener una sola herramienta para un enfoque híbrido en las pruebas de rendimiento, entonces XK6 Browser con K6 puede ayudarte con eso. No estamos buscando competir, estamos resolviendo un problema diferente al que nuestros usuarios se enfrentan.

Sí, puedes realizar pruebas de rendimiento específicamente en el front-end con Cypress. Pero, ¿qué pasa si también deseas tener la misma herramienta para el back-end? Entonces necesitarías utilizar otras herramientas. El enfoque que estamos tratando de comunicar aquí es que si deseas tener una sola herramienta para un enfoque híbrido en las pruebas de rendimiento, entonces XK6 Browser con K6 puede ayudarte con eso. No estamos buscando competir, estamos resolviendo un problema diferente, supongo, al que nuestros usuarios se enfrentan. Y supongo que mientras más herramientas podamos proporcionar a nuestros usuarios que puedan resolver el problema, supongo que mejor será.

Closing Remarks and Q&A

Short description:

Dependiendo del caso de uso y del producto que se esté probando, la respuesta a si se necesita realizar pruebas de rendimiento variará. Si tienes alguna pregunta adicional, no dudes en hacerla en la sección de preguntas y respuestas de Discord. Gracias por ver este episodio de XK6 Browser y por tu interés en las pruebas de rendimiento para el front-end y el back-end. ¡Nos vemos la próxima semana!

Correcto, supongo que la respuesta siempre es depende, ¿verdad? Sí. Dependiendo del caso de uso, del producto que estás testing, y todo eso.

Así que adelante, asistentes, si tienen alguna pregunta adicional, pueden seguir haciéndola en Discord en la sección de preguntas y respuestas de producción. Pero vamos a terminar aquí, Marie. Muchas gracias por responder todas estas preguntas y por tu charla realmente genial e interesante. Sé que definitivamente estoy interesado en conocer más sobre XK6 Browser y las pruebas de performance testing para el front-end y el back-end.

Así que muchas gracias, Marie. Nuevamente, pueden seguir haciendo preguntas a Marie en la sección de preguntas y respuestas de producción en Discord. Muchas gracias. Sí. Vamos a hacerlo. Estamos bien. Sí. Estamos bien. Eso es genial. Muchas gracias por ver este episodio de XK6 Browser. Nos vemos la próxima semana. Nos vemos pronto. Cuídate. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop