https://argentesting.com/ejecutando-pruebas-de-performance/ Quiero contarles en esta charla del proyecto más asombroso en el que he participado en los 12 años que llevo trabajando en pruebas de performance, que fue para una empresa del Fortune 500, que maneja su propio Cloud, que tiene millones de usuarios y que sus exigencias de tiempos de respuesta son de milisegundos. Además, la forma de trabajo ágil y con entornos de integración continua hacen que el nivel de automatismo vaya más allá de lo imaginable. Pero lo más lindo sobre lo que quiero enfocarme, es que este mecanismo de trabajo permite que cualquiera pueda tener sus pruebas de performance ejecutando todos los días a bajo costo, sin que puedan poner las excusas típicas, ya que esto lo podemos hacer con herramientas open source (no hace falta gastar en herramientas costosas) bien fáciles de usar (no es necesario aprender de una tecnología muy específica para hacerlas), usando una infraestructura mucho menor que la de producción (no hace falta tener un entorno igual al de producción), y con resultados inmediatos (no hace falta esperar meses a tener un resultado de valor).

1. Pruebas de
Performance
todos los días y a bajo
costo
PhD. Federico Toledo
@fltoledo

2. www.abstracta.us/blog/
www.federico-toledo.com

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

4. Prejuicios del testing:
• El enemigo.
• Los que rompen el
sistema.
Ahhh vos sos de los que les
gusta criticar todo…
De los que ponen palos en las
ruedas para no salir en
producción…

5. Prejuicios del
testing:
• Se hace al
final.
• Es opcional.
El testing es eso que va al
final, si hay tiempo…

6. Performance
• Velocidad
• Uso de recursos

7. Source:http://www.miniatur-wunderland.de/
Simulación

8. Simulación
HTTP
HTTP
Server

9. Tres historias
Pruebas todos los días y a bajo costo

11. Waterfall
Etapa I: Etapa Inicial
Etapa II: Análisis de
Requerimientos
Reuniones
Preliminares
Pruebas de
Concepto
Etapa III: Automatización
Etapa IV: Armado de la
Infraestructura Definitiva
Etapa VI: Etapa Final
Definición de
Infraestructura
Definición de
Escenarios
Definición de
Transacciones
Etapa V: Ejecución y Reportes
Preparación para
la Ejecución
Ejecución de
Tests
Armado Reporte
de Prueba
Informe Final
Transferencia de
Conocimiento
PostMortem
Actividadesdecontrol/gerenciamiento
Automatizar Transacciones Revisión de Scripts / Robots
Armado
Propuesta de
Servicio
Validación con
Cliente
Ajustar el
Sistema
Instalación de ambiente y
datos de pruebas

12. Contexto y Objetivos
0
500
1000
1500
2000
2500
2004 2005 2006 2007 2008
Forecast Concurrent Users
Simular escenario de carga esperado.

13. Casos de prueba
13 (web)
Funcionarios
3 (ISO8583)
Cajeros y POS
2 (web services)
Call center
Total: 1500
usuarios

14. Cronograma

15. Criterios de aceptación

16. Infraestructura similar a PROD

17. ¡Todo listo para ejecutar!

18. Resumen de Desafíos
1. Esfuerzo de automatización y
preparación de datos.
2. Exclusividad de uso de ambiente
similar a PROD.
3. No hay equipo. Hay silos.
4. Incertidumbre y sorpresas.

20. Continuous Performance Testing
https://automationnext.files.wordpress.com
https://continuousdelivery.com/
Testing

21. https://www.linkedin.com/pulse/10-questions-ask-our-continuous-delivery-pipeline-anton-weiss/
Delivery Pipeline: Pipes and Filters

22. https://www.voxxed.com/2017/01/pipeline-as-code-with-jenkins-2/
Continuous Integration

23. Objetivo y Contexto
• Jenkins con cientos de Jobs y
decenas de pipelines.
• Ejecución de más de 300
pruebas de performance
semanales.
• Automatizadas por devs.
• Detectar desviaciones de
performance lo antes posible. http://bit.ly/webinarShutterfly

24. Mis tareas
Análisis de degradaciones
Mantenimiento de pruebas
Profiling y ajuste de tests

25. Profiling: Ajustar el cinturón

26. Profiling: Ajustar el cinturón

27. Profiling: Ajustar el cinturón

28. Profiling: Ajustar el cinturón

29. Profiling: Ajustar el cinturón

30. Profiling: Ajustar el cinturón
Criterios de aceptación basados en punto de
quiebre:
• 350 hilos (virtual users)
Assertions:
• < 1% error
• P95 Response Times < 130ms + 10%
• Throughput >= 150 TPS – 10%

31. Pros & Cons
PROS
1. Menos riesgo, menos sorpresas.
2. Feedback temprano y constante.
3. Aprendizaje continuo.
CONS
1. Si no se hace al nivel correcto,
mayor esfuerzo de
automatización.
2. Falacia de la Composición.

32. Resumen de Desafíos
1. Integrar pruebas de distintos devs.
2. Mantenibilidad de un framework enorme: mucha
deuda técnica.
3. Revisar resultados.
4. Equipos, silos, falta de acuerdos,
¿quién es responsable de solucionar problemas?

34. ¿Enfoque ágil en el gobierno?
El manifiesto indica que hay que priorizar:
• Individuos e interacciones
• sobre procesos y herramientas
• Software funcionando
• sobre documentación extensiva
• Colaboración con el cliente
• sobre negociación contractual
• Respuesta ante el cambio
• sobre seguir un plan
• Pliego
• Licitación
• Contrato

35. Desarrollo basado en contrato
Contrato.
.
.
.
6 meses después:
• Deuda técnica.
• Incertidumbre.

36. Pilares ágiles
http://managementplaza.es/blog/los-tres-pilares-de-scrum/
Continuous Delivery

37. Pipeline de inspección
Dev CI Test
Test UAT
Pre-
Prod
Prod
Proveedor
Cliente
Todos los días
Cada entrega
Impulso para la industria

38. https://es.atlassian.com/devops
Cultura DevOps

39. Resumen de Desafíos
1. Adopción de metodologías.
2. Complejidad tecnológica.
3. Relación entre cliente, proveedores,
operaciones, gestión, testing, etc.
4. Confianza:
• Proceso.
• Equipo.
• Producto.

41. Waterfall

42. Agile

43. DevOps

44. www.shutterstock.com
Propiciar:
• Continuous testing
• Continuous learning
• Continuous
communication

45. ¡Gracias!
PhD. Federico Toledo
@fltoledo
Keynote:
Pruebas de Performance
www.abstracta.us
www.federico-toledo.com