Federico ToledoFederico.Toledo@abstracta.com.uy

@fltoledo

Testing técnico

¿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

Simple1: Ingresa

http://www.monkop.com2: Upload APK

3: Dinos tu emailListo!

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

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.1

Se abre

1.2

Acciones2

Terminar d

e 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 SwitchesWeb

ServersFirewall

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

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

Tie

mp

o R

esp

ues

ta (

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 SwitchesWeb

ServersFirewall

Applications Servers

Bases 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 ToledoFederico.Toledo@abstracta.com.uy

@fltoledo