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

1. AUTOMATIZACIÓN DE
PRUEBAS
FUNCIONALES

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. TESTEO FUNCIONAL
Definición:
– Asegura que el software desarrollado está haciendo
para lo que fue concebido, que cumple los
requerimientos.
No deben ser nuestros únicos tests.

4. LA PIRÁMIDE INVERTIDA

5. LA PIRÁMIDE INVERTIDA
La base de la pirámide está construida por tests de
interfaz de usuario
– Frágiles
– Complejos
– Lentos

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. INVIRTIENDO LA PIRÁMIDE

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. 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. ¿DÓNDE SON BUENOS LOS TESTS DE UI
AUTOMATIZADOS?

11. Suite de regresión automatizada

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. Suite de regresión automatizada
• Cuidado!
– No tomar como sustituto de otras pruebas
– No invertir la pirámide

14. Pruebas de regresión automatizadas de bugs

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. Pruebas de la GUI

17. Pruebas de humo automatizadas

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

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. ¿CUANDO NO ES BUENO?

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. PLANIFICAR LA AUTOMATIZACIÓN

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

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. Recomendaciones
• Extraer las funcionalidades comunes de los mapas
UI a librerías comunes.

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. Recomendaciones
• Tratamiento de errores
– Asegurarse que utilizamos captura de excepciones en
todos los métodos de test

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. 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. 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. Recomendaciones
• Utilizar scripts de inicio y fin
– [TestInitialize] y [TestCleanup]
– [ClassInitialize] y [ClassCleanup]
– [AssemblyInitialize] y [AssemblyCleanup]

35. DEMO

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

41. MUCHAS GRACIAS
vigarcia@plainconcepts.com
@vgaltes
www.plainconcepts.com
geeks.ms/blogs/devnettips