Evaluación de una herramienta de pruebas de rendimiento

1 ¿Por qué una herramienta de Pruebas de Rendimiento?

El objetivo de las pruebas de rendimiento (performance testing) es simular el comportamiento de una aplicación o sistema cuando sobre él actúan de manera concurrente un número elevado de usuarios.

El propio objetivo de las pruebas obliga a disponer de algún tipo de herramienta que permita "inyectar" la actividad de cientos o miles de usuarios y además obtenga los indicadores de rendimiento (tiempos de respuesta, transacciones/hora, consumo de recursos, etc..)

Existen multitud de herramientas que permiten realizar pruebas de carga. Para realizar una selección adecuada debemos fijar unos criterios de evaluación que nos permita seleccionar una herramienta que se adapte a nuestras necesidades y presupuesto.

2 Criterios de evaluación.

Veamos algunos criterios que tenemos que tener en cuenta a la hora de elegir una herramienta de pruebas de rendimiento. El siguiente mapa mental nos puede servir de guía.

2.1 Protocolos/Productos de las aplicaciones bajo pruebas

La herramienta debe soportar la tecnología y protocolo de la aplicación bajo
pruebas. Los protocolos más comunes  (HTTP/HTTPS, SMTP, SOAP/Web Service y ODBC...), suelen estar soportados por herramientas Open Source, pero según aumente la complejidad de la aplicación (tecnolgías RIA, MS Sharepoint, etc..), más complejo es la generación de pruebas realistas y se hace necesario el uso de herramientas de aplicación general que suelen incorporar ayudas para este tipo de tecnologías optimizando los esfuerzos en las tareas de scripting.

También debemos considerar la posibilidad de protocolos asociados a productos comerciales (Siebel/Oracle, SAP GUI, CITRIX, Terminal Server, Tuxedo, etc...). Para realizar pruebas sobre aplicaciones basadas en estos productos es necesario disponer de herramientas de aplicación específica capaces de "capturar el tráfico de los usuarios", y de proveer herramientas de asistencia a la generación de scripts que nos ayudarán a diseñar pruebas realistas.

  
2.2 Número de usuarios virtuales

El objetivo es simular una actividad similar o incluso superior a la que la aplicación soportará en el entorno productivo. Esto se consigue mediante introducción de usuarios virtuales o hilos de ejecución concurrentes que simulan la actividad de los usuarios reales.

La estimación del número de usuarios virtuales suele ser una labor compleja, e incluso polémica, dentro de la planificación de las pruebas. Por ello, tenemos que tener muy claro el grado de concurrencia que debemos simular y a qué nivel de aplicación estamos forzando la concurrencia.

En el caso de que necesitemos una herramienta comercial, el número de usuarios virtuales tiene implicaciones directas en el coste. Por ello, es importante considerar que los usuarios virtuales introducen en el sistema una carga superior a la que introduce un usuario real. Una buena estrategia para ahorrar en costes de licencia es  dimensionar el número de usuarios virtuales contratados en función de la concurrencia a nivel de proceso de negocio.

2.3 Infraestructura.

Las pruebas de rendimiento necesitan de una infraestructura de apoyo que soporte los distintos elementos: Controladores, Inyectores, herramientas de monitorización, etc... La infraestructura de equipos y ordenadores debe considerarse en el presupuesto.

También debemos considerar si es necesario instalar complementos sobre otros elementos de la infraestructura. Por ejemplo existen herramientas de monitorización de consumo de recursos que necesitan de la instalación sobre los servidores de la aplicación, por lo que será necesaria la colaboración de los equipos y departamentos de sistemas de nuestra organización.

2.4 Número de pruebas a realizar

A la hora de contratar una herramienta para pruebas de carga debemos tener en cuenta la demanda para este tipo de prueba. Debemos evaluar:

• El número de aplicaciones sobre las que realizaremos pruebas
• El número de pruebas a realizar en cada aplicación

Si nuestra organización es grande, normalmente nos encontraremos ante un ecosistema en el que convivirá un gran número de tecnologías y arquitecturas. Las pruebas de rendimiento se tendrán que enfrentar a todas ellas y deberemos disponer de herramientas potentes que las soporten (comerciales)

La necesidad de realizar un gran número de pruebas, suele implicar tiempos de diseño cortos y herramientas que nos proporcionene altas productividades: rápida construcción de scripts, facilidad de análisis de resultados, e integración con otras herramientas

Por el contrario, si el número de pruebas se estima pequeño, se concentran en periodos de tiempo puntuales y las tecnologías de las aplicaciones sobre las que probamos está muy acotada, quizás sea conveniente dirigir los esfuerzos hacía herramientas más económicas.

2.5 Entorno (Cloud Testing)

Debemos valorar cómo inyectaremos la carga sobre la aplicación y si disponemos de la suficiente capacidad de inyección para llevarlo a cabo (inyectores de carga y ancho de banda). 

Las pruebas de rendimiento a través de Cloud Testing nos lo podemos plantear en:

• Pruebas sobre aplicaciones desplegadas en entornos cloud
• Pruebas sobre aplicaciones en modalidad hosting clásico pero a las que tengamos que atacar desde ubicaciones geográficas reales.

En la actualidad existen un gran número de proveedores de pruebas de rendimiento en cloud que no solo prestan su infraestructura, si no también el posible software para realizar las pruebas

2.6 Licenciamiento.

Las herramientas comerciales de pruebas de rendimiento presentan un tipo de licenciamiento particular y que en ocasiones resulta complicado de entender. En general el licenciamiento depende del número de usuarios virtuales contratados y del número de protocolos sooportados. A mayor número de usuarios virtuales y protocolos contratados, mayor será el precio de la licencia.  En general tendremos tres tipos de licencimiento:

• Free: Típico de las herramientas Open Source, nos permiten disponer de un número ilimitado de usuarios a un precio bajo o nulo para protocolos sencillos.
• Fijo (Fixed): Dispondremos de un número fijo tanto de usuarios virtuales como de protocolos  de manera indefinida. La inversión inicial es alta, pero el coste de la herramienta se amortiza a lo largo del tiempo. El costo por prueba tiende a ser muy bajo.
• Alquiler (Rent): Podremos contratar el número usuarios virtuales  y protocolos  para su uso por un periodo de tiempo limitado. Esta modalidad nos permite contratar la herramienta en el tiempo de uso. Por esa razón el costo por prueba realizada suele ser alto.
• Pago por uso (pay per use): Tendremos flexibilidad en los términos de la licencia en y unicamente pagaremos por el tiempo que utilicemos la licencia. Este tipo de licenciamiento en típico de herramientas cloud.

Cada tipo de licencia presenta riesgos que debemos contemplar, veamos algunos:

• Las herramientas Free, presentan problemas con tecnologías complejas y los ratios de productividad suelen ser bajos debidos a la dificultad para generar scripts.

• La compra de una licencia definitiva (fixed), nos limita a los términos contratados, por lo que los riesgos los encontramos ante evolución de las tecnologías hacía nuevos protocolos o si es necesario introducir niveles de carga superiores a los contratados.

3 Tipos de Herramientas

3.1 Herramientas comerciales

En el mercado existen multitud de herramientas comerciales para la realización de pruebas de rendimiento. Sus principales características son:

• Protocolos soportados: Generalmente estas herramientas soportan la mayoría de protocolos y aportan librerías de apoyo en aquellas tecnologías más complejas. Hay que tener en cuenta que generalmente un mayor número de protocolos supone un mayor costo en la licencia.
• Necesidades de infraestructura: Coste Medio/Alto
• Número de usuarios virtuales:  El número de usuarios virtuales impacta directamente en el costo de la herramienta
• Tiempo de Desarrollo (Time to market): Coste Medio. Estas herramientas aportan facilidades y herramientas que facilitan la optención de scripts, la generación de escenarios y el análisis de resultados.
• Curva de aprendizaje: Coste Medio
• Soporte: Bueno. Disponen de equipos de soporte dedicados.
• Disponen de extensiones que pueden integrarse con la herramienta y que amplían las funcionalidades: herramientas de monitorización integradas, herramientas de análisis, etc...  

3.2 Herramientas Freeware/Open Source 

• Protocolos soportados: Generalmente estas herramientas no soportan directamente todos los protocolos y es necesario recurrir a desarrollos particularizados.
• Necesidades de infraestructura: Coste Medio
• Número de usuarios virtuales: El límite en el número de usuarios virtuales se encuentra en la infraestructura que dispongamos.
• Tiempo de Desarrollo (Time to market): Coste Alto. El desarrollo de scripts y los tiempos de grabación pueden ser altos.
• Curva de aprendizaje: Alto.
• Soporte: Bajo. Es necesario recurrir a foros y grupos de noticias.

3.3 Herramientas Cloud Testing 

En la actualidad ha crecido la demanda de pruebas en entornos cloud. Las principales características son:

• No necesita ningún tipo de instalación de la herramienta.
• Pago por uso. Puede ser por número de pruebas o por tiempo de ejecución.
• Protocolos soportados: Dependen del tipo de herramienta.
• Necesidades de infrestructura: Coste Bajo o Nulo
• Número de usuarios virtuales: No disponemos de límite en el número de usuarios virtuales aunque puede impactar en el coste.
• Tiempo de Desarrollo (Time to market): Coste Alto. El desarrollo de scripts y los tiempos de grabación pueden ser altos.
• Curva de aprendizaje: Depende de la herramienta seleccionada. Generalmente en la nube encontramos las mismas herramientas comerciales o Open Source.
• Soporte: Medio.
• Es necesario que la aplicación bajo pruebas tenga conectividad con los inyectores en la nube.
• La mayoría de fabricantes suministran ya soluciones cloud basadas en sus productos.