Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Argentesting 2017 - Performance testing 101 con jmeter

748 views

Published on

Este taller será una introducción a los conceptos de Performance Testing y a la utilización de JMETER para armar planes de pruebas de performance.

Los requerimientos de las máquinas de los asistentes son:

Procesador Intel i3 o Superior con 2GB y 1 GB de espacio Libre.
SO: Linux, MacOs, Windows
JAVA 1.8 Instalado

Expositor: Sebastián Lallana

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Argentesting 2017 - Performance testing 101 con jmeter

  1. 1. Performance Testing 101 con
  2. 2. Sponsor
  3. 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. 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. 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. 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. 7. Entonces - Tiempo de Respuesta = Latencia + Tiempo de Procesamiento Hardware Código Arquitectura
  8. 8. Práctica Carga TiempodeRespuesta Throughput Utilización del Recurso
  9. 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. 10. ISO/IEC 25010
  11. 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. 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. 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. 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. 15. Metodología: Ambiente de Test
  16. 16. Metodología: Aceptación/Diseño
  17. 17. Utilización de Herramientas - Client (e.g. https://gtmetrix.com/) vs. Server - Herramientas Open Source vs. - Herramientas Comerciales - On Premise - SaaS - Community
  18. 18. Arquitectura
  19. 19. 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
  20. 20. JMETER
  21. 21. 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.
  22. 22. Grabando un Escenario - Concepto de Proxy - Recorder - BlazeMeter Recorder - Template
  23. 23. 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)
  24. 24. Variables & Funciones ● User Defined Variables (Constantes) ● User Parameters ● Funciones ● Variables definidas en Lenguajes de Scripting Sólo se setean en el TestPlan
  25. 25. 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
  26. 26. Properties ● Orden: ○ jmeter -> user -> system ● Jmeter Properties -> “Read Only” ○ Usar user.properties para agregar properties ● Funciones: __P, __setProperty, __getProperty
  27. 27. Config Elements - HTTP Request defaults - HTTP Header Manager - HTTP Cache Manager - HTTP Cookie Manager - HTTP Authorization Manager - DNS Cache Manager
  28. 28. 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
  29. 29. Execution Order 1. Config Elements 2. Pre Processors 3. Timers 4. Samplers 5. Post Processors 6. Assertions 7. Listeners
  30. 30. 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
  31. 31. 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
  32. 32. Armando un Escenario Complejo - Thread Group - Config Element - Header/Cookie/Cache Manager(s) - Sampler - Timer - Pre Procesor - Post Procesor - Listener
  33. 33. 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/
  34. 34. APÉNDICE A: Protocolo HTTP
  35. 35. TCP/IP Stack
  36. 36. 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
  37. 37. HTTP CLIENTE SERVIDOR REQUEST RESPONSE
  38. 38. 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.

×