PRUEBAS DE CARGA Y ESTRÉS II

Tal y como os avancé en un artículo anterior, voy a continuar hablando de las pruebas de carga y estrés. Hoy me voy a centrar, entre otras cosas, en: proyecto de prueba de Carga, configuración de las pruebas de carga o ejecución de los test de pruebas.

Proyecto de prueba de Carga.

Para crear un proyecto de prueba de carga se crea un proyecto “c#” de tipo “Test”, “Web Performance» and «Load Test ProJect”

Web Performance Tests

Este test se crea para probar una aplicación web. El fin es generar un juego de pruebas en formato “Web Performance Tests” y que se genere una macro a través de la grabación de los pasos dados en la simulación.

El proceso es sencillo, al crear un nuevo elemento “Web Performance Test” se activa la grabadora del navegador permitiendo realizar varias peticiones web.

Al empezar la grabación de la macro se requiere una url de acceso a la aplicación y credenciales de acceso si la aplicación lo requiere.

Simplemente hay que parar la grabación cuando se desee y se habrá generado un “Web Performance Test”.

A partir de aquí, el objetivo es ir depurando estas peticiones hasta conseguir la ejecución completa y correcta del “Web Performance Test”.

“Web Performance Test” puede complementarse con “Data Sources” para accesos bases de datos, ficheros csv y ficheros xml; “Web Test plugins” para aislar código que se ejecuta antes y/o después de una petición; “credenciales” para establecer credenciales de acceso; “parametrización de servidores web” por si se cambia de entorno modificar solo el valor de la variable de contexto con el nombre de servidor; identificar “parámetros dinámicos” para ver datos de respuesta de la página web.

Desde el “Web Test Performance” se pueden realizar algunas operaciones útiles tales como insertar una “request”, crear una transacción para agrupar un conjunto de peticiones, crear un bucle para repetir un conjunto de peticiones un número determinado de veces o mientras se cumpla una condición, añadir una llamada a otro “Web Test” o volver a grabar en “Internet Explorer” una serie de peticiones y añadirlas a la grabación.

Load Test

Un “Load Test” es una prueba de carga que aglomera los test y define los diferentes entornos que se desean probar.

Se configura uno o más escenarios para la ejecución de los “Web Performance Test” con sus normas y comportamientos personalizados.

Desde un “Load Test” se termina de definir el porcentaje de conexiones que vendrán de los diferentes tipos de redes, la configuración de navegadores, la forma en la que se va a simular el acceso de los diferentes usuarios del sistema y su número, como por ejemplo: accesos por porcentajes de distribución, o por cuantas pruebas va a ejecutar cada usuario por hora, o si cada usuario ejecuta las pruebas en el orden que se especifica y cuando termine el ciclo vuelve a empezar la iteración.

Definir

Es recomendable tener en cuenta el “warm-up” (o tiempo de espera para que los servicios se levanten) y que sea acorde con el tiempo de duración de la prueba o del número de iteraciones que hayamos configurado.

El “sampling rate” es el tiempo que pasa entre la recogida de datos de los contadores de las máquinas que hemos decidido observar. Cuanto mayor sea este valor, los datos serán menos exactos. Pero capturar datos cada segundo hará que la prueba pase más tiempo recabando información que ejecutando la prueba en sí.

Configuración de las pruebas de carga

La información de los resultados se almacena en una base de datos SQL Server donde esta base de datos se genera automáticamente en el servidor local de base de datos. Es posible configurar la aplicación para no utilizar bases de datos para los resultados y/o generar ficheros de log.

Si parece que todo está configurando ya, aún no hemos terminado.

Antes de ejecutar la prueba de carga, hay que configurar los “Test Settings”.

En todo proyecto de pruebas de carga tiene que haber a nivel de solución un archivo de configuración de la prueba. Se puede crear uno si no existe o disponer de varios diferentes para poder ejecutar las pruebas en diferentes entornos.

A través del fichero “local.testsettings” se puede configurar información de seguimiento de diagnóstico, información del sistema, de una grabación de vídeo, simular cuellos de botella en las máquinas de prueba, reducir la memoria disponible del sistema o emular una red lenta, configurar la recopilación de datos de diagnóstico y para controlar las pruebas que se distribuyen en más de una máquina.

Ejecución de los test de pruebas de carga.

La ejecución de los test de prueba de carga se realiza desde el diseñador de “Web Test Performance”. Basta con seleccionar la opción “Run” o “Debug Test”.

Si se ha generado código fuente y este ha sido modificado, no es posible convertirlo a formato “Web Test Performance” por lo que la ejecución de este código ha de ser desde la pantalla del código fuente a través de las opciones “Run Codec Web Test Performance” o “Debug Codec Web Test Performance ”

Tras la ejecución de las prueba del test se mostrará un panel de control con las opciones de “Request”, “Response”, “Context” y “Details” desde donde se podrá recuperar la información necesaria para la validación y ajuste de las pruebas.

Ejecución de las pruebas de carga

De igual manera, desde el diseñador de las pruebas de carga “Load Test” es posible ejecutar las pruebas de carga a través de las opciones “Run Load Test” o “Debug Load Test”.

Tras la ejecución de las prueba del carga se mostrará toda la información referente a los resultados.

Es posible exportar esta información a un fichero Excel para su estudio y análisis posteriores.

Code Coverage

El “Code Coverage” nos indica qué líneas de nuestro código han sido ejecutadas tras lanzar un test. De esta forma puede saberse si hay partes del código que no están siendo testeadas.

Si el porcentaje es bajo es que hay muchas partes del código que no podemos asegurar que funcionen. Lo óptimo sería un 80% o 90% de porcentaje.

Por desgracia, mi versión de “Visual Studio” no disponía de esta opción por lo que no he podido probarlo.

IntelliTrace

Se recomienda el uso de “IntellTrace” para registrar y realizar el seguimiento del historial de ejecución del código.

No es compatible el uso conjunto con “Code Coverage”.

Seguridad en las páginas de prueba

Si la seguridad de la aplicación a testear es robusta, seguramente sea necesario la generación de código fuente del “Web Test Performance” y el desarrollo personalizado de “plugins” en mi caso, para obtener “tokens” de usuario y accesos a la API de “SignalR”, pero esto ya es una historia muy larga que dejaremos para otra ocasión.

Mª Teresa Estévez Rama