Etiqueta: Jesús Moreno

Como parte importante y necesaria del testing, las pruebas de rendimiento me parecen fascinantes, en particular las pruebas de carga y las de estrés.

Las pruebas de carga validan que se alcanzan los objetivos a los que se verá sometido el sistema en un entorno de trabajo normalizado, mientras que las de estrés someten al sistema a una carga por encima de los límites requeridos con el objetivo de encontrar el punto de ruptura del sistema.

La realización de las pruebas de rendimiento en un entorno financiero y aplicables al resto  tiene 4 fases diferenciadas y al mismo tiempo relacionadas, a continuación intento dar el enfoque con el que trabajamos.

Paso 1 – Requisitos de la prueba

Es la fase donde el tester tiene que adentrarse y situarse en el escenario de la prueba, como elementos importantes en esta fase destacan:

• Diagrama topológico del sistema
• Capacidad del sistema o pruebas de rendimiento de referencia
• Propósito de la prueba
• Carga a generar en el sistema

Diagrama topológico del sistema

Importante para situar al tester en el entorno y tener una visión del sistema objeto de la prueba, en el siguiente gráfico se puede ver un ejemplo.

Capacidad del sistema o pruebas de rendimiento de referencia

Esencial para tener un punto de partida o de comparación, de lo contrario, serían necesario realizar más pruebas para determinar métricas del sistema.

Propósito de la pruebas

Determinar que parte del sistema o funcionalidad  es el objeto de la prueba y establecer objetivos coherentes.

Carga a generar en el sistema

Por lo general, número de usuarios (threads) concurrentes durante la prueba y forma como se distribuye la carga, dependiendo del objeto de la prueba puede ser secuencial o intervalos. a continuación se muestra un ejemplo.

La carga puede ser generada de forma interna (desde la misma red) o de forma externa simulando conexiones desde uno o diversos puntos, se realiza de forma externa cuando la carga se considera alta y queremos estresar todo el sistema.

Paso 2 – Preparación de la prueba.

Es la parte más técnica de la prueba y se basa en la “grabación”  de la secuencia de navegación de la funcionalidad a probar y que posteriormente será emulada por cada usuario (thread).

Es recurrente que una prueba de rendimiento agrupe varias grabaciones, con el fin de reproducir una carga de trabajo que recoja las funcionalidades más comunes.

Para la grabación, se utilizan los “sniffers” plugins de navegadores o de aplicaciones que ayudan a captar todas las peticiones (request) que realiza la aplicación al servidor.

Para la implementación de las pruebas de rendimiento existen diferentes herramientas, siendo una de ellas Apache jmeter (opensource).

Paso 3 – Ejecución de la prueba

Es el día D, el momento en que todo está orquestado.

Es recomendable reproducir las pruebas de rendimiento en modo prueba unitaria para comprobar que no ha habido ningún cambio en la funcionalidad del sistema entre el Paso 2 y la ejecución de la prueba.

Durante la ejecución es clave la comunicación y se debe estar alineado con:

• Departamento de sistemas
• Departamento de Comunicaciones
• Departamento de Seguridad

Durante la ejecución el tester tiene la capacidad de detener la prueba si los resultados no son los esperados.

Paso 4 – Informe

Tras el análisis de la prueba, el informe de la prueba debe reflejar las gráficas de rendimiento obtenidas y los errores detectados.

Es en esta fase donde la capacidad analítica del tester ayuda a plantear conclusiones y aportar valor añadido a los responsables.

Ejemplo de gráfica de rendimiento:

 

Jesús Moreno

Test Engineer

Software Control & Testing | Sogeti