Cada día nuestros usuarios se vuelven más exigentes a la hora de utilizar nuestras aplicaciones. Los sistemas no sólo deben de funcionar correctamente, sino que también deben responder al instante. Te puedo asegurar que:

  • Si el sistema responde en una décima de segundo (0.1 seg.) el usuario se encontrará satisfecho, esto nos dará más probabilidad de que siga utilizando nuestros servicios.
  • Si responde hasta en 3 segundos, estaremos dentro del límite de tolerancia de espera, el usuario lo aceptará.
  • Si a la aplicación le toma más de 3 segundos prepararse para su uso, es muy probable que los usuarios la abandonen o que ocupen ese tiempo para realizar otras actividades, perdiendo su completa atención.

Por lo tanto, es aconsejable mantener aplicaciones que respondan de manera inmediata si lo que deseas es convertir tus visitantes en usuarios concurrentes.

¿Qué son las pruebas de rendimiento?

A los usuarios no les interesan las cuestiones técnicas del por qué la aplicación se comporta lenta.

Las pruebas de rendimiento (performance testing)  tienen como objetivo detectar los problemas (usando programas especializados) que ocasionan lentitud en la respuesta de los sistemas, antes de que estos sean colocados en un ambiente productivo.

Estas pruebas no buscan defectos funcionales (esos se debieron de haber detectado y corregido antes de hacer estas pruebas). Tratan de detectar las causas que afectan al rendimiento de los sistemas y que nada tienen que ver con cuestiones funcionales.

Es importante que durante la ejecución de este tipo de pruebas, se realize el monitoreo del comportamiento de las bases de datos, servicios, CPU del servidor, uso de memoria, etc., con la intención de detectar qué componente está ocasionando el problema de rendimiento.

Conceptos fundamentales

Si recién te incorporas al mundo de las pruebas de rendimiento, te aconsejo que te familiarices con los siguientes términos, muy utilizados en el ámbito del performance:

  • Modelo de carga: El modelo de carga es la especificación de cómo se realizarán las pruebas de rendimiento (¿a los cuántos minutos se incrementarán los usuarios? ¿Cuántos usuarios usarán la aplicación? ¿cuál es el tiempo esperado de respuesta?, etc.).
  • Punto de quiebre: Es el momento en el que el sistema deja de enviarle respuesta al usuario y le presenta errores como “Servidor no encontrado”.
  • Concurrencia: Situación presentada cuando distintas personas realizan la misma acción al mismo tiempo.
  • Testers virtuales: Son usuarios no reales que hacen uso de la aplicación por determinado tiempo. Estos son “generados” por aplicaciones especializadas. Sería imposible tener a más de mil personas haciendo la misma prueba durante 5 horas.

Tipos de pruebas de rendimiento

Existen muchos tipos de pruebas para medir el rendimiento de los sistemas, en este artículo sólo te mencionaré las más reconocidas.

Pruebas de carga

Estas pruebas demuestran la capacidad y comportamiento que tiene un sistema (software/hardware) atendiendo un determinado número de usuarios o transacciones de manera simultánea.

El objetivo de este tipo de pruebas es predecir el funcionamiento que tendrá el servidor cuando se encuentre operando en un ambiente productivo.

Las pruebas de carga no sólo sirven para demostrar que para un sistema hacen falta recursos, sino también para comprobar que estos están siendo subutilizados.

Pruebas de estrés

Cuando se llega el punto de quiebre del servidor, este deja de responder.

Las pruebas de estrés (stress testing) son utilizadas para encontrar el punto de quiebre de las aplicaciones (o servidores) y consisten en iniciar la ejecución de la prueba con pocos usuarios e ir incrementando el número de estos hasta que el sistema deje de responder.

Este tipo de pruebas son muy útiles cuando se espera atender a un número masivo de visitas durante un evento temporal.

Pruebas de volumen

Estas pruebas están enfocadas a revisar el comportamiento de las aplicaciones con grandes cantidades de datos. Si una base de datos tiene un millón de registros no responderá a la misma velocidad que cuando tenía diez, es común que el rendimiento se vea afectado.

La mayoría de los datos de las aplicaciones crecen de manera considerable conforme el uso y paso del tiempo.

El objetivo de estás pruebas es predecir la necesidad de mayor recursos en la infraestructura de la aplicación, para que estos sean asignados antes de que los límites de capacidad actuales sean superados y se vea degradado el funcionamiento de la aplicación.

Pruebas de estabilidad

No importa cuánto tiempo un sistema permanezca en uso, debe de funcionar igual en todo momento.

Para este tipo de pruebas (soak testing), el número de testers virtuales no se reducen ni se aumentan. Simplemente se somete una prueba continúa durante un tiempo de uso prolongado, para comprobar que la aplicación no presenta degradación o alguna otra incidencia.

Estas pruebas ayudan a verificar que en los sistemas no existan fugas de memorias.

Pruebas de picos

A diferencia de las anteriores, en estas pruebas (spike testing), el número de usuarios incrementa y decrementa drásticamente durante un periodo de tiempo prologando (mil usuarios, cinco usuarios, mil usuarios, cinco usuarios…).

El sistema debe de ser capaz de recuperarse debidamente y no debe mostrar afectación ante este tipo de comportamiento.

Ejemplo de una prueba de picos, en donde usan diez usuarios el sistema y luego mil.

Pruebas de aislamiento

Las pruebas de aislamiento son similares a las pruebas modulares, en donde se va probando cada componente por separado con el objetivo de detectar cuál es aquel que ofrece un rendimiento no esperado y que afecta a la respuesta de los demás módulos, componentes o servicios.

Consejos y recomendaciones

Te comparto consejos que puedes aplicar a la hora de hacer pruebas de rendimiento:

  • Te recomiendo que hagas las pruebas de rendimiento hasta que estés seguro de que ya no existirán cambios en el sistema. Si estos se llegasen a presentar, entonces deberás realizar pruebas de regresión del rendimiento, para comprobar que los resultados siguen siendo los mismos y si cambiaron, tomar acciones correctivas.
  • Nunca podrás obtener los mismos resultados en una simulación que en la realidad, son aproximaciones, por lo tanto, deberás informar antes de realizar las pruebas todas las situaciones que alteres antes de iniciar tus pruebas para generar conciencia en tus superiores.
  • Las pruebas de performance son muy caras, pero puedes disminuir el costo haciendo pruebas a escala (usa un sólo servidor y de ahí obtén conclusiones de cómo se comportará con cinco servidores).
  • Agrega a tu plan de pruebas los supuestos, restricciones y los posibles riesgos que se pueden presentar durante la ejecución de las pruebas.
  • De nada servirá la ejecución de pruebas si no expresas de manera entendible tus resultados. Recuerda que los lectores de tu informe no tendrán el mismo nivel de conocimiento técnico que tú. Además, el informe es lo más importante de las pruebas, pues sirven para que se tomen las medidas preventivas o correctivas adecuadas.
Tus pruebas de rendimiento deben de ser muy cercanas y parecidas a la realidad.

Conclusión

Las pruebas de rendimiento ayudan a mejorar la experiencia y satisfacción del usuario, ayudando a crear aplicaciones más eficientes a la hora de realizar operaciones. Este tipo de pruebas no sólo te ayuda a identificar los componentes que están generando problemas en los tiempos de respuesta (funciones, herramientas, bases de datos, componentes, etc.), sino también a predecir el comportamiento que dará la aplicación con el transcurso del tiempo y aumento de su uso.

Es necesario, antes de que ejecutes cualquier tipo de pruebas, que realices la evaluación de qué es lo que necesitas conocer, porque cada tipo de prueba te dará un resultado diferente. A partir de eso, puedes determinar qué pruebas realizarás y cómo establecerás tu modelo de carga.

Recuerda que si no hay presupuesto para mejoras de código, si los tiempos son limitados o no existe cooperación, etc., es conveniente que no ejecutes las pruebas, ya que sólo se incurrirá en un gasto que no generará ningún valor.