Evento CDA Abstracta - Perú 2015 - Testing de performance y testing automático. Federico Toledo
Descargar como PPTX, PDF1 recomendación870 vistas
El documento presenta un análisis sobre la importancia de las pruebas de automatización y rendimiento en el sector de TI, destacando la necesidad de optimizar tiempos y garantizar calidad. Se menciona la trayectoria de la empresa Abstracta, enfocada en el testing de software en Perú y su expansión en varios países. Además, se discuten diferentes tipos de pruebas de rendimiento y herramientas que ayudan a mejorar la experiencia del usuario y la calidad del software.
Evento CDA Abstracta - Perú 2015 - Testing de performance y testing automático. Federico Toledo
- 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
- 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?
- 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”.
- 29. PageSpeed Insights • Luego nos plantea cómo solucionarlo:
- 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
- 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!
- 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