Está en la página 1de 39

Performance

Testing 101 con


Sponsor
Acerca de Mi

Fiel Esposo y Padre de 2


Eterno Inconformista
Adems:
Pasatiempo: Me encanta cocinar (y ni les digo comer)
Libro Preferido: Dune - Frank Hertzberg
Pelcula Preferida: Star Wars - El Imperio Contraataca
Producto Preferido: Amazon.com
Ingeniero en Sistemas UTN FRBA
20+ Aos Experiencia en IT/Desarrollo de Software
Gerente de Quality Engineering @AVANTRIP.com
Acerca de Nosotros (La Clase)

- Conversar con el compaero de al lado e intercambiarse estas 4 preguntas:


- Nombre
- Pasatiempo
- Libro / Pelcula Favorit@
- Producto Preferido (y por qu?)
Agenda
- Conceptos de Performance Testing:
- Definiciones
- Objetivos, Riesgos, Metodologa y Tipos de Pruebas de Performance
- Herramientas Disponibles
- Arquitectura de las Herramientas
- Introduccin a Apache JMeter
- Pre-requisitos, Instalacin, Configuracin
- El Plan de Pruebas -> Nuestro Primer Script
- Elementos, Scoping y Orden de Ejecucin
- Correlacin
- Algunas Buenas Prcticas con JMeter
- Uso de Config Elements
- Data-Driven
- Ejecucin en Consola
Definiciones
- Performance Testing:
- Es una prctica que se realiza para determinar cmo un sistema responde en trminos de
capacidad de respuesta y estabilidad bajo una cierta carga. Tambin sirve para medir otros
atributos de calidad del sistema como la escalabilidad, la confiabilidad y la utilizacin de los
recursos de hardware
- Tiempo de Respuesta
- Es el tiempo que tarda un sistema entre que se enva una peticin y sta vuelve a su orgen en
forma de respuesta
- Latencia
- Es el retardo entre causa y efecto de algn cambio fsico 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 volmen de trabajo neto de un sistema
Entonces
- Tiempo de Respuesta = Latencia + Tiempo de Procesamiento

Hardware Cdigo Arquitectura


Tiempo de Respuesta Prctica Utilizacin del Recurso

Throughput
Carga
Objetivos de las Pruebas de
Performance
- Determinar la disponibilidad (readiness) de un sistema
- Evaluar los criterios de aceptacin (transacciones por segundo, bsquedas por minuto,
compras por hora, etc.)
- Comparar las caractersticas 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)
ISO/IEC 25010
Tipos de Pruebas de Performance

El trmino Performance Testing es abarcativo e incluye uno o ms de los siguientes tipos de


pruebas:

- Performance
- Realizar pruebas (generalmente a nivel componente) para determinar la utilizacin 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 especificacin
- Stress
- Realizar pruebas ms all de la carga esperada del sistema para evaluar su comportamiento Su
objetivo es tratar determinar el punto de quiebre (si quiebra)
Riesgos
UX
Response Time Trending
Velocidad
SLAs

Crecimiento de la Demanda
Escalabilidad Planificacin de la Capacidad
Optimizacin
Concurrencia

Confiabilidad
Disponibilidad
Estabilidad Recuperabilidad
Prctica: Diseando Escenarios
Issues Performance Load Endurance Capacity Stress Spike
UX
Velocidad Response Time Trending
SLA

Demanda
Planificacin de la
Escalabilidad Capaciddad
Efficiencia/Optimizacin
Concurrencia

Confiabilidad
Disponibilidad
Estabilidad
Resiliencia/Recuperabilidad
Degradacin
Metodologa

Identificar el Ambiente
Establecer Criterios de
Aceptacin

Disear los Escenarios

Implementar las
Pruebas
Ejecutar las Pruebas

Anlisis de Resultados
Optimizacin
y Reporte
Metodologa: Ambiente de Test
Metodologa: Aceptacin/Diseo
Utilizacin de Herramientas
- Client (e.g. https://gtmetrix.com/) vs. Server
- Herramientas Open Source vs.
- Herramientas Comerciales
- On Premise
- SaaS
- Community
Arquitectura
Instalacin de JMETER

- JAVA 8 (JDK)
- java -version
- Instalacin 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
JMETER
Enter the Test Plan
- LA BASE EST
- Thread Group
- El alma mater del Script, es el elemento que simula los usuarios concurrentes a
travs de la creacin de hilos.
- Sampler: HTTP Request Sampler
- Es el quien genera la muestra, es decir un request (en este caso HTTP) con la
informacin requerida para la prueba.
- Listeners: View Results Tree
- Los listener sirven para escuchar el muestreo y almacenarlo para monitoreo,
debugging, reporte, etc.
Grabando un Escenario

- Concepto de Proxy
- Recorder
- BlazeMeter Recorder
- Template
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 pgina
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 expresin regular y parsear
un valor en una variable (para su utilizacin)
Variables & Funciones
User Defined Variables (Constantes)
User Parameters
Funciones
Variables definidas en Lenguajes de Scripting

Slo se setean en el TestPlan


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
Properties
Orden:
jmeter -> user -> system
Jmeter Properties -> Read Only
Usar user.properties para agregar properties
Funciones: __P, __setProperty, __getProperty
Config Elements
- HTTP Request defaults
- HTTP Header Manager
- HTTP Cache Manager
- HTTP Cookie Manager
- HTTP Authorization Manager
- DNS Cache Manager
Scoping
- Samplers y Logical Processors son el equivalente de los statements
- Resto de Elementos, su alcance depende de su posicin en el Test Plan

Usar los Managers (Cookie, Header, etc.) a nivel Test Plan


Execution Order
1. Config Elements
2. Pre Processors
3. Timers
4. Samplers
5. Post Processors
6. Assertions
7. Listeners
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 errneas
INFO - Eventos en RT
DEBUG - Informacin detallada del flujo
Correlacin

1- Obtener ID Sesin

2- ID = ab8221897ydau

3- Guard ID
4- Hace algo, mi ID es ab8221897ydau
ab8221897ydau

5 - 200 - OK (Pudiste Hacerloe)


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

- Listener
Algunas Buenas Prcticas
- 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/
APNDICE A: Protocolo HTTP
TCP/IP Stack
Header y Footer
HTTP/1.1 200 OK
Date: Sun, 18 Oct 2009 08:56:53 GMT
Server: Apache/2.2.14 (Win32)
HEADER 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

BODY
<html><body><h1>Bienvenidos a
Argentesting!</h1></body></html>
HTTP
CLIENTE SERVIDOR

REQUEST

RESPONSE
Verbos y Response Codes
VERBOS: MENSAJES
GET 1xx (Informational): Request received, server is
POST continuing the process.

PUT 2xx (Success): The request was successfully received,


understood, accepted and serviced.
DELETE
3xx (Redirection): Further action must be taken in order
HEAD
to complete the request.
OPTIONS
4xx (Client Error): The request contains bad syntax or
TRACE cannot be understood.
5xx (Server Error): The server failed to fulfill an
apparently valid request.

También podría gustarte