Pregunta

Estamos desarrollando una aplicación bastante grande basada en WPF y nos gustaría incluir algunas pruebas de IU automatizadas en nuestro conjunto de pruebas (que ya contiene una serie de pruebas unitarias).

El UI Automation Framework de Microsoft en parte parece un ajuste perfecto para iniciar e interactuar programáticamente con la aplicación en una configuración de prueba. Sin embargo, me costó encontrar referencias sólidas para muestras y experiencias con la tecnología, los artículos y pequeñas muestras disponibles en MSDN no son suficientes para convencerme de que es una opción sólida.

Entonces, ¿alguien tiene experiencias en el mundo real usando el Marco de automatización de la interfaz de usuario en su conjunto de pruebas? ¿Cuáles son las advertencias y las trampas? Cualquier práctica recomendada cuando se escriben scripts de prueba, ¿puede "grabar y reproducir"? a un formato programable, ¿cuánto debería facilitar la prueba desde la aplicación, cómo la incorporó en la compilación automática? ¿Deberíamos mirar en otra dirección que no sea el marco de automatización de la interfaz de usuario?

Siéntase libre de publicar sus experiencias aquí o enlace a algunas buenas referencias que podría haber perdido

¿Fue útil?

Solución

Donde trabajo acabamos de comenzar a evaluar algunas herramientas de prueba para nuestro sistema. Encontramos una herramienta llamada white , que usa el marco de automatización de la interfaz de usuario. Tenga en cuenta que el blanco también tiene una función de registro, aunque creo que tiene problemas y todavía se está desarrollando.

Lo que intentamos hacer fue configurarlos para que parecieran pruebas unitarias, es decir, [TestFixture] [Test] etc. entonces pudimos ejecutarlos a través de nunit al mismo tiempo que las pruebas unitarias.

Hemos descubierto que puede ser difícil acceder a algunos de los componentes dentro de su ventana, pero no hemos tenido muchas oportunidades de investigar por qué.

Si no le importa pagar por el software, le recomendaría TestComplete .

Otros consejos

Estoy en medio de la automatización de la interfaz de usuario de una aplicación WPF en el trabajo. Estoy usando White y IronRuby y funciona muy bien. He escrito cómo lo hice aquí: http://www.natontesting.com/2010/02/17/how-to-test-a-wpf-app-using-ironruby-and-white/

Inicialmente fuimos con blanco, y luego nos alejamos de él. Intenta ser genérico y abstracto sobre la API Win32, Winforms, aplicaciones Java y la API de automatización MS UI. La API de automatización de MS UI también está tratando de ser genérica y abstracta sobre la API win32 y winforms y WPF, por lo que terminas en un "mínimo común denominador de bajo común común denominador" escenario.

El resultado de esto fue que la API de búsqueda de elementos blancos simplemente no era lo suficientemente flexible como para encontrar varios elementos de la interfaz de usuario que necesitábamos encontrar, y no exponía lo suficiente de los elementos subyacentes del marco de automatización de la interfaz de usuario para que pudiéramos hacer nada útil con él.

Terminamos yendo con un tipo de marco de cosecha propia; Utilizamos el marco de MS UIAutomation directamente, pero tenemos métodos de extensión y clases auxiliares para lidiar con los escenarios que no aborda. (Entrada de teclado y mouse, principalmente).

Nota: nuestros scripts de prueba y el marco de trabajo local están utilizando IronRuby. La capacidad de Ruby para agregar métodos a las clases existentes y su sintaxis flexible (combinada con method_missing) son increíbles para este tipo de cosas.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top