Argentesting 2017 - Performance testing 101 con jmeter
0 recomendaciones1,519 vistas
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.
Argentesting 2017 - Performance testing 101 con jmeter
- 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
- 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
- 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
- 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.