Testing técnico - Automatización en web y mobile para pruebas funcionales y performance
Upcoming SlideShare
Loading in...5
×
 

Testing técnico - Automatización en web y mobile para pruebas funcionales y performance

on

  • 193 views

Introducción a distintos aspectos de calidad y testing de software, enfocando en ciertos puntos desarrollados en Abstracta: ...

Introducción a distintos aspectos de calidad y testing de software, enfocando en ciertos puntos desarrollados en Abstracta:

- testing automatizado (Selenium, GXtest, JUnit)
- generación de pruebas con model driven approaches usando UML, UTP, ATL (model to model) y Acceleo (Model to Text)
- smart monkey testing (Monkop - monkop.com) para probar automáticamente aplicaciones Android
- pruebas de performance con OpenSTA

De esta forma mostramos cómo estamos volcando la empresa a la investigación en la industria, investigación en la academia, desarrollo de productos y servicios de alto valor agregado.

Statistics

Views

Total Views
193
Views on SlideShare
193
Embed Views
0

Actions

Likes
3
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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 Presentation Transcript

  • Federico Toledo Federico.Toledo@abstracta.com.uy @fltoledo Testing técnico
  • ¿No puede existir un software perfecto? ¡¡ Testing !!
  • Testing ¿aburrido? ¿Por qué? – Tareas repetitivas – No hay desafíos técnicos – Trabajo para el mal programador
  • Temario Test execution automation Test design automation Monkop Performance Testing
  • Test execution automation
  • 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
  • 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)
  • 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
  • Automatización • Adquirir tecnología para automatizar procesos manuales • Mejora: – calidad – performance en la producción – rendimiento de los recursos humanos
  • ¿Qué es automatizar pruebas? Lograr que los casos de prueba sean corridos por una máquina
  • ¿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
  • ¿Cómo automatizar? • Se debe utilizar una herramienta • Algunos conceptos importantes –Record & Playback –Data-Driven Testing –Model-Based Testing istockphoto ®
  • Selenium • Record and Playback • User interface level automation
  • Cómo funciona Selenium Tester / User SUT: System Under Test Manual Test Case Execution
  • Como funciona Selenium Functional Test Scripts Selenium captures User Interactions Tester / User Executes and reports SUT: System Under Test Manual Test Case Execution This is record and playback!
  • Data-drive con Selenium
  • Demo
  • ¿Qué es ? • Herramienta de testing específica para aplicaciones Web GeneXus Model-Based Testing Record & Playback Data-Driven Testing
  • ¿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
  • ¿Cómo se logra? GXtest asocia Artefactos de Prueba a la KB Casos de Prueba Ejecutables Capa de Adaptación Casos de Prueba
  • Ejemplo • Transacción Clientes • Herramientas tradicionales: • GXtest:
  • Casos de Prueba Datapools Decisiones InclusiónLogin Comandos Orden de ejecución de las aristas
  • Manager
  • Resumen • Record and Playback • Data-driven testing • Model-based testing
  • Test design automation
  • Tesis: Enfoque MDA para 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)
  • 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
  • Conclusiones • Especial atención en 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
  • Mayor aporte: vínculo con 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
  • Casos de prueba generados en GXtest
  • Resumen • Model driven approaches • Test design generation • Usado en la industria – GXtest Generator
  • Monkop
  • Ing. Fabián Baptista Gerente de Operaciones Presentación Institucional Tuning Apps?
  • Tuning (informática) Afinar la configuración de hardware y software para optimizar su rendimiento* * Wikipedia
  • World Forecast
  • Smart Devices Jungle
  • Objetivos SIMPLE – Envía tu 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
  • Principales áreas de análisis Performance, Seguridad, Funcionalidad
  • 24x7 Cross Device Knowledge Expert Análisis 360° Simple
  • Simple 1: Ingresa http://www.monkop.com 2: Upload APK 3: Dinos tu email Listo!
  • Reporte de resultado
  • Reporte de resultado
  • Reporte de resultado
  • 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)
  • Pruebas basadas en conocimiento (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.
  • Demo de ejecución
  • Resumen • Monkey testing para mobile • Pruebas sobre distintos dispositivos • Reporte automático • Sugerencias de mejora • Performance, seguridad, funcionalidad
  • Open Device Lab’s - Uruguay
  • Performance Testing
  • Performance • Computer performance is characterized by the amount of useful work accomplished by a computer system compared to the time and resources used. • Requisito “no funcional” del sistema
  • ¿Si no hay performance? 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
  • Pruebas de performance Cómo ayudamos: – 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
  • Tipos de pruebas de performance • Pruebas de carga (load test) • Pruebas de estrés (stress test) • Pruebas de resistencia (endurance test) • Pruebas de escalabilidad • Etc.
  • Load test
  • Stress test
  • Endurance
  • Scalability
  • Software Load test ¿Cómo simulamos el uso real del sistema? – Manualmente – Usando herramientas
  • Ventajas Manual Automático
  • Desventajas Manual Automático
  • Objetivo • Apuntar siempre a 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!
  • 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
  • Diseño de pruebas Definir objetivos del proyecto Diseñar casos de prueba Diseñar escenarios de carga Criterios de aceptación Determinar Infraestructura Datos de prueba
  • Automatizar Pruebas de Performance • Algunas opciones de herramientas opensource – OpenSTA (opensta.org) – JMeter (jmeter.apache.org) • Trabajan a nivel de protocolo
  • 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
  • Performance Test Script Depending on the application 1 line in Selenium is equivalent to 200 lines in OpenSTA
  • GXtest • Automatizar caso de 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
  • Monitorización INTERNET Clientes Routers Switches Web Servers Firewall Applications Servers Bases de Datos
  • 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
  • Ejecución – Plan de 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
  • Análisis de métricas • Buscar patrones de comportamiento • Correlaciones entre eventos
  • Patrones 0 500 1000 1500 2000 2500 3000 3500 4000 4500 15:40:02 15:40:45 15:41:31 15:42:17 15:43:04 15:43:50 15:44:36 15:45:22 15:46:08 15:46:54 15:47:40 15:48:26 15:49:12 15:49:58 15:50:45 15:51:31 15:52:16 15:53:02 15:53:49 15:54:34 15:55:21 15:56:07 15:56:56 15:57:39 15:58:25 15:59:12 15:59:58 16:00:44 16:01:30 16:02:16 16:03:03 16:03:49 16:04:36 16:05:22 16:06:08 16:06:54 16:07:40 16:08:26 16:09:12 16:09:58 TiempoRespuesta(ms)
  • ¡Cuidado! • Asegurarse que los 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)
  • Patrones Nunca supera el 25% 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?
  • Patrones • Luego de media 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
  • Causas • Los problemas de 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
  • ¿Qué estamos probando? Base de datos JVM Aplicación Sistema operativo Hardware Servidor de aplicaciones HTTP Aplicación Aplicación
  • Errores comunes • En la base de datos – Bloqueos de tablas – Falta de índices – SQLs ineficientes – Problemas de tamaño de tablas • Falta de depuración / limpieza de datos
  • Errores comunes • En el 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)
  • Errores comunes • Problemas de hardware – Dimensionamiento (Sizing) – Conexiones mal armadas – Un elemento con problemas • Una vez nos dieron un hub en lugar de un switch
  • Bitácora • Llevar una bitá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
  • Baselines 15/02/08 ESCENARIO 20% 16/02/08 .- se aumenta a 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
  • Skills del performance tester • Neceisdad de ser – “mid-level everything” – Multi-disciplinario. • Conocimiento de distintas: – Tecnologías – Arquitecturas / protocolos – Herramientas • Generación de carga • Monitorización
  • Resumen Generarlacarga Recolectar y Analizar Datos Realizar Correcciones INTERNET Clientes Routers 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
  • http://www.abstracta.com.uy/ http://blog.abstracta.com.uy @gxtest ¡A testear! Testing técnico Federico Toledo Federico.Toledo@abstracta.com.uy @fltoledo