Pruebas de rendimiento

El rendimiento de un sistema es un valor tanto o más importante que la propia funcionalidad del sistema. Se puede diseñar un software con una funcionalidad novedosa, desarrollado bajo las más estrictas pruebas funcionales y con la interfaz más intuitiva y amigable, pero si este no responde de manera adecuada en el ambiente para el que ha sido diseñado, su calidad general será bastante peor de la esperada.

En la vida actual, se requiere velocidad, fluidez, trabajo en tiempo real, por lo tanto, las pruebas de rendimiento son esenciales antes de poner un sistema en producción. Pueden utilizarse para obtener distintos objetivos; rendimiento máximo del sistema, comparación entre distintas versiones o configuraciones, detección de cuellos de botella entre los componentes del sistema, etc.

Dentro de las pruebas de rendimiento, estas se pueden dividir a su vez en distintos tipos:

Pruebas de carga:

Su principal objetivo es comprobar el comportamiento del sistema frente a un uso intensivo del mismo, por ejemplo, un gran número de usuarios concurrentes. Durante las pruebas de carga, se pueden obtener tiempos de respuesta del sistema según el número de usuarios, carga de las máquinas, uso de memoria, …

Pruebas de estrés:

Se utilizan en conjunto con las pruebas de carga. Estas consisten en aumentar el número de usuarios concurrentes o peticiones (en función del diseño del sistema) que se utilizarán en las pruebas de carga. Generalmente, este aumento se hace doblando en cada iteración el número de peticiones. Con estas pruebas obtenemos cual es el máximo uso admisible por el sistema. También se podría determinar qué elemento es el que lo limita para estudiar una futura escalabilidad si es hardware o un rediseño si es software.

Pruebas de estabilidad:

Determinan la fiabilidad del sistema en uso continuo. Comprueban la correcta gestión de memoria, gestión de conexiones en la red, gestión de ficheros de log, consultas a BD con gran cantidad de datos, … Si algo funciona 10 minutos no quiere decir que vaya a funcionar igual después de 10 días.

 Una posible metodología a seguir (según MSDN):

  • Identificación del ambiente de pruebas
  • Identificación de los criterios de aceptación
  • Planing y diseño de las pruebas
  • Configuración del ambiente de pruebas
  • Implementación del diseño de pruebas
  • Ejecución de las pruebas
  • Análisis de resultados y reporte de incidencias detectadas
  • Nueva fase de pruebas

En este enlace teneis una lista con numerosos programas enfocados a las pruebas de carga. En siguientes post hablaré sobre la librería ContiPerf, la cual añade a JUnit nueva funcionalidad enfocada a las pruebas de rendimiento.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s