charla en universidad ort 2014 - testing técnico (automatización, mobile, performance y más)
TRANSCRIPT
¿No puede existir un software perfecto?
suficientemente bueno
¡¡ 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 BaptistaGerente 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
24x7Cross Device
Knowledge ExpertAnálisis 360°
Simple
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
Monkops
Monkops
Monkops
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 baseDatos, 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 ventaLos sistemas son controlados por personas• Mayor costo de soporteLa imagen de la empresa es el sistema que le da a sus usuarios• Costos indirectos• Pérdida de imagen y confianza
Pruebas de performanceCó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
Automatización / robotización
Ventajas
Manual Automático
Simulado
Controlado
Repetible
Real
Sin costos de herramientas
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 proyectoDiseñar casos de pruebaDiseñar escenarios de cargaCriterios de aceptaciónDeterminar InfraestructuraDatos 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
Se
abre
1.1Se abre
1.2
Acciones2
Terminar de grabar3
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
ServersBases 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
Analyze Fix Between 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:4
0:02
15:4
0:45
15:4
1:31
15:4
2:17
15:4
3:04
15:4
3:50
15:4
4:36
15:4
5:22
15:4
6:08
15:4
6:54
15:4
7:40
15:4
8:26
15:4
9:12
15:4
9:58
15:5
0:45
15:5
1:31
15:5
2:16
15:5
3:02
15:5
3:49
15:5
4:34
15:5
5:21
15:5
6:07
15:5
6:56
15:5
7:39
15:5
8:25
15:5
9:12
15:5
9:58
16:0
0:44
16:0
1:30
16:0
2:16
16:0
3:03
16:0
3:49
16:0
4:36
16:0
5:22
16:0
6:08
16:0
6:54
16:0
7:40
16:0
8:26
16:0
9:12
16:0
9:58
Tiem
po R
espu
esta
(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 CPUTiempos 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 datosJVM
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 parautilizar “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 de10.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
Gen
erar
la c
arga
Recolectar y Analizar
Datos
Realizar
Correcciones
INTERNET
Clientes Routers Switches Web Servers Firewall Applications
ServersBases de
Datos
Servidor WebServidor Web
Servidor Web
Tool Tool
1
1.11.2
2
3
3.1
Tenemos el script
GatewayBrowser
Http - Request
Http - Response
Http - Request
Http - Response
http://www.abstracta.com.uy/
http://blog.abstracta.com.uy
@gxtest
¡A testear!Testing técnico
Federico [email protected]
@fltoledo