Para alcanzar el buen nivel de rendimiento de un sistema, es vital que las pruebas se realicen al inicio del ciclo de desarrollo del software. Descubre en este post cuáles son los tipos de pruebas de performance y cómo diseñar adecuadamente una estrategia de performance testing antes de decidir cómo simular la carga.

Las pruebas de performance revelan cómo se comporta y responde un sistema ante diversas situaciones. Un sistema puede funcionar bien con solo 1.000 usuarios virtuales simultáneos pero, ¿cómo funcionaría con 100.000? En términos de performance, se busca lograr velocidad, escalabilidad y estabilidad del sistema.

El plan de pruebas de performance detalla lo que se debe ejecutar en el tiempo que hemos asignado para la prueba. De tal forma que se puedan responder las preguntas sobre el rendimiento del sistema, después de haber ejecutado la menor cantidad de ejecuciones posibles.

En este post te explicamos cuáles son los tipos de pruebas de performance, y cómo diseñar un plan de performance testing antes de decidir cómo simular la carga.

¿Qué son las Pruebas de Rendimiento?

Las pruebas de performance simulan la carga esperada del sistema en un entorno similar al de producción, pudiendo detectar “cuellos de botella” y oportunidades de mejora.

Recordemos que en la medida en que se detectan problemas asociados al rendimiento lo antes posible, se logra un ahorro importante en el tiempo, los costos y otros problemas asociados.

¿Te interesa mejorar la performance de tu sitio web, sistema o aplicación, pero no sabes por donde empezar a diseñar el plan de pruebas? Llegaste al lugar correcto, ¡continúa leyendo!

¿Cómo definir un Plan de Pruebas de Performance?

En primer lugar, al hablar de un plan de pruebas de performance, no nos referimos propiamente al documento, sino a lo que se va a ejecutar en el tiempo que se tiene asignado para los tests.

De esta forma, se propone que con la menor cantidad de ejecuciones posibles, seamos capaces de responder los interrogantes de performance por los cuales nos indicaron hacer la prueba. Primero, es necesario saber qué preguntas vamos a contestar con los resultados de acuerdo a cada tipo de prueba.

¿Cuáles son los tipos de Pruebas de Performance?

Existen varios tipos de pruebas de performance, cada una simula un diferente y posible escenario de usuario, siendo las más comunes:

1. Pruebas de Estrés

Las pruebas de estrés permiten descubrir cuál es el máximo número de usuarios simultáneos que soporta un sistema o app con una experiencia de usuario aceptable, es decir, cuál es su punto de quiebre o ruptura.

2. Pruebas de Carga

Dado el escenario actual de carga del sistema, las pruebas de carga permiten ver cómo se comportará la aplicación, y qué oportunidades de mejora existen para ese escenario esperado.

3. Pruebas de Resistencia

También llamadas pruebas de remojo, confiabilidad o duración, las pruebas de resistencia evidencian cómo funcionará el sistema luego de estar cierto tiempo ejecutándose, por ejemplo durante 24 horas.

Vale la pena destacar que en algunos casos esto implica tomar acciones como la de reiniciar el servidor cada noche, hasta encontrar una solución definitiva a algún leak presente en el sistema.

4. Peak Testing

Si un sistema funciona adecuadamente en estado normal y hay un peak de estrés (la casuística hace que en un mismo momento coincidan muchas más peticiones que lo normal, ante lo cual los tiempos de respuesta quizá empeoran por debajo de lo aceptable, el peak testing deja entrever qué tan rápido se recupera el sistema.

Otras consideraciones

En cualquier caso, hay otra pregunta que está siempre presente en toda prueba de performance: ¿cuáles son los cuellos de botella principales, y cómo solucionar los limitantes que aparecen en el camino?

Incluso podríamos responder cosas como por ejemplo: ¿mi equipo está preparado para cuando algo así pase en producción o necesito aprender algo más? ¿Qué disponibilidad de recursos físicos hay disponibles o cuán difícil es conseguirlos? ¿Qué tan rápido damos soluciones a problemas asociados al rendimiento?

Con estos interrogantes ya tenemos mucho para trabajar. Muchas veces es necesario revisar los access log del sistema para tener una idea de la cantidad de usuarios que se conectan a diario. O bien, tenemos que hacer estimaciones de cuántos usuarios se esperan recibir.

Al momento de diseñar el plan de pruebas de performance, todo lo anterior se refina mucho más, ya que es necesario indagar qué hacen cada uno de esos usuarios (qué casos de prueba, con qué datos, etc.)

Ahora bien, en lo que me quiero centrar en este post es cómo ejecutar ese escenario de carga.

¿Con cuántos usuarios concurrentes se ejecutan las Pruebas de Performance?

Algo que ya he repetido tantas veces y que ahora ya debe ser verdad: si diseñamos/definimos nuestro escenario de carga con una cantidad X de usuarios, no podemos comenzar ejecutando una prueba que simule los X usuarios concurrentes en un primer momento.

Si hacemos eso, por experiencia, es posible que aparezcan tantos problemas a la vez que no sabremos por dónde comenzar. De ahí es que surge la idea de aplicar una metodología iterativa incremental para el plan de pruebas de performance.

Iterativa porque se van ejecutando distintas iteraciones de prueba, de manera incremental. Comenzando con una cantidad reducida de usuarios concurrentes, solucionando los problemas que se vayan identificando, e ir avanzando mientras se aumenta la concurrencia.

Ejemplos de Casos de Pruebas de Performance

1. Ejemplo de una Prueba de Carga

Consideremos como primer ejemplo que estamos haciendo una prueba de carga, donde el objetivo es analizar si el sistema soporta 1.000 usuarios concurrentes (aclaración: no estoy teniendo en cuenta el tema de entorno de prueba, y qué tan similar es al de producción, y cómo definir el alcance en base a la diferencia de los ambientes).

Primera Prueba

Un usuario no concurrente (esto puede servir como baseline, para comparar luego, puede ser con 1, 5, 10 o más, pero tiene que ser algo sumamente reducido para lo esperado en el sistema).

Segunda Prueba

200 usuarios concurrentes (es decir, el 20% de la carga esperada). Desde este momento ya se puede obtener muchísima información sobre qué tan difícil va a ser completar la prueba, tanto en tiempo como en forma.

Al ejecutar estas primeras pruebas vamos a resolver los problemas más “gruesos”: las configuraciones por defecto (pools de conexión o tamaño del heap de Java por ejemplo). También vamos a tener una idea de cómo escala el sistema, comparando los tiempos de respuesta con respecto al baseline.

Una vez que se termina el análisis y resolución de problemas, se vuelve a ejecutar esta prueba hasta que se obtengan tiempos aceptables.

Según qué tan ajustados sean esos resultados vamos a decidir si la tercera prueba será la del 40% (para seguir con incrementos de a 20) o si vamos con 50% de la carga (pensando en pasar luego al 75 y al 100), o si el sistema responde muy bien, quizá nos animemos a pasar directamente a más.

En cualquier caso, lo que queremos tener al final es una gráfica que nos muestre los tiempos de respuesta obtenidos con cada prueba (con cada porcentaje de la carga esperada), y así podremos ver cómo fue evolucionando el sistema gracias a nuestro trabajo.

En la anterior gráfica, vemos cómo se ejecutaron distintas pruebas incrementando de a 20% la carga. Además, se puede observar que se repitieron las pruebas hasta alcanzar el acuerdo de nivel de servicio esperado (SLA o Service Level Agreement) en cada caso, y recién al alcanzarlo, se pasa al siguiente escalón.

2. Ejemplo de una Prueba de Estrés

Como segundo ejemplo, imaginemos que queremos encontrar el punto de quiebre del sistema con una prueba de estrés.

Para eso queremos ejecutar distintas pruebas, con distintas cantidades de usuarios, analizando si al aumentar la concurrencia sigue aumentando el throughput (si al aumentar la concurrencia no aumenta las transacciones por segundo, eso indica que llegamos al punto de quiebre, ya que se está saturando el sistema en algún punto, sin escalar).

Si comenzamos a ejecutar pruebas con números de usuarios al azar, va a ser muy arriesgado y perderemos mucho tiempo. Por lo que la mejor estrategia es ejecutar una prueba exploratoria de performance. Esto con el fin de tener una primera idea de dónde está ese punto de quiebre.

Para ello, ejecutamos una prueba incremental de 0 a X, donde X es una cantidad de usuarios grande (digamos que 1.000 para considerar una generadora de carga sola) y que creemos que el quiebre tiene que estar en ese rango.

Lo que se puede hacer en cualquier herramienta de simulación de carga para ejecutar esta prueba es establecer un ramp-up (aumento de la velocidad de la prueba de carga) uniforme durante el tiempo de la prueba.

En otras palabras, si queremos que esa prueba dure una hora, hacemos una configuración para que la prueba comience con cero usuarios concurrentes, y al cabo de una hora tener 1.000. De esta manera, vamos a poder tener una primera aproximación hacia cuando el throughput del sistema se degrada. Si observamos que es alrededor de los 650 usuarios, ahí podemos comenzar a refinar ejecutando pruebas puntuales.

Por ejemplo, podríamos ejecutar una prueba con 500, otra con 600, otra con 700. Si efectivamente la prueba de 700 usuarios tiene menos throughput (tasa de transferencia efectiva) que la de 600, hay que refinar y ejecutar una con 650, y así seguimos con el punto medio, hasta mejorar la precisión.

3. Ejemplo de una Prueba de Resistencia

Para una prueba de resistencia, es aconsejable ejecutar una carga constante que esté entre el 50 y el 70% de la carga soportada por el sistema en condiciones aceptables. Si bien podría servir una carga menor, todo dependerá de qué tan complejo sea preparar los datos de prueba para poder ejecutar durante muchas horas.

Por lo general las pruebas de resistencia se ejecutan una vez terminadas las pruebas de estrés de carga que se hayan realizado, para intentar identificar otros tipos de problemas (memory leaks, conexiones colgadas, etc.)

Si se cuenta con tiempo y datos suficientes, se podrían incrementar las cargas que se utilicen para las pruebas ejecutándolas en forma prolongada.

4. Ejemplo de Peak Testing o Prueba de Picos

Como mencionamos antes, la idea es ver qué pasa cuando hay un peak y qué tanto le cuesta al sistema recuperarse. En este contexto, pueden surgir varios interrogantes, tales como: ¿Si hay un peak entonces el sistema me queda colgado? ¿A los 10 segundos se recupera, o a las dos horas?

Para esto, es necesario conocer de partida cuál es el punto de quiebre del sistema y así poder preparar una prueba que esté por debajo de ese umbral. De este modo generar un peak subiendo la carga por ejemplo por un minuto, y luego bajarla.

El enfoque incremental que se puede aplicar aquí es en el peak en sí. Se podría comenzar experimentando con peaks pequeños (de corta duración o poca carga), y luego estudiar cómo reacciona el sistema ante peaks mayores.

En cualquier caso, esto es algo que se debe diseñar en base a un estudio de comportamientos de los usuarios, especialmente en base a los access logs que se tengan a disposición.

¿Cómo ejecutar las Pruebas de Performance?

La forma de ejecutar pruebas de performance varía según el tipo de prueba. Es decir, depende de la pregunta a la que queremos encontrar respuesta.

En términos generales el enfoque de las pruebas de rendimiento persigue un mismo objetivo: reducir la cantidad de pruebas que ejecutamos, optimizando la relación costo-beneficio del testing.

Para esto, lo ideal es seguir un enfoque iterativo incremental (para pruebas de carga, de resistencia y peak testing). Así como un enfoque iterativo de refinamiento, específicamente para las pruebas de estrés.

Por último, tener en cuenta también que estos tests se deben repetir con liberaciones de nuevas versiones para evitar que se introduzcan bugs o cambios que degraden significativamente el rendimiento. En otras palabras, así como se ejecutan tests de regresión, también considerar performance dentro de esas regresiones.

Si tu sitio web funciona con lentitud o tu sistema no opera como tus usuarios esperan, estás perdiendo dinero. Utilizando las herramientas adecuadas y las mejores prácticas de testing, nuestros ingenieros de performance ayudan a evitar tiempos de inactividad en el sistema y mejoran su confiabilidad.

---

¿Buscas un partner para diseñar y ejecutar la estrategia de pruebas de performance? Abstracta es la empresa más confiable de Latam en ingeniería de calidad de software.

Conoce nuestro servicio de performance testing, contáctanos y conversemos sobre cómo podemos ayudarte a mejorar de manera general el rendimiento de tu sistema, e-commerce o app, a través de una evaluación de madurez de las pruebas, reportes, monitoreo del rendimiento y servicios DevOps.

---

Otros contenidos relacionados

¿Por qué son necesarias las Pruebas de Performance?

¿Cuándo es el mejor momento para comenzar con las Pruebas de Performance?

Prepara tu sitio para eventos masivos de compras online

---