Un Popurrí de Pruebas de Rendimiento Frontend y Backend

♪♪♪ ¡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.

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.

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.

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.

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.

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.

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.

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.

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.

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á.

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.