Automatización de pruebas funcionales

AUTOMATIZACIÓN DE PRUEBAS

FUNCIONALES

http://www.plainconcepts.com/

• Development Advisor en PlainConcepts• Professional Scrum Developer y Certified Scrum Master• Microsoft Certified Professional

[email protected]

@vgaltes

www.plainconcepts.com

geeks.ms/blogs/devnettips

VICENÇ GARCÍA ALTÉS

mailto:[email protected]


Definición:– Asegura que el software desarrollado está haciendo

para lo que fue concebido, que cumple los requerimientos.

No deben ser nuestros únicos tests.

TESTEO FUNCIONAL

LA PIRÁMIDE INVERTIDA

La base de la pirámide está construida por tests de interfaz de usuario– Frágiles– Complejos– Lentos


• 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


INVIRTIENDO LA PIRÁMIDE

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

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

AUTOMATIZACIÓN

¿DÓNDE SON BUENOS LOS TESTS DE UI AUTOMATIZADOS?

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.


• Cuidado!– No tomar como sustituto de otras pruebas– No invertir la pirámide


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”

Pruebas de regresión automatizadas de bugs

Pruebas de la GUI

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

Pruebas de humo automatizadas

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.

Refactorizando

¿CUANDO 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

¿CUANDIO NO ES BUENO?

PLANIFICAR LA AUTOMATIZACIÓN

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

Identificación de casos

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

Prueba de concepto

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

Recomendaciones

• Extraer las funcionalidades comunes de los mapas UI a librerías comunes.

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()

Recomendaciones

• Tratamiento de errores– Asegurarse que utilizamos captura de excepciones en

todos los métodos de test

Recomendaciones

• Logging– Asegurarse que logueamos mensajes importantes– Console.WriteLine y Console.Error.WriteLine• Se redirijen al StandardOutput y al StandardError.• Se recomienda no utilizarlos

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

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.

Recomendaciones

• Utilizar scripts de inicio y fin– [TestInitialize] y [TestCleanup]– [ClassInitialize] y [ClassCleanup]– [AssemblyInitialize] y [AssemblyCleanup]

Recomendaciones

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

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)


– 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


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


[email protected]

@vgaltes

www.plainconcepts.com

geeks.ms/blogs/devnettips

MUCHAS GRACIAS

mailto:[email protected]


Automatización de pruebas funcionales

Technology

Transcript of Automatización de pruebas funcionales