Charla sobre testing de performance y testing automatizado, centrado en las herramientas que nos permiten realizar estas tareas, pero sin dejar de lado la importancia de la metodología para aprovechar el máximo provecho que se le pueden sacar a estas herramientas. Esto fue en el marco del evento organizado por CDA-Perú, en el que se presentó la alianza estratégica entre CDA y Abstracta, a través de la cual se ofrecen servicios especializados de testing automatizado y performance a empresas de Perú.

1. Noviembre 2015, Lima, Perú
TESTING
Automatización y Performance
Herramientas para optimizar tiempos y
garantizar calidad.
PhD. Federico Toledo
federico.toledo@abstracta.com.uy
Twitter: @fltoledo

2. Perú 2010 - 2015
Historia Global y Local
Noviembre 2015

3. ¿Quiénes somos en el Perú y resto de la región?
Fundada en el año 1986 en Argentina y desde el año 2010 en el Perú
Casi 500 profesionales de IT en total, en el Perú más de 60 y creciendo día a día
Más de 9 millones de horas empleadas en la actividad
Más de 50 bancos, compañías e industrias líderes en la región nos eligieron
Oficina en Lima ubicada en el centro financiero de la ciudad
Presencia internacional en seis países:
Argentina – Chile – España – México – Perú - Uruguay
3

4. Nuestra historia
4
Creación de la
empresa
Primera Sede
nacional en Arg
Renovamos la
marca
Primera Software
Factory
Apertura Sede
México
ISO 9001
Certificaciones
Internacionales
Apertura Chile
Apertura Sede
Perú
Apertura
Sede
España
Sede Corporativa
en Bs.As

5. Nuestros Clientes en el área de Desarrollo de SW
5
Servicios Clientes
Desarrollo y
Mantenimiento de
Sistemas
Software Factories

6. Nuestros Clientes en el área de Calidad de SW
6
Servicios Clientes
Testing Funcional,
Regresión
Testing Automatizado,
Stress

7. Una breve presentación
bit.do/librodetesting

8. Community
+270
+180 www.meetup.com/Testing-Uy
www.testing.uy
+100 Charlas, cursos, papers, artículos…
blog.abstracta.com.uy
+5000 visitas
mensuales

9. www.nahual.uy
+15 colaboradores
3 chicos trabajando
+30 formados

10. ¿Por qué trabajas en testing?
¿No conseguiste otra cosa mejor?
Prejuicios del testing:
• Es aburrido
• Es repetitivo
• No tiene desafíos
• Es el trabajo para el
programador nuevo

11. #TestingRocks

12. Hablemos de…
• Performance testing
– Del lado del cliente
– Del lado del servidor
• Pruebas automáticas de regresión
– Para garantizar la calidad

14. Usuarios acostumbrados a usar el celular en todo
momento y a exigir cada vez más velocidad, usabilidad,
etc.
Los usuarios afectan el mercado, comentarios y
calificaciones en GooglePlay o AppStore.

15. Performance
• +60% de los problemas de las apps que fracasan
son de performance.
• Gold Standard era 6s, luego 3s, Google apunta a
1s.
• El usuario espera que en su celular funcione mejor
que en us PC.

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

17. Y si no hay performance,
¿qué pasa?

18. El trabajo equivocado…

20. Las soluciones equivocadas
• ¡¡Más hardware!!

21. Pruebas de performance
Cómo ayudamos:
– Simular situaciones de carga para conocer el desempeño del sistema del lado del
servidor
– Analizar oportunidades de mejora
• Optimizaciones
• Mejoras, cambios, ajustes
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

22. ¿Qué buscamos?
• El objetivo de la ejecución en
gran parte es buscar los
bottlenecks para mejorar el
mejorar el sistema

23. Las dos caras

24. Performance – Client Side
• Webapp
– PageSpeed Insights
developers.google.com/speed/pagespeed/insights
– Webpage Test www.webpagetest.org
– SiteSpeed run.sitespeed.io
– Yslow www.yslow.org
• Mobile Nativa
– Monkop www.monkop.com

25. ¿Qué aplicación probamos?
• Necesito un conejillo de indias
• ¿Quién se anima a prestar su aplicación
para la demo?
• Sitios más visitados en Perú
– Sacando Facebook, Youtube, Google, porno
y otros
• http://elcomercio.pe
• http://www.sunat.gob.pe

26. PageSpeed Insights
Performance y
usabilidad.
Información para
optimización del lado
del cliente:
Web desktop
Mobile
Basado en “best-
practices”.

27. PageSpeed Insights

28. PageSpeed Insights

29. PageSpeed Insights
• Luego nos plantea cómo solucionarlo:

30. Optimizar tráfico

31. Performance – Client Side
• Webapp
– PageSpeed Insights
developers.google.com/speed/pagespeed/insights
– Webpage Test www.webpagetest.org
– SiteSpeed run.sitespeed.io
– Yslow www.yslow.org
• Mobile Nativa
– Monkop www.monkop.com

32. by

33. Monkop

34. Monkop

35. Monkop

36. Explorando la app de FIFA

37. Explorando otras aplicaciones
Encuentro GeneXus Marca Fotocasa La Liga VivaVideo

38. Monkop
Reporte de ejemplo: https://goo.gl/bMf46T

39. Las dos caras

40. ¿Cómo hacerlo?

41. Tipos de pruebas de performance
• Pruebas de carga (load test)
• Pruebas de estrés (stress test)
• Pruebas de resistencia (endurance test)
• Otras
– Pruebas de escalabilidad
– Pruebas de picos

42. Load test

43. Stress test

44. Endurance

45. Scalability

46. Performance – Server Side
¿Cómo simulamos el uso real del sistema?
– Manualmente
– Usando herramientas
• Conceptos importantes
– Simulación de carga
– Concurrencia
– Usuarios virtuales

50. Servidor Web
ModellerModeller
¿Cómo se prepara un
UV?
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

51. BlazeMeter
• https://blazemeter.com
– URL
– Prueba de JMeter
– Prueba de Webdriver (Selenium)

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

53. Herramientas de
Generación de carga
• “La herramienta no hace al tester”
“Enterprise grade load generation tools are designed to look easy in
to look easy in sales demos. Don’t be fooled.”
Scott Barber

54. AUTOMATIZACIÓN DE
PRUEBAS FUNCIONALES

55. Automatizar ejecución de pruebas
Lograr que los casos de prueba sean ejecutados por
una máquina

56. • Aumentar la cobertura de pruebas y calidad del
producto
• Reducir tiempos de ejecución y salida al mercado
• Ejecución en distintos ambientes
• El trabajo queda documentado en los scripts de
prueba
Beneficios

57. • Los resultados quedan registrados y nos sirven
para tomar decisiones
• Detección temprana de errores
• Reducir el costo total de la aplicación
• Apoyo y motivación al equipo manual para pensar
en pruebas alternativas
Beneficios

58. ¿Cómo automatizar?
• Se debe utilizar una herramienta
• Algunos conceptos importantes
–Record & Playback
–Data-Driven Testing
–Page Object
–Model-Based Testing

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

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

61. Como funciona Selenium
Functional
Test Scripts
Selenium captura
las interacciones del
usuario
Tester / User
Ejecuta y reporta
SUT: System Under Test
Manual Test Case
Execution
Esto es record and playback!

62. Data-driven con Selenium

63. • Distintas dimensiones para aprovechar:
Tiempo
Plataformas
Datos
¿Beneficios solo a largo plazo?

64. Framework Xtest
Xtest
GXtest ASPXtest BTtest Selenium …

65. • Automatizar el caos, solo traerá más caos más rápido.
• Las herramientas NO piensan.
– Lo bueno es que siempre ejecutan lo mismo.
– Lo malo es que siempre ejecutan lo mismo.
• Priorizar, seleccionar y diseñar las pruebas pensando
en automatizarlas.
¡Cuidado!

66. ¿Qué formas hay de
automatizar?
• Se puede automatizar en distintos niveles:
– A nivel de código: pruebas unitarias, invocando
invocando directamente métodos de clases del sistema.
– A nivel de Componentes o Servicios: pueden ser a
pueden ser a nivel de interfaces de los controllers, WS,
etc.
– A nivel de Sistema (o End-to-End): desde la interfaz
la interfaz gráfica.

67. ¿Cómo debería ser?
Pirámide de Cohn
Más info:
http://abstracta.us/2015/10/26/best-testing-practices-
for-agile-teams-the-automation-pyramid/

68. ¿Cómo se suele hacer?
• Antipatrón del Cono de
Helado

69. ¿Cómo debería ser?
Casos de prueba
Exploratorio
1 hora
2 horas

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

72. Introducción a las
Pruebas de Sistemas
de Información
http://blog.abstracta.com.uy/

73. ¿Siguen pensando que el
testing es aburrido y sin
desafíos técnicos?
testing es aburrido y sin
desafíos técnicos?

74. PhD. Federico Toledo
federico.toledo@abstracta.com.uy
Twitter: @fltoledo
¡Gracias!
#TestingRocks
http://www.slideshare.net/FedericoToledo