Problemas de rendimiento de optimización de matriz de prueba de MBUnit en pruebas de interfaz de usuario automatizadas

Question

Actualmente estamos usando MBUnit tanto para pruebas unitarias como para pruebas de IU.Para las pruebas de IU, el costo de configuración de los ejes de la matriz de prueba es bastante alto (inicio de sesión, instancia del navegador, navegar a la página, etc.).Para evitar configurarlos para cada caso de prueba, confiamos en parte en AssemblyFixture para administrar algunos de ellos.

Sin embargo, debido a que no es posible filtrar ciertos casos en los que no son aplicables a una combinación determinada, no es posible que realmente utilicemos dicha optimización.Así que actualmente estamos haciendo algunas de las configuraciones por caso de prueba, terriblemente ineficaces.

Podríamos colocar declaraciones if dentro del código de prueba para verificar las combinaciones correctas, pero tampoco deseamos eso.Contamina el código de prueba.

¿Cómo hacen estas optimizaciones, chicos?o gestión de matriz de prueba?¿Existe una mejor práctica en otro marco de prueba?

Answer 1

Hasta hace poco, siempre había pensado en la automatización de la interfaz de usuario como una prueba de caja negra en la que mis pruebas de la interfaz de usuario se comparan con una aplicación o un sitio web completamente independiente. Como resultado, las pruebas se ejecutan bajo la restricción de la ejecución normal y están sujetas a una serie de problemas de sobrecarga del entorno.

Recientemente adopté la noción de pruebas de IU "superficiales" y "profundas" donde cada conjunto de pruebas se ejecuta bajo una configuración optimizada para aliviar las diferencias ambientales y acelerar las cosas. Por ejemplo, el controlador de inicio de sesión se intercambia con un mecanismo que evita la sobrecarga de inicio de sesión de OAuth y está codificado con nombres de usuario fijos. El catálogo de productos omite la búsqueda en la base de datos y está codificado con algunos elementos fijos. El backend de comercio electrónico se intercambia para realizar operaciones rápidas que aceptan / rechazan transacciones según la tarjeta de crédito y el monto.

En una configuración "superficial", puedo realizar pruebas "profundas" contra la lógica de la interfaz de usuario. Cuando cambio a una configuración "profunda", se asemeja a la producción y puedo realizar pruebas "superficiales" de componentes totalmente integrados, como inicio de sesión, catálogo de productos, búsqueda, etc.

Se requiere una combinación de estrategias de prueba.

Answer 2

Puede ser el ui-test-automation-best-prácticas es útil para usted.Tiene algunos ejemplos de cómo mejorar el rendimiento de la automatización de las pruebas de interfaz de usuario minimizando los inicios de sesión y los cambios de contexto.