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.

1. Federico Toledo
Federico.Toledo@abstracta.com.uy
@fltoledo
Testing técnico

2. ¿No puede existir un
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
Monkop Performance
Testing

5. Test execution
automation

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ía para automatizar procesos
manuales
• Mejora:
– calidad
– performance en la producción
– rendimiento de los recursos humanos

10. ¿Qué es automatizar pruebas?
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?
• Se debe utilizar una herramienta
• Algunos conceptos importantes
–Record & Playback
–Data-Driven Testing
–Model-Based Testing
istockphoto ®

13. Selenium
• Record and Playback
• User interface level automation

14. Cómo funciona Selenium
Tester / User
SUT: System Under Test
Manual Test Case
Execution

15. 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!

16. Data-drive con Selenium

17. Demo

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?
GXtest asocia Artefactos de Prueba a la KB
Casos de Prueba Ejecutables
Capa de Adaptación
Casos de Prueba

22. Ejemplo
• Transacción
Clientes
• Herramientas
tradicionales:
• GXtest:

23. Casos de Prueba
Datapools Decisiones
InclusiónLogin
Comandos
Orden de ejecución
de las aristas

24. Manager

25. Resumen
• Record and Playback
• Data-driven testing
• Model-based testing

26. Test design
automation

27. 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)

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

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

32. Casos de prueba generados en GXtest

33. Resumen
• Model driven
approaches
• Test design
generation
• Usado en la
industria
– GXtest Generator

34. Monkop

35. Ing. Fabián Baptista
Gerente de Operaciones
Presentación Institucional
Tuning Apps?

36. Tuning
(informática)
Afinar la configuración de hardware y software
para optimizar su rendimiento*
* Wikipedia

37. World Forecast

38. Smart Devices Jungle

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

40. Principales áreas
de análisis
Performance,
Seguridad,
Funcionalidad

41. 24x7
Cross Device
Knowledge Expert
Análisis 360°
Simple

42. Simple
1: Ingresa
http://www.monkop.com
2: Upload APK
3: Dinos tu email
Listo!

44. Reporte de resultado

45. Reporte de resultado

46. Reporte de resultado

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

50. Demo de ejecución

51. Resumen
• Monkey testing para mobile
• Pruebas sobre distintos dispositivos
• Reporte automático
• Sugerencias de mejora
• Performance, seguridad, funcionalidad

52. Open Device Lab’s - Uruguay

53. Performance
Testing

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

55. ¿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

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

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

58. Load test

59. Stress test

60. Endurance

61. Scalability

62. Software Load test
¿Cómo simulamos el uso real del sistema?
– Manualmente
– Usando herramientas

66. Ventajas
Manual Automático

67. Desventajas
Manual Automático

68. 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!

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
Definir objetivos del proyecto
Diseñar casos de prueba
Diseñar escenarios de carga
Criterios de aceptación
Determinar Infraestructura
Datos de prueba

71. Automatizar Pruebas de Performance
• 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
Depending on the
application
1 line in Selenium is
equivalent to 200
lines in OpenSTA

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

75. Monitorización
INTERNET
Clientes Routers Switches
Web
Servers
Firewall
Applications
Servers
Bases de
Datos

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

78. Análisis de métricas
• Buscar patrones de comportamiento
• Correlaciones entre eventos

79. 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)

80. ¡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)

81. 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?

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

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

84. ¿Qué estamos probando?
Base de datos
JVM
Aplicación
Sistema operativo
Hardware
Servidor de aplicaciones
HTTP
Aplicación
Aplicación

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

86. 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)

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

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

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

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

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

92. http://www.abstracta.com.uy/
http://blog.abstracta.com.uy
@gxtest
¡A testear!
Testing técnico
Federico Toledo
Federico.Toledo@abstracta.com.uy
@fltoledo