Este documento presenta una introducción a las pruebas de rendimiento. Explica conceptos clave como tiempo de respuesta, latencia y throughput. También describe los objetivos, riesgos y tipos de pruebas de rendimiento, así como la metodología y herramientas disponibles como JMeter. Finalmente, brinda detalles sobre cómo configurar y ejecutar scripts de prueba básicos en JMeter.

1. Performance
Testing 101 con

2. Sponsor

3. ● Fiel Esposo y Padre de 2
● Eterno Inconformista
● Además:
○ Pasatiempo: Me encanta cocinar (y ni les digo comer)
○ Libro Preferido: Dune - Frank Hertzberg
○ Película Preferida: Star Wars - El Imperio Contraataca
○ Producto Preferido: Amazon.com
○ Ingeniero en Sistemas UTN FRBA
○ 20+ Años Experiencia en IT/Desarrollo de Software
○ Gerente de Quality Engineering @AVANTRIP.com
Acerca de Mi

4. Acerca de Nosotros (La Clase)
- Conversar con el compañero de al lado e intercambiarse estas 4 preguntas:
- Nombre
- Pasatiempo
- Libro / Película Favorit@
- Producto Preferido (y por qué?)

5. Agenda
- Conceptos de Performance Testing:
- Definiciones
- Objetivos, Riesgos, Metodología y Tipos de Pruebas de Performance
- Herramientas Disponibles
- Arquitectura de las Herramientas
- Introducción a Apache JMeter
- Pre-requisitos, Instalación, Configuración
- El Plan de Pruebas -> Nuestro Primer Script
- Elementos, Scoping y Orden de Ejecución
- Correlación
- Algunas Buenas Prácticas con JMeter
- Uso de Config Elements
- Data-Driven
- Ejecución en Consola

6. Definiciones
- Performance Testing:
- “Es una práctica que se realiza para determinar cómo un sistema responde en términos de
capacidad de respuesta y estabilidad bajo una cierta carga. También sirve para medir otros
atributos de calidad del sistema como la escalabilidad, la confiabilidad y la utilización de los
recursos de hardware”
- Tiempo de Respuesta
- “Es el tiempo que tarda un sistema entre que se envía una petición y ésta vuelve a su orígen en
forma de respuesta”
- Latencia
- “Es el retardo entre causa y efecto de algún cambio físico en el sistema que se observa”
- Tiempo de Procesamiento
- “Es es el tiempo que insume un sistema en procesar un pedido, sin tener en cuenta el tiempo
que tarda ese pedido en llegar del usuario al sistema y viceversa”
- Throughput
- “Es el volúmen de trabajo neto de un sistema”

7. Entonces
- Tiempo de Respuesta = Latencia + Tiempo de Procesamiento
Hardware Código Arquitectura

8. Práctica
Carga
TiempodeRespuesta
Throughput
Utilización del Recurso

9. Objetivos de las Pruebas de
Performance
- Determinar la disponibilidad (readiness) de un sistema
- Evaluar los criterios de aceptación (transacciones por segundo, búsquedas por minuto,
compras por hora, etc.)
- Comparar las características de performance entre diferentes sistemas y/o
configuraciones
- Identificar los cuellos de botella del sistema
- Asistir en el proceso de mejora de performance de un sistema (tunning)
- Ayudar a identificar los niveles de throughput a nivel sistema
- Como herramienta de testing (JMETER en el CI)

10. ISO/IEC 25010

11. Tipos de Pruebas de Performance
El término “Performance Testing” es abarcativo e incluye uno o más de los siguientes tipos de
pruebas:
- Performance
- Realizar pruebas (generalmente a nivel componente) para determinar la utilización de los
recursos
- Carga (Load)
- Realizar pruebas a nivel componente o sistema para determinar si se cumple con los
requerimientos de performance definidos en la especificación
- Stress
- Realizar pruebas más allá de la carga esperada del sistema para evaluar su comportamiento Su
objetivo es tratar determinar el punto de quiebre (si quiebra)

12. Riesgos
Velocidad
Escalabilidad
Estabilidad
● UX
● Response Time Trending
● SLAs
● Crecimiento de la Demanda
● Planificación de la Capacidad
● Optimización
● Concurrencia
● Confiabilidad
● Disponibilidad
● Recuperabilidad

13. Práctica: Diseñando Escenarios
Issues Performance Load Endurance Capacity Stress Spike
Velocidad
UX
Response Time Trending
SLA
Escalabilidad
Demanda
Planificación de la
Capaciddad
Efficiencia/Optimización
Concurrencia
Estabilidad
Confiabilidad
Disponibilidad
Resiliencia/Recuperabilidad
Degradación

14. Metodología
Identificar el Ambiente
Establecer Criterios de
Aceptación
Diseñar los Escenarios
Implementar las
Pruebas
Ejecutar las Pruebas
Análisis de Resultados
y Reporte
Optimización

15. Metodología: Ambiente de Test

16. Metodología: Aceptación/Diseño

17. Utilización de Herramientas
- Client (e.g. https://gtmetrix.com/) vs. Server
- Herramientas Open Source vs.
- Herramientas Comerciales
- On Premise
- SaaS
- Community

18. Arquitectura

20. Instalación de JMETER
- JAVA 8 (JDK)
- java -version
- Instalación en Ubuntu:
- download: http://jmeter.apache.org/download_jmeter.cgi
- descomprimir
- ejecutar jmeter.sh en $JMETER_HOME/bin
- Plugins
- download: https://jmeter-plugins.org/downloads/all/
- bajar plugins-manager.jar en $JMETER_HOME/ext
- (re)iniciar JMETER

21. JMETER

22. Enter the Test Plan
- LA BASE ESTÁ
- Thread Group
- El alma mater del Script, es el elemento que simula los usuarios concurrentes a
través de la creación de hilos.
- Sampler: HTTP Request Sampler
- Es el quien genera la “muestra”, es decir un request (en este caso HTTP) con la
información requerida para la prueba.
- Listeners: View Results Tree
- Los listener sirven para “escuchar” el muestreo y almacenarlo para monitoreo,
debugging, reporte, etc.

23. Grabando un Escenario
- Concepto de Proxy
- Recorder
- BlazeMeter Recorder
- Template

24. En segunda base...
- Timers
- Sirven para emular los “think times” de los usuarios, de acuerdo al alcance pueden afectar
cada request individualmente o todos los requests.
- Assertions
- Sirven para determinar si una prueba pasa o falla, por ejemplo determinando si la página
web devuelve o no un resultado.
- Pre Procesors
- Se ejecutan antes del sampler (request) para por ejemplo, preparar la data
- Post Procesors:
- Se ejecutan despues del sampler para, por ejemplo, analizar una expresión regular y parsear
un valor en una variable (para su utilización)

25. Variables & Funciones
● User Defined Variables (Constantes)
● User Parameters
● Funciones
● Variables definidas en Lenguajes de Scripting
Sólo se setean en el TestPlan

26. Properties
● System Properties
● Jmeter Properties
○ Custom Properties
● User Properties
Se setean dentro y fuera (en el archivo de Properties) del TestPlan
Sirven para pasar info entre Thread Groups

27. Properties
● Orden:
○ jmeter -> user -> system
● Jmeter Properties -> “Read Only”
○ Usar user.properties para agregar properties
● Funciones: __P, __setProperty, __getProperty

28. Config Elements
- HTTP Request defaults
- HTTP Header Manager
- HTTP Cache Manager
- HTTP Cookie Manager
- HTTP Authorization Manager
- DNS Cache Manager

29. Scoping
- Samplers y Logical Processors son el equivalente de los statements
- Resto de Elementos, su alcance depende de su posición en el Test Plan
★ Usar los Managers (Cookie, Header, etc.) a nivel Test Plan

30. Execution Order
1. Config Elements
2. Pre Processors
3. Timers
4. Samplers
5. Post Processors
6. Assertions
7. Listeners

31. Logging
● Basado en Log4J Framework
○ NONE- Apagado
○ ERROR - Errores Severos, Inesperados, en RT
○ WARN - Uso de APIs deprecadas, ‘casi’ errores, otras situaciones en RT que son
indeseables o inesperadas pero no necesariamente ‘erróneas’
○ INFO - Eventos en RT
○ DEBUG - Información detallada del flujo

32. Correlación
1- Obtener ID Sesión
2- ID = ab8221897ydau
4- Hace algo, mi ID es ab8221897ydau
5 - 200 - OK (Pudiste Hacerloe)
3- Guardá ID
ab8221897ydau

33. Armando un Escenario Complejo
- Thread Group
- Config Element
- Header/Cookie/Cache Manager(s)
- Sampler
- Timer
- Pre Procesor
- Post Procesor
- Listener

34. Algunas Buenas Prácticas
- Uso de Config Elements
- Dan mantenibilidad y flexibilidad a los Scripts
- Para Carga, Apagar Listeners y Ejecutar en Consola (no en GUI)
- Jmeter –n –t ejemplo.jmx –l resultados.xls
- Usando Data Driven Testing
- Uso de CSV Config Element (Ejemplo)
- Si necesito mucha carga, utilizar el modo Distribuido
- http://www.testautomationguru.com/jmeter-distributed-load-testing-using-docker/

35. APÉNDICE A: Protocolo HTTP

36. TCP/IP Stack

37. Header y Footer
HTTP/1.1 200 OK
Date: Sun, 18 Oct 2009 08:56:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Sat, 20 Nov 2004 07:16:26 GMT
ETag: "10000000565a5-2c-3e94b66c2e680"
Accept-Ranges: bytes
Content-Length: 44
Connection: close
Content-Type: text/html
X-Pad: avoid browser bug
<html><body><h1>Bienvenidos a
Argentesting!</h1></body></html>
HEADER
BODY

38. HTTP
CLIENTE SERVIDOR
REQUEST
RESPONSE

39. Verbos y Response Codes
VERBOS:
GET
POST
PUT
DELETE
HEAD
OPTIONS
TRACE
MENSAJES
1xx (Informational): Request received, server is
continuing the process.
2xx (Success): The request was successfully received,
understood, accepted and serviced.
3xx (Redirection): Further action must be taken in order
to complete the request.
4xx (Client Error): The request contains bad syntax or
cannot be understood.
5xx (Server Error): The server failed to fulfill an
apparently valid request.