Descargado 108 veces
Subido porAbstracta
Testing técnico - Automatización en web y mobile para pruebas funcionales y performance
Federico Toledo presenta sobre temas de testing técnico como automatización de pruebas y pruebas de rendimiento. Explica conceptos como casos de prueba, automatización con herramientas como Selenium y GXtest, y diseño de pruebas de rendimiento. También introduce las herramientas Monkop y Open Device Lab para realizar pruebas en diferentes dispositivos de forma automatizada.
Más contenido relacionado
Similar a Testing técnico - Automatización en web y mobile para pruebas funcionales y performance
Testing técnico - Automatización en web y mobile para pruebas funcionales y performance
- 1.
- 2. ¿No puede existirun software perfecto? ¡¡ Testing !!
- 3. Testing ¿aburrido? ¿Por qué? –Tareas repetitivas – No hay desafíos técnicos – Trabajo para el mal programador
- 4. Temario Test execution automation Test design automation MonkopPerformance Testing
- 5.
- 6. Caso de prueba •Un caso de prueba consta de: – conjunto de valores de entrada – precondiciones de ejecución – resultados esperados – poscondiciones de ejecución, – desarrollados con un objetivo particular, por ejemplo: • ejercitar un camino de un programa particular • verificar que se cumple un requisito especifico
- 7. Discusión de “salados” •“Test automation is simply an automatic way of doing what testers were doing before” – Steve Rowe (Tester at Microsoft) • “Test automation means extending the reach of testers” – James Batch (Tester Consultant at Satisfice)
- 8. Testing de Regresión •Verificar que el Software no tenga regresiones • ¿Solo revisar bugs? • Hay quienes dicen que es un chequeo – Michael Bolton http://www.developsense.com/2009/08/testing- vs-checking.html
- 9. Automatización • Adquirir tecnologíapara automatizar procesos manuales • Mejora: – calidad – performance en la producción – rendimiento de los recursos humanos
- 10. ¿Qué es automatizarpruebas? Lograr que los casos de prueba sean corridos por una máquina
- 11. ¿Para qué automatizar? •Aumentar la calidad del producto • Disminuir el Time to Market • Detección temprana de errores • Reducir el costo total de la aplicación • Motivación del equipo • Testear en diferentes plataformas en forma desatendida
- 12. ¿Cómo automatizar? • Sedebe utilizar una herramienta • Algunos conceptos importantes –Record & Playback –Data-Driven Testing –Model-Based Testing istockphoto ®
- 13. Selenium • Record andPlayback • User interface level automation
- 14. Cómo funciona Selenium Tester/ User SUT: System Under Test Manual Test Case Execution
- 15. Como funciona Selenium Functional TestScripts Selenium captures User Interactions Tester / User Executes and reports SUT: System Under Test Manual Test Case Execution This is record and playback!
- 16.
- 17.
- 19. ¿Qué es ? •Herramienta de testing específica para aplicaciones Web GeneXus Model-Based Testing Record & Playback Data-Driven Testing
- 20. ¿Por qué ? •Adaptar rápidamente los casos de prueba a los cambios de la aplicación • Crear casos de prueba de manera sencilla –Enfoque funcional –Data-Driven Testing • Integración con la aplicación GeneXus
- 21. ¿Cómo se logra? GXtestasocia Artefactos de Prueba a la KB Casos de Prueba Ejecutables Capa de Adaptación Casos de Prueba
- 22.
- 23. Casos de Prueba DatapoolsDecisiones InclusiónLogin Comandos Orden de ejecución de las aristas
- 24.
- 25. Resumen • Record andPlayback • Data-driven testing • Model-based testing
- 26.
- 27. Tesis: Enfoque MDApara Generar Pruebas para Sistemas de Información • Universidad Castilla-La Mancha • Beca: Agencia Nacional de Investigación e Innovación • Tutores – Macario Polo (España) – Beatriz Pérez (Uruguay)
- 28. Conclusiones • Model-driven approach •Basado en estándares – UML • UML Data Modeling Profile • UML Testing Profile – Transformaciones Model-to-Model – Transformaciones Model-to-Text • Pruebas funcionales automatizadas y pruebas de performance
- 29. Conclusiones • Especial atenciónen cubrir las estructuras de datos – A partir del modelo de datos se generan casos de prueba para probar el CRUD de las entidades • CRUD = Create, Read, Update, Delete • 80% de las funcionalidades de los sistemas de información son operaciones de este tipo
- 31. Mayor aporte: vínculocon industria • Las técnicas investigadas fueron volcadas a GXtest • GXtest Generator – A partir de la KB de GeneXus genera un conjunto de casos de prueba en GXtest para el CRUD de las entidades
- 32. Casos de pruebagenerados en GXtest
- 33. Resumen • Model driven approaches •Test design generation • Usado en la industria – GXtest Generator
- 34.
- 35. Ing. Fabián Baptista Gerentede Operaciones Presentación Institucional Tuning Apps?
- 36. Tuning (informática) Afinar la configuraciónde hardware y software para optimizar su rendimiento* * Wikipedia
- 37.
- 38.
- 39. Objetivos SIMPLE – Envíatu app, obtén un informe. EXPERTO - Analizar e identificar cuales tareas de Tuning son posibles a realizar sobre la aplicación. EDUCATIVO - Brindar información técnica necesaria para realizar la tarea de Tuning. ESCENCIAL – Ser el complemento (amigo) ideal de toda Software Factory
- 40.
- 41. 24x7 Cross Device Knowledge Expert Análisis360° Simple
- 42. Simple 1: Ingresa http://www.monkop.com 2: UploadAPK 3: Dinos tu email Listo!
- 44.
- 45.
- 46.
- 48. Android Android Device App Under Test Shell Monkop Android Instrumentation Commands/ Services Monkop Agent Android SDK ADB Python Server Monkop Agent Monkop Server Python Server Monkop Server Monko ps Monko ps Monko ps Monkop SaaS Server (Java) Monkop Site AVRO (tpc/ip) AVRO (tpc/ip)
- 49. Pruebas basadas enconocimiento (modelos) • Sin información base: Modelo se crea en base a exploración e ingeniería inversa, pantallas, comportamiento (acciones y transiciones), tráfico de red y texto ayudan a la creación del modelo de la aplicación. • Con información base Datos, código fuente, logs del server y casos de prueba de otros frameworks ayudan a complementar el modelo y la comprensión del sistema.
- 50.
- 51. Resumen • Monkey testingpara mobile • Pruebas sobre distintos dispositivos • Reporte automático • Sugerencias de mejora • Performance, seguridad, funcionalidad
- 52. Open Device Lab’s- Uruguay
- 53.
- 54. Performance • Computer performanceis characterized by the amount of useful work accomplished by a computer system compared to the time and resources used. • Requisito “no funcional” del sistema
- 55. ¿Si no hayperformance? Dependemos de los sistemas para trabajar • Se pierde productividad • Se pierden clientes • Se pierden oportunidades de venta Los sistemas son controlados por personas • Mayor costo de soporte La imagen de la empresa es el sistema que le da a sus usuarios • Costos indirectos • Pérdida de imagen y confianza
- 56. Pruebas de performance Cómoayudamos: – Simular situaciones de carga para conocer el desempeño del sistema Para qué: – Verificar si el sistema soporta la carga esperada – Verificar si se cumplen acuerdos de nivel de servicio (SLA) – Detectar errores u oportunidades de mejora, que solamente son observables ante la concurrencia – Detectar bottle-necks Objetivo: – Asegurar satisfacción de los usuarios
- 57. Tipos de pruebasde performance • Pruebas de carga (load test) • Pruebas de estrés (stress test) • Pruebas de resistencia (endurance test) • Pruebas de escalabilidad • Etc.
- 58.
- 59.
- 60.
- 61.
- 62. Software Load test ¿Cómosimulamos el uso real del sistema? – Manualmente – Usando herramientas
- 66.
- 67.
- 68. Objetivo • Apuntar siemprea mejorar la relación costo / beneficio • Si nos centramos sólo en mejorar la prueba, nos costará muy cara, y los beneficios serán menos redituables • Incluso pueden llegar tan tarde, ¡que no nos sirva para nada!
- 69. EJECUCIÓN • LÍNEA BASE •EJECUCIÓN DE ESCENARIOS • REPORTE DE RESULTADOS IMPLEMENTACIÓN • AUTOMATIZACIÓN • MONITORIZACIÓN DISEÑO •CASOS DE PRUEBA •ESCENARIOS DE CARGA •INFRAESTRUCTURA DE PRUEBAS •INDICADORES DE PERFORMANCE
- 70. Diseño de pruebas Definirobjetivos del proyecto Diseñar casos de prueba Diseñar escenarios de carga Criterios de aceptación Determinar Infraestructura Datos de prueba
- 71. Automatizar Pruebas dePerformance • Algunas opciones de herramientas opensource – OpenSTA (opensta.org) – JMeter (jmeter.apache.org) • Trabajan a nivel de protocolo
- 72. Servidor Web ModellerModeller Usuario Virtual Http- RequestHttp - Responsegrabar 1 Seabre 1.1 Se abre 1.2 Acciones 2 Terminar de grabar 3 3.1 Tenemos el script Gateway (Proxy) Browser Http - Request Http - Response Http - Request Http - Response
- 73. Performance Test Script Dependingon the application 1 line in Selenium is equivalent to 200 lines in OpenSTA
- 74. GXtest • Automatizar casode prueba – Mucho más fácil, nivel de interfaz y no de protocolo – Generar script de OpenSTA o JMeter • Un proyecto de pruebas de performance se puede hacer 10 veces más rápido • Foco en lo importante, menos tiempo automatizando • Se ajustan los cambios más fácil
- 75.
- 76. Performance Testing Methodology •Vázquez, G., Reina, M., Toledo, F., de Uvarow, S., Greisin, E., López, H.: Metodología de Pruebas de Performance. Presented at the JCC (2008). Test Design Automation Execute AnalyzeFixBetween 30% and 50% in automation tasks
- 77. Ejecución – Plande Pruebas • BaseLine – Mejor tiempo posible – Iterativo para tener datos estadísticos • Escenario – Incremental – Comenzar con un 20% de la carga – Escalar hasta llegar al 100% Servidor WebServidor Web Servidor WebServidor Web
- 78. Análisis de métricas •Buscar patrones de comportamiento • Correlaciones entre eventos
- 79.
- 80. ¡Cuidado! • Asegurarse quelos distintos componentes tienen la hora sincronizada lo más preciso posible. • De otro modo se puede dificultar el análisis. • (o llegar a conclusiones erróneas)
- 81. Patrones Nunca supera el25% de CPU Tiempos de respuesta muy malos ¿Por qué no utiliza más recursos si hay? ¿Y si les digo que el CPU tiene 4 núcleos?
- 82. Patrones • Luego demedia hora de ejecución – CPU al 100% • ¿Siempre es un problema de CPU? • La JVM si se queda con poca memoria llega un momento en que el proceso de Garbage Collection consume mucho CPU
- 83. Causas • Los problemasde performance pueden tener distintas causas – La prueba – Lógica – Infraestructura • Solo analizando los resultados y el funcionamiento del sistema (y de la prueba) se puede ver dónde esta la causa
- 84. ¿Qué estamos probando? Basede datos JVM Aplicación Sistema operativo Hardware Servidor de aplicaciones HTTP Aplicación Aplicación
- 85. Errores comunes • Enla base de datos – Bloqueos de tablas – Falta de índices – SQLs ineficientes – Problemas de tamaño de tablas • Falta de depuración / limpieza de datos
- 86. Errores comunes • Enel Web Server – Configuración de máquina virtual (JVM / .Net Framework) – Pool de conexiones • En la lógica de la aplicación – Algoritmos – Zonas de mutua exclusión – Pérdida de memoria (Memory Leaks)
- 87. Errores comunes • Problemasde hardware – Dimensionamiento (Sizing) – Conexiones mal armadas – Un elemento con problemas • Una vez nos dieron un hub en lugar de un switch
- 88. Bitácora • Llevar unabitácora completa de los cambios sobre: – Aplicación • Software de base • Infraestructura – Prueba • Evaluar si se implementan los cambios derivados de la propia prueba durante el proyecto
- 89. Baselines 15/02/08 ESCENARIO 20% 16/02/08 .- se aumentaa 1GB el Heap del NSBT. .- actualización GxClassR. .- eliminación de la transacción 8 (Journal de Movimientos) .- se cambia el hub de las generadoras por un Switch de 100Mb. .- cambios en el tamaño del pool de Conexiones de GeneXus. .- se habilita el caché de GeneXus. .- cambio de Clases en Bantotal para utilizar “select top”. .- se quita el sistema de firmas del ambiente de pruebas. ESCENARIO 50% 20/02/08 ESCENARIO 75% 21/02/08 .- cacheo de tabla de perfiles. .- debug desabilitado. .- Programa GETALERT modificado para no Update permanente. .- en AS400 se asignaron 2GB a una agrupación de memoria que estaba en 1.2GB. .- se aumentaron las CPW de 8.000 a 10.000 en la partición. ESCENARIO 100% 21/02/08 .- Se corrigen problemas detectados en la transacción de Factoring. .- se aumentaron las CPW de 10.000 a 12.000 en la partición. .- se actualizaron las clases sincronizándolas con las de producción ESCENARIO 150% 04/03/08
- 90. Skills del performancetester • Neceisdad de ser – “mid-level everything” – Multi-disciplinario. • Conocimiento de distintas: – Tecnologías – Arquitecturas / protocolos – Herramientas • Generación de carga • Monitorización
- 91. Resumen Generarlacarga Recolectar y Analizar Datos Realizar Correcciones INTERNET ClientesRouters Switches Web Servers Firewall Applications Servers Bases de Datos Servidor WebServidor Web Servidor Web ToolTool Grabar 1 Seabre 1.1 Se abre 1.2 Acciones 2 Terminar de grabar 3 3.1 Tenemos el script GatewayBrowser Http - Request Http - Response Http - Request Http - Response Http - RequestHttp - Response
- 92. http://www.abstracta.com.uy/ http://blog.abstracta.com.uy @gxtest ¡A testear! Testing técnico FedericoToledo Federico.Toledo@abstracta.com.uy @fltoledo