Automatización de pruebas funcionales

2,736 views
2,580 views

Published on

Transparecencias de la charla sobre automatización de pruebas funcionales dada en Artalde.net el 30/10/2012

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,736
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
70
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Automatización de pruebas funcionales

  1. 1. AUTOMATIZACIÓN DE PRUEBAS FUNCIONALES
  2. 2. VICENÇ GARCÍA ALTÉS• Development Advisor en PlainConcepts• Professional Scrum Developer y Certified Scrum Master• Microsoft Certified Professional vigarcia@plainconcepts.com @vgaltes www.plainconcepts.com geeks.ms/blogs/devnettips
  3. 3. TESTEO FUNCIONALDefinición: – Asegura que el software desarrollado está haciendo para lo que fue concebido, que cumple los requerimientos.No deben ser nuestros únicos tests.
  4. 4. LA PIRÁMIDE INVERTIDA
  5. 5. LA PIRÁMIDE INVERTIDALa base de la pirámide está construida por tests deinterfaz de usuario – Frágiles – Complejos – Lentos
  6. 6. LA PIRÁMIDE INVERTIDA• Mantener muchos tests “end-to-end” es duro: – Tardan en ejecutarse – Pueden necesitar muchos recursos – Hay caminos difíciles de testear – Cuando fallan, no sabemos exactamente donde o porqué lo han hecho – Están más acoplados con el entorno y tienen dependencias externas – Desde un punto de vista de refactorización, no dan la misma sensación de seguridad que los tests unitarios
  7. 7. INVIRTIENDO LA PIRÁMIDE
  8. 8. AUTOMATIZACIÓN• La repetición de los tests (de cualquier tipo) es necesaria ya que elimina regresiones.• Con la automatización eliminamos el desperdicio asociado a la repetición.
  9. 9. AUTOMATIZACIÓN• La automatización es muy difícil – Requiere disciplina • Es muy tentador no escribir tests • Es muy tentador ver los tests como desperdicio • Les tests no son algo intuitivo – Requiere vigilancia • Alguien tiene que observar los resultados en rojo • Alguien tiene que reparar los ‘cristales rotos’ • Alguien tiene que evitar que la ‘tensión’ decline
  10. 10. ¿DÓNDE SON BUENOS LOS TESTS DE UIAUTOMATIZADOS?
  11. 11. Suite de regresión automatizada
  12. 12. Suite de regresión automatizada• Automatizar pruebas manuales que hayan pasado con éxito• Convertir una grabación de Test Manager en Coded UI y añadirle aserciones.
  13. 13. Suite de regresión automatizada• Cuidado! – No tomar como sustituto de otras pruebas – No invertir la pirámide
  14. 14. Pruebas de regresión automatizadas de bugs
  15. 15. Pruebas de regresión automatizadas de bugs• Al resolver un bug se crea una prueba automatizada que se lanza en una build para asegurarse que no vuelve a aparecer• Sobretodo útil en entornos “brownfield”
  16. 16. Pruebas de la GUI
  17. 17. Pruebas de humo automatizadas
  18. 18. Pruebas de humo automatizadas• Una prueba de humo comprueba que unas cuantas interacciones clave con el sistema se hacen bien justo después de un despliegue.• Si se automatizan es mucho más rápido, cómodo y menos propenso a errores
  19. 19. Refactorizando
  20. 20. Refactorizando• Rescribiendo una parte del sistema que se tenga que seguir comportando externamente igual.• Podemos cubrirlo de pruebas de GUI y ponerlas en una build para refactorizar con más seguridad.• No es substituto de pruebas unitarias.• Útil en desarrollo brownfield.
  21. 21. ¿CUANDO NO ES BUENO?
  22. 22. ¿CUANDIO NO ES BUENO?• Para substituir otro tipo de pruebas que no se hacen por pereza o porque son complicadas. – Mejor pensar en como puedo poner pruebas unitarias• Si la GUI está en continuo cambio – Prototipando – Metiendo mucha funcionalidad nueva que afecta a la GUI
  23. 23. PLANIFICAR LA AUTOMATIZACIÓN
  24. 24. Identificación de casos• Los identificaremos marcándo el Automation Status como planned en el MTM.• Los escenarios comunes los pondremos como shared steps en el MTM.• El orden lo marcamos con el campo order.
  25. 25. Prueba de concepto• Hay que asegurarse que los tests seleccionados están soportados por Coded UI• Pueden haber controles personalizados que no lo estén y que hacerlos automatizables sea muy costoso.
  26. 26. DEMO
  27. 27. Recomendaciones• Utilizar múltiples mapas de UI – Cada mapa se puede asociar con una parte lógica de la aplicación – Cada tester puede trabajar en una sección de la aplicación sin interferir en el trabajo de los demás. – Los añadidos a la UI se pueden escalar incrementalmente con efectos mínimos en los otros tests.
  28. 28. Recomendaciones• Extraer las funcionalidades comunes de los mapas UI a librerías comunes.
  29. 29. Recomendaciones• Utilizar sincronización de objetos antes que wait/sleep estáticos – Asegurarse que tenemos puntos de sincronización que esperan que el objeto exista/esté disponible/esté activado/etc antes de realizar una operación crítica • WaitForControlReady(),WaitForControlExist() – Preferir la sincronización anterior antes que Playback.Wait() y antes que Thread.Sleep()
  30. 30. Recomendaciones• Tratamiento de errores – Asegurarse que utilizamos captura de excepciones en todos los métodos de test
  31. 31. Recomendaciones• Logging – Asegurarse que logueamos mensajes importantes – Console.WriteLine y Console.Error.WriteLine • Se redirijen al StandardOutput y al StandardError. • Se recomienda no utilizarlos
  32. 32. Recomendaciones – Trace.WriteLine • Se muestra en la pantalla de Output de VS durante la fase de depuración, con lo que se puede perder entre los otros mensajes que se muestran. • Se recomienda utilizarlo en código de producción, pero no de test. – Debug.WriteLine • Lo mismo que el anterior, pero solo en compilaciones Debug
  33. 33. Recomendaciones – TestContext.WriteLine • Se muestra en una sección a parte en el resultado de los tests. • La desventaja es que tenemos que pasar el TestContext allí donde queramos loguear. • Para los proyectos de test, es la solución preferida.
  34. 34. Recomendaciones• Utilizar scripts de inicio y fin – [TestInitialize] y [TestCleanup] – [ClassInitialize] y [ClassCleanup] – [AssemblyInitialize] y [AssemblyCleanup]
  35. 35. DEMO
  36. 36. Do’s and Don’ts of UI Automation• Do(s) – Cada método grabado tiene que actuar sobre una página, formulario, dialog box, etc. – Utilizar el Coded UI Test Builder siempre que sea posible. – Poner el foco explícitamente en la ventana donde el test va a introducir datos. – Cuando sea posible, limitar cada método grabado a pocas acciones, a poder ser a una.
  37. 37. Do’s and Don’ts of UI Automation – Crear un UIMap para cada modulo de nuestra aplicación e incluso para cada página. – Si estamos creando aserciones crear un método por cada aserción en el fichero UIMap.cs – Capturar screenshots en los fallos. – Dejar la UI en un estado conocido cuando un test ha terminado. – Loguear antes de hacer algo, no después (o ambas)
  38. 38. Do’s and Don’ts of UI Automation – Loguear el origen del mensaje (framework, código de producción, test). – Loguear cada operación válida realizada por el test – Utilizar tests dirigidos por datos siempre que se pueda – Refactorizar siempre que sea posible
  39. 39. Do’s and Don’ts of UI Automation• Don’t(s) – No modificar el fichero UIMap.designer.cs directamente. Los cambios se perderían. – No hacer un sleep después de cada operación de UI – No lanzar la aplicación cada vez que se ejecuta un test porque se gasta mucho tiempo. – No hardcodear strings en los tests. Esto incluye ID’s, rutas, etc.
  40. 40. DEMO
  41. 41. MUCHAS GRACIAS vigarcia@plainconcepts.com @vgaltes www.plainconcepts.com geeks.ms/blogs/devnettips

×