Desafios do Teste de Desempenho. Edgardo Greising PUCRS, Testing Day II Abril 2009

Transcripción

1 Desafios do Teste de Desempenho Edgardo Greising PUCRS, Testing Day II Abril 2009

2 Prueba de Performance Establecer el rendimiento de un sistema Detectar errores solamente observables con concurrencia Verificar si el sistema soporta la carga esperada Determinar cumplimiento de requerimientos (SLA) Asegurar satisfacción de los usuarios Observar los cuellos de botella del sistema Anticiparse a situaciones de Sistema caído

3 Metodología CES Nº

4 #1: Reconocer el contexto Objetivo de la prueba Estado de la aplicación/sistema a probar Cronograma del proyecto de desarrollo/implantación Quién ordenó la prueba? Conocer a los involucrados y sus roles

5 #2: Modelar Basada en una representación de la realidad Modelo adecuado a los objetivos de la prueba No existe prueba exhaustiva Seleccionar las transacciones Representatividad Tiempos de usuario Recopilar información de todos las áreas y SIMPLIFICAR

6 Infraestructura

7 Infraestructura 11 x Transacciones Web 3 x Web Services POS y ATM

8 #3: Aplicación estable Funcionalmente probada Versión congelada Cambios menores pueden implicar re-hacer la automatización Evaluar si se implementan los cambios derivados de la propia prueba durante el proyecto

9 #4: Herramientas Generación de carga Seleccionar la mejor herramienta para cada prueba Mejor incluye Accesible La herramienta no hace al tester Enterprise grade load generation tools are designed to look easy in sales demos. Don t be fooled. --Scott Barber Monitorización Usar las ya existentes Mínima intrusión Niveles

10 Testing Manual? Go! Dificultades al sincronizar Recursos necesarios Personal Computadoras Coordinador Análisis de resultados? Internet/Intranet Tester Repeticiones? System Under Test

11 Generación de carga Monitoreo Analizar SUT performance Control Generar Requests Monitorizar Carga dinámica Logs Controlador Generadoras Analizar Tiempos de Respuesta de VU Verificar Respuesta Analizar confiabilidad

12 #5: Equipo Testing de Performance es multidisciplinario Articulador entre las partes Colaboración es la palabra clave Coordinación Los problemas están allí. Nosotros solamente los hacemos evidentes. Es preferible que aparezcan en la prueba y no en producción. La participación del personal del cliente hace que la prueba tenga valor

13 #6: Datos, Datos, Datos Contar con datos adecuados en cantidad y calidad No subestimar el costo de esta tarea Quién lo hace? Confidencialidad es un problema Cantidad: Volúmenes no existentes. Se deben generar. Tip: usar los propios scripts para ello. Calidad: Tan variados como en la realidad

14 #7: Disponer de Infraestructura Debe ser la misma que se usará en producción Ambiente debe estar aislado Puede no estar disponible para pruebas Otras necesidades Pruebas funcionales Migraciones Dificultades aumentan cuando nos acercamos al Día D

15 #8: Alcance Hasta cuándo testear Metas pueden cambiar en función de los resultados intermedios No perder de vista los objetivos del proyecto Cuidado con el entusiasmo

16 Ejecución y Reportes INCREMENTAR LA CARGA Recolectar y Analizar Datos Realizar Correcciones REPORTAR

17 #9: Reportar Analizar con el equipo los resultados de cada ejecución Reportar resultados, no escribir un tratado Claves: Tiempo y Relevancia Adecuado al interlocutor Más vale gráficos que números, y números que letras Dejar las letras para las conclusiones finales

18 Cuál tiene mejor performance?

19 Cuál tiene mejor performance?

20 #[1]0: Rentabilidad Demostrar que la prueba es rentable Performance Testing es caro, pero más caro es no hacerlo Costo máximo aproximado: 2.5% del costo total del sistema Costos de no hacerlo: Recuperación Baja de productividad Pérdidas directas Imagen, Servicio al cliente

21 Have software bugs or errors resulted in higher costs or or lost revenue to your company? El costo de los BUGS 80% de los costos de desarrollo son por bug fixing [NIST] El costo promedio de un system downtime para aplicaciones críticas es de U$S100,000 por hora [Gartner] Resolver bugs tarde en el ciclo de desarrollo cuesta 80 a 1,000 veces más que hacerlo temprano [Gartner] 35% Yes, both 5% Yes, lost revenue 49% Yes, higher costs 11% No Fuente: NIST, Gartner & Informationweek studies PGA.COM May 2003: System overloaded due to high interest in TOURCast subscription Cause: Insufficient testing and capacity planning. Cost: Embarrassment to PGA tour. Testing mejor y Potential loss of customers & revenue más temprano podría bajar los costos a un tercio

22 #11: Sus preguntas