RENDIMIENTO

AGENDA
1. Concepto
2. Tipos de Prueba
3. Estrategia de Pruebas
4. Herramientas
5. Plan de Pruebas
6. Correlación y Métricas
7. Reportes de Pruebas
8. Jmeter
9. Practica
RENDIMIENTO
CONCEPTO
CONCEPTO

Determinar lo rápido
que realiza una tarea en Velocidad
un sistema en
condiciones particulares
de trabajo. También Tiempo
puede servir para
validar y verificar otros
atributos de la calidad Desempeño

del sistema
CASOS DE AFECTACIÓN
Cuando YouTube sacó al Mercado una versión de su página un 90%
más ligera, ellos vieron un gran incremento de tráfico en áreas con
pobre conectividad como Sur América, África y Siberia.

Walmart vio un aumento de hasta el 2% en tráfico mejorando en 1

segundo el tiempo de carga. Esto dio lugar a un aumento de hasta
el 1% de los ingresos.

Yahoo! incremento el tráfico en 9% por cada 400 ms de mejora en

los tiempos de carga.

Google encontró que con 500ms incrementa la carga de

resultados en un 25%.
 APORTES

 Identificar problemas de rendimiento antes que impacte a los usuarios del negocio

 Medir el tiempo de respuesta de procesamiento que experimentaría el usuario

 Definir el plan de capacidad para el sistema en producción, esto es escalabilidad y
contingencias para mitigar fallas

 Definir estrategias de atención a alta demanda para no afectar la experiencia del usuario

 Definir el tamaño (sizing) de la infraestructura para responder altas demandas

 Hallar el servicio, componente, sistema legacy, componente de red, causante de lentitud en

tiempos de respuesta y/o excesivo consumo de hardware

 Reducir pérdidas económicas con mitigación e identificación de riesgos de manera temprana

 CONCEPTO
Desarrollar conciencia de cómo una latencia o una
indisponibilidad de servicio total puede impactar la
empresa cliente, el negocio, la marca y el cliente como
usuario final.
Tiempo
Desglosar mentalmente las partes que componen el todo
para entender su rol, sus entradas y salidas de información
y el canal de transmisión.
Escuchar y entender que hace el sistema objetivo, CPU, RAM,
DISCO, RED
correlacionarlo a patrones de diseño de arquitectura y sacar
“para que” y “porqués”
Ponerse en lugar de un usuario final, que le molestaría, Experiencia
que lo cansaría, que lo haría abandonar la interfaz o la de usuario
página web?
Ponerse en lugar del gerente de la compañía, cuanto
impacta al negocio si fallase el sistema en producción?
RENDIMIENTO TIPOS
DE PRUEBA
TIPOS DE PRUEBA

 Pruebas de Carga

 Pruebas de Estrés Baseline

 Pruebas de Escalabilidad
Carga +
escalabilidad
 Pruebas Soak
 Pruebas de Volumen
Estrés,
 Pruebas de picos Sostenibilidad

 Pruebas de Red

 Pruebas de Benchmarking
 TIPOS DE PRUEBA

Sesión de
1 2 3 usuario, con 3
pasos o
acciones.
Tiempo de
Sesión
Simultáneos 1 minuto.

Concurrentes
1 2 3
Concurrentes

1 2 3 1 2 3
Usuarios

Concurrentes

1 2 3 1 2 31 2 3
PROGRAMACIÓN
1 2 3 1 2 3 1 2 3 1 2
1 2 3 1 2 3 1 ORIENTADA
2 3 1 A OBJETOS
1 2 3 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3
Tiempo
Tiempo de
Sesión
BASELINE

Es el proceso de la ejecución de un conjunto de pruebas para

capturar datos de métricas de rendimiento con el fin de
evaluar la eficacia de posteriores cambios en el rendimiento
de mejora en el sistema o aplicación.
Las pruebas de baseline permiten tener un marco de
referencia del nivel de rendimiento (tiempos, throughPut ,
consumo) del sistema bajo una carga mínima para luego hacer
benckmarking con cargas más altas de usuario/trabajo, o con
cambios de versión.
PRUEBAS DE CARGA
Consisten en validar los tiempos de respuesta y medir variables de rendimiento del
sistema o aplicativo bajo prueba (SUT) cuando esta sujeto a cargas de trabajo
generadas por cierto volumen de información y/o cierta cantidad de usuarios
concurrentes; durante una franja de horario normal.
PRUEBAS DE ESCALABILIDAD

Las pruebas de escalabilidad permiten validar la capacidad de una aplicación

para manejar cargas de trabajo con altas y bajas fluctuaciones en la cantidad de
usuarios concurrentes y/o procesamiento de datos, sin afectar negativamente o
estar muy alejado del rendimiento (eficiencia a escala) que se obtuvo en
pruebas de carga y baseline.
Puede dar a conocer información sobre como actúa la demanda de recursos y
su lapso de recuperación conforme disminuye la carga.
Se utilizan para estimar el tamaño “sizing” de la plataforma respecto a cuantas
unidades de procesamiento instalar, cuanta RAM asignar y que espacios de
almacenamiento definir, cuantos nodos cloud; de forma tal que se pueda
diseñar un plan de capacidad para atender cargas atípicas sin afectar la
experiencia del usuario
PRUEBAS DE ESCALABILIDAD
PRUEBAS DE ESTRES
Son diseñadas para buscar el punto de quiebre del sistema, donde y cómo
perdió disponibilidad.
También se tiene en cuenta la validación de suficiencia de recursos de
hardware.
PRUEBAS DE SOAK O SOSTENIBILIDAD
También llamadas Endurance test, donde se validan las características de
rendimiento del sistema cuando se somete a una carga de trabajo y/o
volúmenes de carga esperadas en producción por un período prolongado de
tiempo.
Esta prueba permite detectar fugas de memoria, desbordamientos de log y
truncamientos en discos y bases de datos.
PRUEBAS DE VOLUMEN

Consisten en dar a conocer la capacidad del software bajo

prueba para procesar (leer, modificar, replicar, comparar,
multiplicar) bancos o lotes de información (datos planos,
imágenes, objetos) en aplicativos comúnmente en
mainframes, cloud computing, big data y Grid computing;
en una ventana de tiempo determinada o bajo las
condiciones de un plan de trabajo asíncrono y
desatendido.
PRUEBAS DE RENDESVOUZ
El punto de encuentro o “Rendezvous” reune y sostiene N cantidad
de peticiones en cola y las hace esperar durante un definido tiempo,
y una vez cumplido el tiempo se disparan los usuarios fuertemente y
de manera casi precisa sobre el componente, permitiendo conocer la
reacción y esfuerzo ejercido del Sistema a nivel de hardware y
tiempo de respuesta al usuario.
RENDIMIENTO ESTRATEGIA
DE PRUEBAS
ESTRATEGIA DE PRUEBAS

 Pruebas de Aplicaciones Web

 Pruebas de batch en AS400

 Pruebas de Cliente Servidor o Standlone

 Pruebas de Mobile Apps

 PRUEBAS APLICACIONES WEB

El objetivo de prueba más común en aplicaciones Web es conocer la capacidad

del sistema a mantenerse disponible 7/24, sin afectar la experiencia del usuario.
Involucra principalmente la medición del performance en cada capa de la
arquitectura para determinar en cual o cuáles de éstas capas se debe prestar
mayor atención y si es necesario aplicar mejoras por parte del grupo de
desarrollo.
Tecnologías comunes web 2.0
Las aplicaciones RIA (Rich Internet Applications) están construidas con una
variedad de protocolos, frameworks e interfaces que mejoran la experiencia del
usuario, pues éstas fueron concebidas para simplicidad de desarrollo,
compatibilidad con otras sistemas, mantenimiento y actualización, procurando
no afectar los tiempos de respuesta al usuario final.
PRUEBAS APLICACIONES WEB
Tecnologías comunes web 2.0

En etapa de diseño de scripts para simulación de usuarios nos encontraremos con

peticiones PreProcessing (request) aspx, php, xml, Rest, oraforms, AdobeFlash,
Silverlight, Json, Jquery, GWT, entre otros. Y donde el servidor Web nos devolverá
un Response con un postprocessing del Request.
El tema del diseño de script se concentra en este ámbito, <Request and Response>.
Los responses nos devuelven los datos embebidos en el html, y que para dinamismo
funcional del aplicativo el diseñador debe realizar la tarea de capturar las
variables en el response, las cuales se identifican como posibles parámetros para
re-enviar en Request subsiguientes.

Actualmente la mayoría de herramientas comerciales soportan el control de estas

variables dinámicas facilitando el trabajo del diseñador, sin embargo es común
“meter mano” en el diseño y revisar cuales variables no fueron capturadas
(variabilizadas) y hacerlo de manera manual (parsing) para permitir el flujo normal
de parámetros vía GET y vía POST.
DIAGRAMA DE EJECUCION
PRUEBAS AS-400

El objetivo de prueba en arquitecturas mainframe sobre trabajos en batch y por lotes,

es medir la capacidad de procesamiento de volúmenes de información versus la
demanda de CPU.

Al tratarse de máquinas robustas en número de procesadores y memoria, difícilmente

se estresan por insuficiencia de recursos de hardware, sin embargo ha habido casos
donde el poder de CPU toca el umbral debido a poca asignación de procesadores.

El diseño de scripts para simular una transacción no es común en esta arquitectura,

sino que se aplica el trabajo manual generando lotes de archivos planos con
características definidas según la naturaleza del proceso o Job a lanzar.

Los casos de prueba son puramente estratégicos, donde juega como armar los lotes
según las reglas del negocio, simular condiciones de estado en cuentas, franquicias de
tarjetas, afiliados, extractos, bonos, entre otras, que son el tipo de información que
suelen manejar las grandes empresas en sus mainframes.
PRUEBAS AS-400
Que se mide en pruebas de performance para AS400
1. Tiempo de ejecución con 1, 2, 3, 5…..n procesadores asignados
2. Cumplimiento de SLA o criterio de aceptación para finalización de un proceso
3. Tiempo de respuesta con 25% de volumen de carga, con 50%, con 75%....
100…125%
4. Volumen de data procesada por unidad de tiempo con paralelismo y sin
paralelismo

Que herramientas de monitoreo de máquinas se usan

Herramientas propias de IBM, las cuales vienen en caja cuando una compañía
implementa tecnología AS400:
• IBM iDoctor
• IBM iNavigator
• JobWatcher
 PRUEBAS CLIENTE SERVIDOR
Las pruebas de performance en standalone, al igual que en Web, miden los
tiempos de respuesta del sistema y su esfuerzo en requerimiento de hardware.
El diseño de script se hace mediante herramientas de grabación de movimientos en
pantalla ya sea por reconocimiento de objetos [botones, menú contextual, barras,
checkbox, textbox] o mediante coordenadas x,y.

La arquitectura de aplicación es comúnmente un desktop, o una terminal liviana

haciendo peticiones desde módulos cliente hacia el core del lado de servidor.
La medición de los tiempos de respuesta parte desde el clic en el objeto en
pantalla y termina cuando aparece la respuesta del objeto accionado.
Cabe anotar que el tiempo de respuesta en interacciones de objetos cliente
servidor depende también del rendimiento de la máquina cliente, pues
normalmente el software bajo prueba se une con otras tecnologías por ejemplo
Acrobat reader, crystal reports, MS Office.... haciendo que la máquina o terminal
cliente tenga que compartir sus recursos entre las aplicaciones.
PRUEBAS CLIENTE SERVIDOR

Que se mide en pruebas de performance para cliente-servidor

1. Response time en carga de ventanas, menúes, reportes.

2. SLA
3. Capacidad Usuarios concurrentes del lado de servidor
4. TPS (transacciones por segundo)
5. Latencia
6. Archivos planos por segundo
7. CPU, RAM, DISCO, RED, COLA DE PROCESO, PAGINACIÓN, CANAL DE
RED
PRUEBAS DISPOSITIVOS MOVILES

Al igual que pruebas en web applications, las pruebas en app Mobile también se basan
en diseño de scripts a través de protocolo web de dispositivos móviles, ya sea
capturando el tráfico de peticiones y respuestas (intercambio de datos) desde el mismo
celular o Tablet, como también desde emuladores Android, IOS, Windows Phone etc.

Las pruebas de performance en aplicaciones Web y en aplicaciones para dispositivos

móviles se ejecutan casi de la misma manera, es decir que debe existir una
herramienta de capture and replay y debe existir un aplicativo en ambiente de prueba
desplegado y funcionalmente estable. Sin embargo hay 3 puntos clave donde cambia la
estrategia de prueba para mobile:

• Simulación de red para protocolos Wireless

• Grabación directa desde el dispositivo
• El soporte de un amplio rango de dispositivos
TIPOS DE APP

Native applications:
Son las apps codificadas ya sea mediante Objetive C for Ios, Java for
Android y la propia API atada a la tecnologia del dispositivo. (App Atore,
Play Store)
Web applications:
Son las apps construidas con HTML, Javascript, y que puede ser accedidas
desde un browser en el dispositivo móvil. Ejemplo m.Gmail.com,
m.eltiempo.com, m.Facebook.com

Hybrid applications:
Aquí la parte nativa comúnmente se deja en elementos de página como
botones o menu’s contextuales, luego el contenido principal como noticias,
artículos, productos etc se muestra en navegadores embebidos (bajo html,
js). Ejemplo Facebook y Linkedin.
HERRAMIENTAS
HERRAMIENTAS
Cada tipo de prueba requiere de una herramienta para diseño y ejecución y a veces
otra herramienta aparte para monitoreo, sin embargo hay casos donde una sola
herramienta puede desempeñarse para las 3 cosas.
En performance testing hay variedad de herramientas que cubren diseño de
escenarios (scripts), por ende pueden ejecutar las cargas y monitorear
paralelamente los recursos de servidores.
Sin embargo los ambientes de hoy y las restricciones de seguridad y algunas
limitantes de presupuesto hacen que el monitoreo se realice con herramientas
internas del ambiente del cliente.

El diseño de scripts es igual en todas las herramientas, solo basta tener

conocimientos de desarrollo web (saber que significa un POST, GET, .JS, y otros
elementos Web).

Temas como restricciones del lado del cliente, el presupuesto de proyecto, la

tecnología del software a probar y la cantidad de usuarios virtuales a simular
determina la(s) herramienta(s) a utilizar.
HERRAMIENTAS PROTOCOLO HTTP

Tanto si el aplicativo es local, intranet, o Internet, en este tipo de prueba

se suele simular a necesidad del negocio, más de 10 usuarios
concurrentes... hasta 50.000 VU. Por tanto se debe optar por herramientas
de capture and replay a nivel de protocolo HTTP, donde la herramienta
actúa como un “man in the middle” o proxy intermedio entre el browser y
el servidor.

Las herramientas comerciales para este caso suelen manejar

automáticamente el intercambio de proxy en el browser de forma tal que
sea solo con hacer clic en un botón “Record” y digitar la URL del sitio web
para comenzar a grabar el paso a paso de la transacción de negocio.
HERRAMIENTAS PROTOCOLO HTTP
Las Ventajas de herramientas comerciales es que vienen con tecnología para
parametrización de variables de forma dinámica, para reconocer tecnologías
web 2.0 y RIA como código Silverlight, Adobe Flex (AFM), Oracle Forms, Json,
Ajax, HTTPS, Autenticación NTLM y Kerberos, Active Directory y LDAP, como
también reconocer Siebel, SAP, CRM Dynamics.

Las más reconocidas en el mercado y de modalidad comercial son:

Nombre Fabricante
Neoload Neotys
Load Runner HP
SIlk Performer Microfocus (antes Borland)
Wapt Softlogical
Rational Performance IBM
HERRAMIENTAS PROTOCOLO HTTP
Las más reconocidas en el mercado y de modalidad free
son:
Nombre Fabricante/Autor
Jmeter (java) Apache Community
The Grinder (java) Free Software community
Gatling (basado en scala) Gatling Corp
Httperf HP

Nota: Las herramientas free, y de software libre comúnmente no hacen

intercambio de proxy por si solas, y no manejan variables de forma dinámica
sino que el diseñador debe ajustar manualmente los parámetros que se deben
capturar de respuestas del servidor, como tampoco reconocen las tecnologías
RIA, lo que les quita oportunidad para ser utilizadas y requieren más horas de
esfuerzo, lo que eleva el costo del proyecto y riesgo de desfase.
HERRAMIENTAS PROTOCOLO HTTP

Buena práctica:

Procurar tener el controlador de prueba en una máquina A, y configurar para

que las inyecciones de cargas salgan mediante agentes inyectores B,C,D de
forma que el controlador no se estrese al tener que hacer control de
inyección, medición de estadísticas, captura de monitoreo de hardware.

A medida que la herramienta vaya simulando los usuarios virtuales, el analista

puede hacer pruebas paralelamente en un browser real y percibir el
rendimiento que experimentaría el usuario final, además de presenciar bugs
que puedan presentarse a causa de la concurrencia.
HERRAMIENTAS CLIENTE SERVIDOR
Dado que aquí no aplica la grabación por protocolo http, de hecho una aplicación
híbrida (http con cuadros de diálogo Windows) solo puede ser simulada con
herramientas de grabación para desktop GUI.

Este tipo de pruebas son complejas de desarrollar por las siguientes características:

 Por cada usuario virtual a simular debe existir una sesión de Windows / Linux
propia

 Dado que cada UV necesita su propia sesión, se debe incurrir en gastos para
contar con tantas máquinas como usuarios a simular.

 El reconocimiento por objetos y coordenadas no es 100% preciso por lo que el

script o robot podría perder foco en pantalla y estropear el paso a paso
automático.
HERRAMIENTAS CLIENTE SERVIDOR

 Al momento de aplicar temporizadores para capturar el tiempo de

respuesta de cada interacción del aplicativo, suele consumir cpu lo que
podría ser un cuello de botella y estropear las pruebas.

 El costo de licencias de sistema operativo + herramienta de performance

en cada máquina inyectora puede llegar a igualar el costo del servicio de
prestación de prueba de un solo analista contratado al mes.

 Un script diseñado en el computador A, puede que no funcione igual en el

computador B, ya que el reconocimiento de objetos y coordenadas es
sensible a tamaño de pantalla, colores, versión del sistema operativo,
fabricante de tarjeta de video, versión del SUT y hasta el tipo de
navegador.
HERRAMIENTAS CLIENTE SERVIDOR

Buena práctica:

Para grabación de scripts se recomienda hacerlo en una maquina con las

mismas características técnicas en componentes de hardware que las que
tienen los agentes de inyección. Para este caso la mejor estrategia es usar
servidores robustos con 50 sesiones de terminal services para simular a lo
menos 50 usuarios concurrentes por servidor.

La cantidad de servidores depende de la cantidad de usuarios que la

estrategia de prueba determine simular, con base en los requerimientos del
negocio.
HERRAMIENTAS CLIENTE SERVIDOR

Existen pocas herramientas que permitan multiplicar robots para generar

concurrencia, pero las que se listan a continuación ofrecen tanto la
posibilidad de automatizar para pruebas funcionales, como para generar n
cantidad de usuarios [hilos de script, robots] y hacer load testing.

Nombre Fabricante
UFT + Vugen HP
SIlk Performer +SILKTEST (4J, .4Net) Microfocus
Scapa test Platform + Wintask Scapa Tech
HERRAMIENTAS DISPOSITIVOS MOVILES
Las herramientas robustas en el mercado como Neoload, Silk Performer,
Load Runner y Wapt vienen con funcionalidades para capturar tráfico
entre dispositivos móviles y el servidor.

El truco está en seleccionar el escenario más adecuado con base en la

necesidad del caso de prueba y las prestaciones de la herramienta que se
encuentre disponible (sea rentada por el cliente o de propiedad del
proveedor de prueba).

Herramientas free para protocolo http no son una buena alternativa ya

que éstas bien podrían capturar llamados http desde un emulador o
dummy en Windows/Linux pero no tienen la facilidad de simular el script
con canal de red 3G, LTE, Wifi, etc, ni tampoco pueden simular un
browser mobile.
HERRAMIENTAS DISPOSITIVOS MOVILES

Alternativa 1: Usar la nube y el SAAS “Perfecto Mobile”

www.perfectomobile.com Para simular diferentes dispositivos desde
diferentes sitios, y a velocidades diferentes.

Solo es cuestión de contratar el servicio, programar el script y Perfecto se

encarga de adaptarlo a la necesidad del caso de prueba.

Alternativa 2: Usar herramienta tradicional tipo Neoload o SilkPerformer o

Wapt Pro para ejecutar la prueba aprovechando sus funcionalidades de
simular señal de red débil, media, fuerte, señal Wifi, señal 3G, Lte, que se
acercan más a un comportamiento real.
MONITOREO DE RECURSOS
Todas las herramientas de performance vienen con su propio módulo para
capturar métricas de sistema operativo (Disco, Red, CPU, Memoria, Cola de
Procesos, Memoria virtual, Procesos, Jobs, Batch) sin embargo no todas
cuentan con el mismo nivel de profundidad de monitoreo, es decir que no
todas pueden extraer información específica de los contadores de
rendimiento de Apache, de un IIS, de SQL server, de Solaris, etc.
Comúnmente las herramientas más costosas en el mercado vienen con el
reconocimiento de los contadores más importantes de servidor de
aplicaciones y de base de datos.
Es común que el monitoreo desde la herramienta de Performance hacia de
los servidores del ambiente de prueba se vea afectado por restricciones de
seguridad, lo que se propone en estos casos es contar con herramientas
propias de cliente, ya sea manejadas por su personal de TI o por el mismo
analista de prueba con permiso de manipularla y extraer las métricas al
finalizar la ejecución
MONITOREO DE RECURSOS

Neoload y SilkPerformer son herramientas que aparte de ser

automatizadoras de script y generadoras de carga, cuentan con mayor
cobertura de monitoreo, incluso capaces de integrarse con analizadores
de profiling en tiempo real.

Las herramientas free suelen cubrir aspectos básicos como capturar la

cantidad de CPU y RAM consumida en el servidores, sesiones activas y
tráfico en tarjeta de red. Pero no alcanzan a monitorear métricas de
base de datos ni de JVM.
 MONITOREO DE RECURSOS

Las herramientas más comunes y que son comerciales son sólo para
monitoreo y supervisión de rendimiento en servidores, pero son
especializadas en monitoreo profundo:

Nombre Alcance
Spotlight Bases de datos, Sistemas Operativos, Web Servers
Manage Engine Bases de datos, Sistemas Operativos, Web Servers, Application Servers, Profiling
Ruxit Bases de datos, Sistemas Operativos, Web Servers, Application Servers, Profiling
New Relic Bases de datos, Sistemas Operativos, Web Servers, Application Servers, Profiling
App Dynamics Bases de datos, Sistemas Operativos, Web Servers, Application Servers, Profiling
Dynatrace Bases de datos, Sistemas Operativos, Web Servers, Application Servers, Profiling, balanceadore
TIVOLI Bases de datos, Sistemas Operativos, Web Servers, Application Servers, Profiling, para IBM
Willy Bases de datos, Sistemas Operativos, Web Servers, Application Servers, Profiling
Nagios Bases de datos, Sistemas Operativos, Web Servers, Application Servers
Inavigator, JobWatcher AS400
 MONITOREO DE RECURSOS

Las siguientes herramientas free son sólo una alternativa para cuando
no es posible usar las antes mencionadas:

Nombre Alcance
Perfmon.exe Herramienta propia de Windows Servers
NMON Herramienta para monitoreo de servidores AIX de IBM y también para Linux
VisualVM Monitoreo de JVM a nivel de métodos y clases para aplicaciones Java

WARNING: Una prueba de performance sin monitoreo de ninguna clase,

no sirve.
RENDIMIENTO PLAN DE
PRUEBA
PLAN DE PRUEBA

El plan de la prueba de performance debe apoyarse en 3 pilares

fundamentales:

1. Reglas del negocio (Que hace el aplicativo y para quien va dirigido)

2. Criterios de Aceptación (Que quiere el cliente y que espera de la

prueba)
3. Estrategia (Cantidad de analistas, Herramientas, Ubicación de
lanzamientos, set de datos)
PLAN DE PRUEBA
¿Cual es su criterio de aceptación?
¿Cual es la fecha de salida a
producción?
¿El ambiente de prueba estará aislado
solo para performance?
¿Habrá prueba piloto?
¿Cuánto esperan crecer en población
de usuarios o cliente, cada año?
Gerente
de
Proyecto
¿Cual es su criterio de aceptación ?
¿Cuánto es el pool de conexiones a
BD?
¿Hay una data en lo posible similar a un
ambiente de producción ?
¿Cuenta con una herramienta de
monitoreo profundo de motor de base
de datos?
¿Es posible guardar backups de BD
después de cada ejecución para
restauración futura y repetir
ejecuciones?
¿Cuál es su criterio de aceptación?
¿Horario de jornada laboral?
¿Cul es la hora pico?
¿Qué tiempo de respuesta puede
tolerar?
¿Cómo se comportan los clientes o
beneficiarios finales del aplicativo?
¿Cual es su criterio de aceptación?
¿Qué modelo se utiliza para el
desarrollo? Que patrón de diseño?
Usuario ¿Que framework de desarrollo se
utiliza?
¿Qué servidor de aplicación atiende
las peticiones? Hay virtualización?
¿Cómo se hace la conexión a BD?
Jdbc? C3PO?
Arquitecto/ ¿Hay servidores de cacheado?
Desarrollador ¿Es posible deshabilitar llamados a
Google analytics?
YO ¿Cual es su criterio de aceptación ?
¿Es posible probar quitando el https?
¿Es posible conocer el canal de ancho
de banda?
¿Es posible conectar mi herramienta de
monitoreo a sus servidores? Si no, ¿me
pueden brindar monitoreo y logs
después de cada ejecución?
DBA Infraestructura
/DevOps ¿Se cuenta con soporte 7/24?
PLAN DE PRUEBA

 Siempre simular casos de prueba que representen días de jornadas

especiales

 Si una necesidad del cliente es probar de diferentes sitios geográficos, se

debe considerar rentar licencia de herramientas con ambiente cloud
(Neoload, WAPT PRO, SilkPerformer, Blazemeter, Octoperf)
 Siempre probar con suficiente data en base de datos para simular cargas
lo más real posibles

 Nunca suponer

 Si no se puede monitorear la plataforma de servidores, la prueba es

irrelevante
 Comprender que quien toma la decisión de salir o no salir a producción es
el cliente
 PLAN DE PRUEBA - DISEÑO
El diseño de un script es el medio para simular una prueba lo más real
posible, pues éste se convierte en una especie de robot capaz de hacer
peticiones, capturar datos de respuesta en el postProcessing y reutilizar tales
datos en peticiones subsecuentes, independiente del tipo de arquitectura
(web, desktop, Mobile).

Un script se compone de request, responses y pequeñas funciones javascript

propias del diseñador.
En web y mobile, cada request viene armado de un header y un body (vital
saber desarrollo web básico), dentro del body se puede hacer peticiones GET
o POST con datos de formularios, como también se solicita elementos de
página como jpeg, css, etc.

Un browser normalmente pide los datos del request de forma simultánea, ya

el servidor responde a cada petición a la velocidad que pueda, algunos datos
saldrán del servidor en forma paralela, otros saldrían en serie, y en el camino
pueden tener retrasos por cuestiones de señal de red.
 PLAN DE PRUEBA - DISEÑO
Entre el ir y venir de datos va información como IDsessions, tokens, información de
cuentas, de gente, etc. las herramientas de performance obviamente permiten ver la
data, Por tanto el juego está en chequear que pide el browser en el request y
chequear que recibe en el response del servidor, identificado esa información sabremos
que datos son dinámicos (cambian cada vez que se carga una página al navegar y nunca se
repiten en la sesión que transcurre en el momento) y que datos son estáticos.

También podremos ver que hay datos de session que son los identificadores que permiten
navegar con autorización entre cada página.

Las variables de sesión que normalmente se deben enfrentar son:

 Session User (aplica para toda aplicación web, identifica el login del visitante)
 Session carts (carros de compra)
 Token Id (identificadores de visitante en sistemas de seguridad y banco)
 Eventviewer (Vector de datos de formulario POST de aplicaciones asp, aspx, c#, .net)
 Oracle Handlers (Identificadores de tags en aplicativos desarrollados en Oracle forms)
 PLAN DE PRUEBA - DISEÑO

La variabilidad de parámetros:

Se puede conocer como parsing, como correlación de variables de request /

response, y como variabilidad.

Esto consiste en capturar variables de sesión, datos de transacción (cédulas,

factura, consecutivo, fechas, valores xml) del response mediante expresiones
regulares (las herramientas comerciales lo hacen de manera automática) y
encapsularlas en variables de usuario para ser reusadas en requeté
subsecuentes.

Nota> El control de los tiempos de respuesta de las páginas lo hace la

herramienta de manera automática para luego hacer el análisis de estadísticas.
PLAN DE PRUEBA - DISEÑO

{<type "text" name=“user” value“pepe"><type "password value="./3#%2">}

{<name="sessionID" value="./3#%2"> ......</tag> </html>}

Request1(login, solicitud de elementos web)

Response1(sessionID, elementos Web)
RegExpre sessionID => $Mi_sessionID
Reques2(i$Mi_sessionID, otros datos, elementos web)
Response2(data de negocio, elementos Web)
RegExpre datoDinámico => $Mi_dato
Request3($MI_dato, test1, text2, text3, elementos web)
Response3(data de negocio, elementos web)
Reques4($Mi_sessionID, destroy.sesión(), elementos Web)
PLAN DE PRUEBA - DISEÑO
Buenas prácticas para desarrollo de scripts o robots:

 Comprender los códigos http (2xx, 3xx, 4xx, 5xx)

 Saber que hace un Get, que hace un Post, que hace un Querystring
 Saber la importancia de un header y un body
 Saber como trabaja https (ssl) para poder diseñar scripts a URL seguras
 Saber que cada browser es diferente al procesar peticiones y respuestas, como también es
diferente al tratar código javascript
 Entender que es un proxy, una excepción de proxy y un puerto de salida
 Grabar un script al menos dos veces nos dice claramente que datos son constantes y que
datos son dinámicos en diferente sesión
 Parametrizar toda variable que identifiquemos que cambia en cada llamado del request
 Manejar aserciones que validen internamente que el response recibido viene perfecto
 Parametrizar think times que reflejen un comportamiento real de usuario (depende mucho
del tipo de usuario al que va dirigido el aplicativo, y depende también de la transacción que
tenga que hacer)
 PLAN DE PRUEBA - DISEÑO
Buenas prácticas para un diseñar un script lo más independiente y limpio posible

 Hacer un Verify Virtual User, es decir un smoke test al script al menos con 5 usuarios
concurrentes para revisar que cada sesión realizada fluyó sin problema por toda la
transacción, que su inicio y cierre de sesión fueron correctos, lo que garantiza que
no quedaran sesiones abiertas ocupando memoria en servidor a causa de un error
de script y no de aplicativo objeto de prueba.

 Contar con set de datos para Logins de usuario, para llenado de formularios, contar
con archivos poblados en caso de requerirse simular archivos adjuntos

 Evitar tener request de llamados a páginas por fuera del aplicativo a probar (google
analytics, links a facebook, etc)

 Siempre limpiar caché del navegador antes de grabar

PLAN DE PRUEBA - DISEÑO
Buenas prácticas para un diseñar un script lo más independiente y limpio posible

 En este tipo de pruebas, el diseño es grabar un paso a paso por cada ventana de
formulario sin interesarnos en los datos internos de petición y respuesta, pues no es
http, por tanto la forma de capturar valores que vienen en una pantalla o formulario se
hace a través de funciones que la herramienta trae para reconocimiento de texto OCR,
reconocimiento de bitmaps o captura de área X,Y, y llevar el valor capturado o escaneado
a una variable, tarea de la que se ocupa la herramienta de forma automática.

 También se debe tener en cuenta que si el escáner OCR no detecta la cadena que
queremos capturar, hay que recurrir “por la última” a usar captura por coordenada lo
cual es muy impreciso y causa fallos constantemente al momento de ejecutar los scripts.

Los tiempos de respuesta que la herramienta captura se hace con ayuda del programador
del script ya que durante la grabación del paso a paso debe marcar un temporizador que la
herramienta dispone para cronometrar.
PLAN DE PRUEBA - DISEÑO
 RENDIMIENTO
CORRELACION Y
METRICAS
 CORRELACION Y METRICAS
Un script bien diseñado procura incurrir en riesgos de enviar malas peticiones (bad request)
al servidor, como también nos puede ayudar a obtener métricas más acertadas del escenario
simulado. Estas métricas son comúnmente tiempos de respuesta y consumos de hardware
en servidores.

¿Qué debe analizar el performance tester?

 Como se degrada el tiempo de respuesta conforme aumenta la carga de usuarios

 Como se degrada los recursos de hardware en máquinas conforme se aumenta la carga
 En cuanto tiempo se recuperan las máquinas cuando la carga de usuarios o de
transacciones disminuye
 Como se ocupa el canal de red durante la ejecución
 Hasta cuantos usuarios concurrentes soportó el aplicativo y que costo tuvo sobre las
máquinas
 ¿Se cumplieron los critérios de aceptación de cada personaje involucrado em la mesa
técnica?
 ¿Es necesario aplicar retest?
 CORRELACION Y METRICAS - ANALISIS
 Cuando el controlador aumenta el porcentaje de carga de UV para una próxima escala, se
experimenta una burbuja de subida de tiempo de respuesta que tenderá a estabilizarse. Ese
pico de degradación debe excluirse para no afectar el promedio en la estadística.

 En el caso de hardware: SI la CPU sobrepasa su umbral (80% de consumo) es importante

relacionar con la tarjeta de red ya que un cuello de botella en tarjeta de red, puede esforzar
la CPU. Si no es la red, entonces se debe correlacionar CPU y Memoria, si la memoria está
consumida en un 80% constantemente es porque el existe una fuga a nivel de desarrollo y
por ende el garbage collector en afán de liberar memoria, sacrifica CPU para poder
ejecutarse para poder liberar memoria no referenciada.
 Siguiendo con el caso anterior, si la memoria tiene problemas, el daño colateral es el
intercambio a disco y ralentizar el performance.

 Si el aplicativo es lento, pero las máquinas y la red muestran total disposición de recursos
suficientes, quiere decir que hay problemas de arquitectura de software que ameritan ser
analizados mediante profilers y analizadores de código (tarea de desarrollador)
 CORRELACION Y METRICAS - ANALISIS
 A nivel de máquinas: Si el servidor de aplicaciones muestra problemas de
performance en CPU o Red, se debe correlacionar con el servidor que le envía datos,
suele ser el de base de datos y quizás el cuello de botella se formó allí.

 Si el servidor de base aplicaciones no muestra alto consumo de recursos, pero el

aplicativo es lento, se debe revisar como está rindiendo el servidor de la base de datos
y/o sus colaboradores (servidores legay, red de almacenamientos.

 Si los servidores son virtuales y demuestran mal rendimiento se debe escalar a

infraestructura o DevopS para asignar más capacidad desde el host.

 Si se encuentra pérdida de paquetes de red a nivel de protocolo TCP debe

sospecharse de mala calidad del canal, no homologación de velocidades de tarjetas y
concentradores, balanceadores mal afinados, clusterización de servidores en modo
pasivo y activo.
 CORRELACION Y METRICAS - ANALISIS
 Si se está ejecutando pruebas en AS400, analizar performance con 1 Job, con 2
Jobs concurrentes, con 3 Jobs….. Y comparar como se fue degradando el
performance.

 Si se esta ejecutando pruebas sobre Unix, Linux, Solaris, se debe revisar como se
comportan la memoria ram y la memoria virtual, como se degradan cada uno de los
cores de CPU a medida que se incrementan los usuarios concurrentes.

 Si se está ejecutando pruebas en .net sobre Windows en Internet Information

Services, debe analizarse el comportamiento de los workers process (w3wwp.exe)
ya que son el punto más delicado de este tipo de aplicaciones.

 Si se esta ejecutando sobre servidores Weblogic, Webpshere, Apache Tomcat, Jboss,

Glasfish, y Nginx debe analizarce el comportamiento de WebContainers, de Pool de
conexiones y de Hilos o threads en ejecución. Pues comúnmente son los puntos de
mayor fallo por configuraciones y deploys mal realizados.
 CORRELACION Y METRICAS - ANALISIS
 Si se esta analizando servidor SQL server, se recomienda analizar los
siguientes contadores:
 Fill Factor
 DeathLocks
 Buffer cache hit ratio
 Life Expectancy
 Bath Request
 Indexes/sec contra Recompilations/sec

 Si se esta analizando servidor ORACLE , se recomienda analizar los siguientes

contadores:
 Los contadores internos del SGA
 DeathLocks
 Buffer cache hit ratio
 Commit Trnas y Rollback Trans
 Indexes/sec contra Recompilations/sec
RENDIMIENTO REPORTES
DE PRUEBAS
 REPORTES DE PRUEBAS
El análisis de resultados y el reporte de éstos es lo que el cliente paga y por
lo que volverá a solicitar más ejecuciones a corto plazo.

Por tanto un buen reporte de performance debe concentrar la siguiente

información:
1. Conclusiones en primera plana:
Estas conclusiones deben elaborarse de manera que puedan ser correlacionadas por 4
frentes
a- Expectativo del usuario final
b- Expectativa del desarrollador/arquitecto de soluciones
c- Expectativa de personal de infraestructura y base de datos
d- Expectativa por gerente de proyecto y gerente del negocio

En este punto se da a conocer a toda la mesa de trabajo como fue el performance y si

se cumplió con los criterios de aceptación fijados en plan de prueba o si se incumplió y
dejar que el cliente decida como enfrentar la situación.
 REPORTES DE PRUEBAS
2. Dar Recomendaciones para mejorar el rendimiento

3. Detalle de ejecución de resultados:

a- Presentar gráficas de performance en tiempos de respuesta por cada escenario

ejecutado y su esfuerzo en consumo de hardware.

b- Presentar gráficas de tendencias de tiempos de respuesta por cada escenario

ejecutado de tal forma que se pueda visualizar el rendimiento a perspectiva de
cambios en cantidad de usuarios o cambios de versiones en código fuente, o
cambios de versiones en base de datos

c- Presentar gráficas de desviación standard por cada ejecución de transacción y

que los promedios sean calculados con percentile 90.

d- En lo posible propender por detallar donde se encuentra la fuente del mal

rendimiento para que el equipo de desarrollo tarde menos tiempo en corregir.
 REPORTES DE PRUEBAS
4. El público a quien va dirigido el informe es muy visual y querrán ver lo
siguiente:

a- Cuál es la página mas rápida y cual es la más lenta?

b. Cual es la página más pesada a nivel de descarga y renderizado y porqué?

c- Cuantos usuarios virtuales se lograron sostener en ejecución antes que el

tiempo de respuesta se sobrepase al tiempo esperado en el criterio de
aceptación

d- Cual fue el primer servidor que se estresó? Cuantos usuarios virtuales

habían en ese momento?

e- ¿Cuantas transacciones de negocio se realizan por segundo versus la escala

de usuarios?
RENDIMIENTO JMETER
JMETER

Antes de comenzar a utilizar la herramienta para el proceso de

grabación es necesario asegurarse de los siguientes puntos:

 Instalar Java (JDK) – (Si ya tiene instalada una versión de java

1.6 o superior puede omitir este paso)
 Instalar JMeter: http://jmeter.apache.org/download_jmeter.cgi
 Para las pruebas en ATH se utilizó jmeter versión XXXXX con
plugins descargados..

Para iniciar el proceso de grabación es necesario añadir una plantilla

(template) y después seleccionar grabación (Recording)
JMETER
Después en la pestaña
Servidor Proxy HTTP se
ingresara cual es el
proxy que se va a utilizar
por defecto es 8888 pero
el mismo puede ser
cambiado por el de
preferencia.

También en Servidor
Poxy HTTP se
configuran los patrones a
excluir o URLs que no
serán tenidas en cuenta
tales como extensiones
bmp|css|js|gif|ico|jpe?g|p
ng|swf|woff
JMETER
 JMETER

Jmeter va a grabar la petición en la herramienta, y cada una de estas pestañas

serán el insumo de ejecución de las pruebas de rendimiento

Es necesario que el proceso de grabación sea el indicado, ya que si hay una

equivocación por ejemplo en el ingreso del usuario, la falla quedara grabada
también en la herramienta y al momento de ejecutarla esta también quedara activa
en el proceso de ejecución.
JMETER
Grupos de hilo: Configuración la cantidad de
usuarios con los que se va a trabajar
JMETER

Variables: Configuración
los valores dinámicos de
la prueba, por ejemplo
usuario y contraseña
JMETER
EXPRESIONES REGULARES

Nombre de Referencia: Es el nombre dado al parámetro y que después será

usado en la prueba
Expresión Regular: Es el código con el que se puede capturar la variable de
la petición donde la misma se encuentra
Plantilla: La base utilizada para crear el string desde las coincidencias
encontradas.
Coincidencia No.: Indica cual coincidencia tomar. Si ponemos 0 seleccionara
una coincidencia al azar; si ponemos un valor positivo N, seleccionara la
coincidencia nro. N; si ponemos un valor negativo -N, seleccionara todas las
coincidencia posibles.
Valor por Defecto: Si la expresión regular no tiene coincidencias, entonces la
variable de referencia tomara el valor ingresado en esta casilla
JMETER
JMETER
PRUEBAS DISTRIBUIDAS

Ruta C:\....\apache-jmeter-2.13\bin, abrir el archivo jmeter.properties

JMETER

En el fragmento remote_hosts se van a ingresar las IPs de los

equipos que van a servir de agentes distribuidos en las pruebas, el
archivo se guarda y jmeter se reinicia para que los cambios tengan
efecto y se puedan ver las IPs en la herramienta
JMETER

Para que cada agente funcione correctamente en el momento de

lanzar las pruebas es necesario abrir el archivo C:\.....\apache-
jmeter-2.13\bin\jmeter-server.bat con doble clic. Si toda la
configuración es correcta se verá lo siguiente en cada agente
JMETER
JMETER
JMETER
JMETER
RENDIMIENTO e-ICBS
RENDIMIENTO ICBS
Se realizan las consultas pertinentes para contar con un ambiente
de pruebas optimo en la ejecución, se solicita también la limpieza y
truncado de tablas que generen problemas en los datos
RENDIMIENTO ICBS

Cuando el ambiente de pruebas se encuentra listo, se revisa la

configuración de las propiedades de Jmeter para ejecutar la cantidad
de hilos correctos y los diferentes servers en que se ejecutaran
RENDIMIENTO ICBS
Se ejecutan las pruebas en todos los servidores e inmediatamente
se puede evidenciar como las pruebas afectan los servidores
RENDIMIENTO ICBS
Siempre que la prueba se encuentre en marcha se revisan los
reportes de Jmeter para conocer si las peticiones enviadas están
siendo respondidas correctamente
RENDIMIENTO ICBS
También es necesario conocer el resultado de los monitoreos a los
servidores de aplicaciones y bases de datos para dejar evidencia de
la prueba y de que tanto se saturo el servidor en la misma
RENDIMIENTO ICBS