En este artículo, exploramos cómo diseñar un plan de pruebas de performance para elevar la estabilidad y escalabilidad del software. Conocerás en detalle los tipos de pruebas, qué se evalúa en cada una, y las herramientas clave. Además, entenderás los pasos para crear un plan efectivo y cómo abordar desafíos críticos, lo cual permite mejorar la eficiencia y seguridad de tu infraestructura digital.

Las pruebas de rendimiento revelan cómo se comporta y responde un sistema ante diversas situaciones. Un sistema puede funcionar bien con 1.000 usuarios virtuales simultáneos, pero ¿cómo lo haría con 100.000? Nuestro objetivo es lograr velocidad, escalabilidad y estabilidad.

El plan de pruebas detalla lo que debemos ejecutar en el tiempo asignado. Así, respondemos preguntas sobre el rendimiento del sistema con la menor cantidad de ejecuciones posibles. Estos planes son esenciales para evaluar la capacidad y seguridad de la infraestructura, lo cual permite que el sistema maneje la demanda esperada.

En este post, te explicamos los tipos de pruebas de rendimiento y cómo diseñar un plan antes de simular la carga. Abordamos diferentes escenarios y tareas, y consideramos factores críticos para el uso eficiente de las soluciones de software.

¿Qué son las pruebas de performance?

Las pruebas de rendimiento simulan la carga esperada del sistema en un entorno similar al de producción, permitiendo detectar cuellos de botella y oportunidades de mejora. Detectar problemas de rendimiento lo antes posible ahorra tiempo, costos y otros factores críticos.

Como mencionamos en este artículo, las pruebas de performance son una parte fundamental del proceso de testing de software. El colapso de los sistemas de software por la alta demanda impacta negativamente la experiencia de los usuarios y su calidad de vida digital, lo cual genera significativas pérdidas a las empresas.

Al diseñar un plan de pruebas, es crucial considerar varios aspectos. La base de un buen plan incluye la identificación de cuellos de botella y la evaluación de la capacidad del sistema para manejar la demanda. Además, la integración de IA puede mejorar la precisión y eficiencia de las pruebas.

¿Cómo diseñar un plan de pruebas de performance?

En primer lugar, al hablar de un plan de pruebas, no nos referimos solo al documento, sino a las acciones que realizaremos en el tiempo asignado para los tests. Proponemos que, con la menor cantidad de ejecuciones posibles, seamos capaces de responder los interrogantes de rendimiento por los cuales nos indicaron hacer la prueba.

El plan de pruebas es fundamental para asegurar que todas las etapas del testing se realicen de manera ordenada y eficiente. Un buen plan no solo detalla los casos de prueba, sino que también establece los objetivos y expectativas del proyecto.

Este documento es clave para la gestión y seguimiento del proceso de testing de software. Además, proporciona respuestas claras y precisas sobre el rendimiento del sistema, cruciales para la optimización de cualquier página o programa.

Para diseñar un plan efectivo, primero es importante entender cuáles son los diferentes tipos de pruebas de rendimiento.

¿Cuáles son los tipos de pruebas de performance?

Existen varios tipos de pruebas que se deben considerar al diseñar un plan. Entre ellas se encuentran las de carga, estrés, resistencia y picos. Cada prueba tiene un objetivo específico que en conjunto ayudan a identificar y solucionar problemas de manera precisa:

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 una aplicación con una experiencia de usuario aceptable, es decir, cuál es su punto de quiebre o ruptura.

2. Pruebas de carga

Las pruebas de carga permiten ver cómo se comportará la aplicación bajo la carga esperada y qué mejoras son necesarias para ese escenario.

3. Pruebas de resistencia

También llamadas pruebas de remojo, confiabilidad o duración, evidencian cómo funcionará el sistema tras un uso prolongado, por ejemplo, durante 24 horas. En algunos casos, es necesario reiniciar el servidor cada noche hasta encontrar una solución definitiva a cualquier leak presente en el software.

4. Pruebas de picos

Si un sistema funciona bien en condiciones normales, el peak testing muestra qué tan rápido se recupera tras un pico de estrés con muchas más peticiones de lo habitual.

¿Cómo evaluar la performance de un producto de software?

En toda evaluación de rendimiento, primero, es necesario saber qué preguntas vamos a contestar con los resultados de acuerdo a cada tipo de prueba. El objetivo es optimizar la relación costo-beneficio del proceso de testing y calidad de software, así como minimizar la cantidad de pruebas.

Para guiar este proceso, podríamos responder preguntas como:

• ¿Cuáles son los cuellos de botella y cómo solucionarlos?
• ¿Cuántos usuarios simultáneos puede manejar el sistema sin degradar el rendimiento?
• ¿Cómo se comporta bajo condiciones de estrés prolongado?
• ¿Qué tan rápido se recupera después de un pico de carga?
• ¿Está nuestro equipo preparado para manejar problemas en producción?
• ¿Qué disponibilidad de recursos físicos tenemos y qué tan difícil es conseguirlos?
• ¿Qué tan rápido resolvemos problemas de rendimiento?

Para abordar estos interrogantes, es útil revisar los access logs del software para conocer la cantidad de personas que se conectan a diario o hacer estimaciones de cuántas se esperan recibir. Al diseñar el plan de pruebas, detallamos qué hacen los usuarios, los casos de prueba y los datos utilizados.

Para llevar a cabo las pruebas de rendimiento de manera efectiva, es importante saber cómo ejecutar el escenario de carga. En este artículo, nos centramos en cómo determinar la cantidad adecuada de usuarios a través de ejemplos prácticos.

¿Con cuántos usuarios concurrentes ejecutar las pruebas?

Si diseñamos nuestro escenario de carga con una cantidad X de usuarios, no podemos comenzar con una prueba que simule los X usuarios concurrentes desde el inicio. Hacerlo podría generar tantos problemas a la vez que no sabríamos por dónde empezar. Por eso, aplicamos una metodología iterativa incremental para el plan de pruebas de rendimiento.

Comenzamos con una cantidad reducida de personas concurrentes, resolvemos los problemas que se identifiquen y avanzamos mientras aumentamos la concurrencia.

Ejemplos de casos de pruebas de performance

1. Ejemplo de una prueba de carga

Consideremos una prueba de carga para analizar si la aplicación soporta 1.000 personas concurrentes, sin considerar el entorno de prueba ni su similitud con el de producción.

Primera prueba

Un usuario no concurrente sirve como baseline para comparar luego. Puede ser con 1, 5, 10 o más, pero debe ser algo reducido para lo esperado en la aplicación.

Segunda prueba

200 personas concurrentes, es decir, el 20% de la carga esperada. Desde este momento, obtenemos mucha información sobre la dificultad de completar la prueba, tanto en tiempo como en forma.

Al ejecutar estas primeras pruebas, resolvemos los problemas más importantes, como configuraciones por defecto en pools de conexión o tamaño del heap de Java. También obtenemos una idea de cómo escala la aplicación al comparar los tiempos de respuesta con el baseline.

Una vez que terminamos el análisis y resolución de problemas, volvemos a ejecutar esta prueba hasta obtener tiempos aceptables. Según qué tan ajustados sean esos resultados, decidimos si la tercera prueba será del 40% de la carga para seguir con incrementos de 20, o del 50% de la cargapara luego pasar al 75 y al 100. Si la aplicación responde muy bien, podemos pasar directamente a más.

Nuestro objetivo final es tener una gráfica que muestre los tiempos de respuesta obtenidos con cada prueba, con cada porcentaje de la carga esperada, y así podremos ver cómo evolucionó la aplicación.

En la gráfica, vemos cómo se ejecutaron distintas pruebas incrementando la carga en un 20% cada vez. Además, observamos que las pruebas se repitieron hasta alcanzar el acuerdo de nivel de servicio esperado (SLA) en cada caso, y solo entonces se avanzó al siguiente escalón.

2. Ejemplo de una prueba de estrés

Imaginemos que queremos encontrar el punto de quiebre del sitio web con una prueba de estrés. Para eso, ejecutamos distintas pruebas con diferentes cantidades de usuarios para analizar si al aumentar la concurrencia sigue aumentando el throughput. Si no aumentan las transacciones por segundo, hemos llegado al punto de quiebre, ya que el sitio web se está saturando en algún punto sin escalar.

Si comenzamos con números de usuarios al azar, será muy arriesgado y perderemos mucho tiempo. La mejor estrategia es realizar testing exploratorio para tener una primera idea de dónde está ese punto de quiebre.

Configuración y ejecución de una prueba

Ejecutamos una prueba incremental de 0 a 1.000 personas y aumentamos la carga de manera uniforme durante una hora. Utilizamos una herramienta de simulación de carga para establecer un ramp-up, con el fin de incrementar gradualmente la velocidad de la prueba durante un tiempo determinado.

Esto nos da una primera aproximación de cuándo el throughput del sitio web se degrada. Si observamos que ocurre alrededor de 650 personas, ajustamos las pruebas con 500, 600 y 700 personas. Si la prueba de 700 personas tiene menos throughput que la de 600, ajustamos con 650 y continuamos hasta mejorar la precisión.

3. Ejemplo de una prueba de resistencia

Para una prueba de resistencia, aplicamos una carga constante entre el 50 y el 70% de la capacidad soportada por la aplicación en condiciones aceptables. Aunque podría servir una carga menor, depende de la complejidad de preparar los datos de prueba para realizar la evaluación durante muchas horas.

Generalmente, las pruebas de resistencia se realizan después de las pruebas de demanda para identificar otros problemas como memory leaks y conexiones colgadas. Si contamos con tiempo y datos suficientes, podemos aumentar las cargas y extender la duración de las pruebas.

4. Ejemplo de Peak Testing o prueba de picos

El objetivo es observar qué sucede durante un peak y cuánto tiempo le toma a la aplicación recuperarse. Pueden surgir preguntas como: ¿La aplicación queda colgada? ¿Se recupera en 10 segundos o en dos horas?

Es necesario conocer el punto de quiebre de la aplicación para preparar una prueba que esté por debajo de ese umbral. Generamos un peak aumentando la carga por un minuto y luego reduciéndola.

Aplicamos un enfoque incremental en el peak. Comenzamos con peaks pequeños y luego estudiamos cómo reacciona la aplicación ante peaks mayores. Es importante diseñar estas pruebas basándonos en un estudio de comportamientos de los usuarios, especialmente en los access logs disponibles.

¿Te interesa mejorar la performance de tu página web o producto digital, pero no sabes por dónde empezar? En esta guía te explicamos cómo hacerlo.

Otras consideraciones para la ejecución de una estrategia de performance

En Abstracta, recomendamos un enfoque iterativo incremental para realizar las pruebas de carga, resistencia y picos, y un enfoque iterativo de ajuste para las pruebas de estrés.

Es clave repetir estas pruebas en cada entrega de nuevas versiones para evitar la introducción de errores o cambios que degraden el rendimiento. Al igual que las pruebas de regresión, debemos incluir pruebas de rendimiento en esas regresiones. Para ello, es importante contar con las herramientas adecuadas.

Herramientas y técnicas de prueba

Existen diversas herramientas open source y comerciales que ayudan en la ejecución de pruebas de rendimiento. Las pruebas deben realizarse en un entorno controlado que simule las condiciones de producción. Durante la ejecución, se deben recopilar datos detallados sobre el rendimiento del sistema, como tiempos de respuesta y throughput.

Llevar adelante una planificación de pruebas es fundamental para lograr crear software de calidad. Descubre en este artículo como diseñamos nuestros planes de prueba.

Te invitamos a conocer más sobre JMeter DSL, nuestra contribución open source, la cual permite integrar pruebas de performance en manera continua en los pipelines de desarrollo fácilmente y que promueve shift left testing. También puedes revisar esta charla de JMeter DSL en nuestro canal.

Seguimiento y mejora continua

El seguimiento de las pruebas es crucial para resolver problemas de manera efectiva. Es importante documentar los hallazgos y verificar continuamente que las soluciones mejoren el desempeño del sistema.

Un plan de pruebas bien diseñado y ejecutado contribuye a que un sistema cumpla con las expectativas de rendimiento. Utilizando técnicas de análisis de datos, las herramientas adecuadas y una estrategia definida, es posible identificar y solucionar problemas, con el fin de elevar la estabilidad y escalabilidad del sistema.

¿Buscas ayuda con el diseño y ejecución de las pruebas de performance?

Utilizando herramientas y mejores prácticas de SRE, DevOps, observabilidad y desarrollo de soluciones con el uso de IA, nuestro equipo de ingeniería de performance evita tiempos de inactividad y mejoran la confiabilidad.

En Abstracta, te ayudamos a mejorar el rendimiento de tu sistema, e-commerce, aplicación o plataforma web. Contáctanos para conocer cómo podemos ayudarte, o explora nuestro servicio de pruebas de rendimiento.

¡Síguenos en LinkedIn, X, Facebook, Instagram y YouTube para ser parte de nuestra comunidad!

Otros contenidos relacionados

¿Por qué son necesarias las pruebas de performance?

¿Cuándo es el mejor momento para comenzar con las pruebas de performance?