Generación de test con CAS

El sistema de autenticación centralizado (CAS) es una aplicación externa a nuestras aplicaciones web encargada de autenticar a los usuarios.

Cuando realizamos test de carga es importante no centrar la carga en esta aplicación ya que podremos estar generando retardos que no tienen que ver con la lógica.

Una manera de evitar esto es modificar el login de nuestra aplicación para que no use el CAS por lo tanto podremos probar la lógica sin problemas. La pega de esta solución es que requiere modificaciones en nuestra aplicación.

En esta wiki vamos a ver cómo hacer un test de carga que no requiera modificaciones en nuestra aplicación, pero no sature el CAS con múltiples accesos. Para ello conseguiremos que la herramienta de test de carga JMeter haga login en el CAS sólo una vez por hilo independientemente de las veces que se repita el test.

Así pues para una prueba con 100 hilos y 100 repeticiones por hilo sólo accederemos al CAS 100 veces, es decir, una vez por usuario, aunque haga 10000 repeticiones de la misma funcionalidad.

Para hacer los test de carga se ha preparado una plantilla por lo que es suficiente con descargarla y empezar ahí nuestro test. plantilla test de carga con CAS (compatible con JMeter 3.x y superior)

A la hora de construir nuestro test de carga tendremos que seguir los pasos de construcción de un test sin CAS indicados en la wiki Creación de test en aplicaciones web con JMeter

Posteriormente definiremos, dentro del Controlador Simple creado según los pasos de la wiki anterior, un Controlador Only Once que procesará el login del CAS para que sólo se realice una vez.

El primer paso es capturar la secuencia de peticiones de nuestra aplicación y eliminar las que aparezcan deshabilitadas.

Nuestra test deberá comenzar con una petición GET que pida la página de incio de nuestra aplicación

Una vez realizada la petición GET haremos uso del Controlador Only Once que se encargará de que las peticiones que contiene sólo se ejecuten una vez por hilo. Dentro de este controlador sólo necesitaremos la petición post enviando al CAS los datos de autenticación y las comprobaciones necesarias para asegurarnos que nos devuelve un token correcto.

Como podemos ver en este controlador, a parte de la petición POST tenemos:

• Parámetros de usuario: Esta es una herramienta de configuración situada en los preprocesadores que nos permite establecer parámetros que se usarán en la petición. En nuestro caso crearemos el parámetro user y pass que serán los que lleven el usuario y contraseña de la petición post.
• Extractor CASTGC: Este PostProcesador de expresiones regulares, extrae de la cabecera de la respuesta el token TGC que comprueba que el CAS validó al usuario y generó un token para él. La configuración de esta propiedad es la siguiente:

• Aserción TGC: Esta aserción comprueba que el login fue validado por el CAS checkeando el token TGC. La configuración es la siguiente:

Una vez establecidas estas condiciones salimos del Controlador Only Once ya que el resto de las peticiones sí se tienen que repetir por lo que estarán dentro del Controlador Simple.

La configuración es similar a las de unas pruebas de carga normales, salvo por tres parámetros adicionales que hay que incluir:

• Extractor del CAS lt
• Extractor del CAS execution
• Control de error de CAS.

Es un extractor de expresiones regulares que nos permite obtener el parámetro lt del CAS necesario para el POST de autenticación realizado en el controlador Only Once. Su configuración es la siguiente:

Al igual que el extractor del CAS lt, se obtiene el parámetro execution necesario para enviar en el post del CAS. Su configuración es la siguiente:

Esta aserción comprueba que el CAS no haya producido un error y se nos redirija a esa pantalla, saliendo del flujo normal de ejecución de la aplicación. Su configuración es la siguiente: