En el área del testing se crean pruebas funcionales para validar el funcionamiento de las características de un sistema, y pruebas no-funcionales para validar características no relacionadas al funcionamiento, por ejemplo; el estilo de la interfaz, contenido, presencia de imágenes, efectos, rendimiento, seguridad, etc, enfocándose en el área de rendimiento. Adicionalmente, se incluye la instalación y uso de la herramienta JMeter, una de las más utilizadas para ejemplificar los conceptos presentados.
Pruebas De Rendimiento
Con este tipo de pruebas se busca analizar el comportamiento del sistema ante diferentes niveles de carga.
A nivel del proyecto el objetivo de las pruebas de desempeño, es determinar qué tan preparado está el aplicativo para ser lanzado a producción, evaluando las siguientes características de desempeño.
Es una forma de evaluar el comportamiento de cualquier aplicación, cuando se adapta con diferentes cargas (usuarios / tráfico) en palabras simples, la prueba de carga ayudan a comprender cómo funciona un programa (supongamos que un sitio web «abc.com») cuando 20 usuarios están usando la plataforma en el mismo momento, se aplica el nivel de carga típico al que está sometido el sistema, se identifican cuellos de botellas, principalmente se deben simular las transacciones críticas.
Las pruebas de estrés son un método para analizar lo que podría ocurrir en determinados escenarios, por lo tanto no se utiliza como una herramienta de predicción.
El sistema es sometido a cargas robustas, (menores a las de estrés) la carga se debe mantener durante un tiempo prolongado y se evalúa la estabilidad del sistema mientras soporta la carga.
El sistema es sometido a cargas robustas, la carga debe ser aplicada en un tiempo muy reducido, se evalúa el comportamiento del sistema ante subidas y bajadas repentinas.
Una vez definido los conceptos básicos, se procede a realizar un instructivo o tutorial de una prueba en Jmeter.
Pantalla con la que se inicia en JMeter
En el frame izquierdo se ve los elementos que componen el plan de pruebas.
En el frame derecho, se ve el detalle o la configuración del elemento que se está seleccionando en el frame izquierdo.
Test Plan: Es como un contenedor que almacena los elementos necesarios para ejecutar una prueba. Es la raíz de nuestro script.
Un Thread Group es el conjunto de usuarios virtuales, (threads) que serán enviados al servicio que se está probando. Son semejantes a varios robots de Selenium.
Se da click derecho en Test Plan y se selecciona Add//Threads (Users)//Thread Group
Una vez agregado, la prueba debe verse así.
Number of Threads (Users)
Es el total de usuarios virtuales que quiere enviar durante la prueba.
Es una rampa que determina en cuánto tiempo se ha enviado el total de usuarios virtuales al servicio que se está probando, ejemplo: si establecemos un Number of Threads de 100 y un Ramp-up
Period:
de 60 segundos, entonces se estará enviando 100/60=1.66667 usuarios virtuales por segundo y al ajustar un tiempo de ejecución de 60 segundos, se han enviado los 100.
Loop Count:
Es la cantidad de ciclos en los que se puede estar enviando el Thread Group actual.
Continuar aunque aparezca algún error durante la ejecución de algún Thread.
Inicia el siguiente loop (ciclo) si encuentra un error durante la ejecución del loop actual.
Detiene la ejecución del loop actual y no inicia los demás ciclos, todo el Thread Group se detiene.
Se detiene la prueba en total, los threads que estén en ejecución se completan antes de detener la prueba.
Se detiene la prueba de forma inmediata, es un stop más agresivo y no espera a los threads en ejecución.
Es semejante al runner de un test con JUnit, Recordar que un runner es aquel que toma un ensamble (conjunto de configuraciones, features, utilidades) que contiene pruebas y lo ejecuta generando un reporte de lo que ha hecho. En este caso, el sampler es el que va a tomar los threads y los va a enviar hacia el aplicativo deseado, para agregar un sampler (en este caso un HTTP Request) se da clic derecho en el Thread Group agregado y continúan la ruta Add//Sampler//HTTP Request.
Con el Sampler agregado, se procede a seleccionar y a escribir el nombre o la IP del servidor que se va ha probar: www.blazedemo.com
Dado que la prueba se va a realizar en el home page, se agrega un / a la casilla Path:
Los temporizadores le dan realismo a las pruebas, ya que los threads no deberían ejecutar acciones de forma inmediata, como clics con diferencias de milisegundos, cuando se agrega un temporizador se agrega un delay a la ejecución del test (la ubicación del timer en el test plan afecta de diferentes formas)
Para agregar un temporizador constante al HTTP Request, se da clic derecho sobre el sampler y se selecciona Add//Timer//Constant Timer.
Agregando el constant timer al sampler, se aplica un delay a cada thread que se envíe al servidor, probando que el valor del delay puede ser cambiado en la casilla señalada.
El temporizador agrega un delay constante + un delay variable, para añadir un uniform random timer, se selecciona Add//Timer//Uniform Random Timer.
Los campos que se deben configurar están señalados en la imagen.
El Random Delay Maximum (cuadro naranja) es el valor máximo de delay variable que se agregará a la ejecución de cada thread, y el Constant Delay Offset (cuadro azul) es el valor de delay constante que tendrá la ejecución de cada thread, Para este caso sólo se agregó el valor aleatorio, por lo que cada thread tendrá un delay entre 0 y 100 ms.
Con los asserts validamos que se están recibiendo las respuestas que se esperan por parte del servidor, también sirven para validar lo que está siendo dirigido a la página correcta. Para agregar un assert, se da clic derecho en el sampler y se selecciona Add//Assertions/Response Assertion.
En el Response Assertion, se identifica lo siguiente en el área de opciones Field to Test (campo del responsable del servidor)
En el área de Pattern Matching Rules, identificamos lo siguiente:
Utiliza expresiones regulares (RegEx) validar que el texto que se recibe por parte del servidor contiene el texto que se indica en el assert.
Usa expresiones regulares (RegEx) es similar a Contains, con la diferencia de que el texto que se recibe por parte del servidor debe ser completamente igual al que se indica en el assert.
Usa texto plano, su validación es igual a la de Matches.
Usa texto plano, su validación es igual a la de Contains.
En el área Patterns to Test, se agrega el texto que se quiere validar, en ese caso se agrega la palabra Welcome, junto a la configuración del Response Assertion presentada en la imagen.
Un Listener es aquel que está pendiente de lo que sucede durante la ejecución de una prueba, para agregar un View Results Tree, se selecciona Add//Listener//View Results Tree.
Un View Results Tree, permite ver los resultados del Test como si estuviera siendo ejecutado en modo debug, en el cuadro naranja se especifica un archivo donde se quiere que JMeter guarde los resultados, o se especifica un archivo que contenga resultados de pruebas anteriores.
Presionando el botón Configure, aparecerá una ventana emergente donde se selecciona los datos de la ejecución que se quiere almacenar.
El Test Plan debería tener la siguiente estructura.
En el View Results Tree, se puede observar el resultado de las ejecuciones; cada vez que se presiona el botón señalado por el cuadro azul, se ejecuta el Test Plan, en ese caso el botón señalado se presionó dos veces, donde en la primera ejecución se alteró el valor del Assertion para que falle (el assert esperaba un mensaje que contenga WelcomeAAA) y en la segunda ejecución se corrigió el valor esperado en el assert para que la prueba no falle.
Para observar un error se expande el resultado del HTTP Request fallido y se da clic en la opción Response Assertion, el mensaje que se recibe indica que acciones tomar.
Con la herramienta Plugins Manager es más fácil gestionar los plugins de JMeter, para descargarlo ingrese al siguiente link y haga clic en el texto señalado por el cuadro rojo: https://jmeter-plugins.org/wiki/PluginsManager/
Cuando el jar esté descargado, agregarlo en la ruta lib/ext de JMeter.
Si tiene JMeter abierto, se cierra y se vuelve a abrir, diríjase al menú y seleccione la lista Options.
Si aparece la opción mostrada, es porque JMeter reconoce e integró el plugin.
Abrir el Plugins Manager.
Buscar el Standard Set seleccionarlo, y hacer clic sobre el botón ‘Apply Changes and Restart JMeter’
Cuando JMeter se reinicie, tendrá disponibles nuevas opciones para armar sus pruebas de rendimiento, en ese caso el que se usará es el listener PerfMon Metrics Collector. Este recibirá los datos enviados por el PerfMon Server Agent y los verificará o guardará.