Prueba automatizada de GUI

Question

Esta pregunta no se trata de pruebas unitarias. Y es para un producto de escritorio.

Se trata de probar la interfaz gráfica de usuario y probar que se ingresen las cosas correctas en el cuadro de texto de la derecha en el momento correcto.

Una empresa en la que solía trabajar WinRunner (departamento diferente, así que no sé mucho más que eso), pero que ahora HP ha cerrado, pero no les importa si se queda con HP o ve a otro lado No puedes leer sobre el producto hasta que te hayas registrado, lo cual es molesto.

La herramienta tiene que trabajar con MFC (no negociable) y la herramienta ideal también ...

• ser automatizado.
• scriptable.
• funcionan con diferentes resoluciones de pantalla automáticamente.
• ser capaz de 'espiar' en cuadros de texto estáticos individuales, etc.
• lo suficientemente intuitivo para que los no programadores puedan crear los scripts.
• tienen herramientas de informes, incluido el correo electrónico de usuarios individuales.

¿Qué hacen otros usuarios de SO para realizar pruebas automatizadas de GUI?

Answer 1

Usamos el SAFS framework para Rational Robot (RRAFS).También hay implementaciones de SAFS para WinRunner (WRAFS) y parece que tienen una nueva implementación de "Prueba basada en imágenes", con la que no estoy familiarizado.

Este marco hace un buen trabajo al separar la implementación de la interfaz de usuario de los scripts de prueba. Probé cuatro lanzamientos de una aplicación web desarrollada por dos equipos diferentes (un equipo que usa ASP clásico y otro que usa ASP.NET) y solo tuve que cambiar el mapa de aplicaciones de mis objetos de interfaz de usuario, las pruebas en sí mismas no necesitaban cambio.

Dicho esto, el lenguaje de la estructura es engorroso y le lleva tiempo acostumbrarse. No es muy robusto, en términos de construcciones de lenguaje, pero con un poco de esfuerzo puede hacer lo que necesite. Es algo así como la "programación" en el lenguaje de lotes de Windows, pero para las pruebas;)

Para hacer frente a sus necesidades individuales arriba:

1) La herramienta tiene que trabajar con MFC (no negociables). El marco SAFS utiliza una herramienta de "grabación de reproducción" de terceros para conducir las pruebas, como Rational Robot o Mercury WinRunner. Si esa herramienta puede interactuar con aplicaciones MFC, entonces el marco puede. No sé cómo la implementación de "Pruebas basadas en imágenes" conduce las pruebas, pero supongo que también puede funcionar con MFC.

2) ser automatizado. El marco SAFS se integra con el STAF framework, que le permitirá automatizar la ejecución de sus pruebas. Tengo una prueba de concepto de prueba que usa STAF para iniciar una imagen de máquina virtual desde un grupo de imágenes, instalar la aplicación bajo prueba, ejecutar la prueba RRAFS y colocar los resultados en un servidor web para que otros puedan acceder.

3) scriptable. Sí, pero como se mencionó, no es el lenguaje de programación más robusto. Escribí un complemento de Excel que nuestros evaluadores usan para escribir sus pruebas que simplifica un poco las cosas.

4) funcionan con diferentes resoluciones de pantalla automáticamente. Sí, ya que se ve "debajo de las sábanas" en los objetos de la interfaz de usuario y no en la pantalla. Excepto quizás la opción "basada en imágenes de Pruebas" ...

5) poder 'espía' en las cajas de texto estáticos individuales, etc. sí, se puede esperar a que aparezca un objeto de interfaz de usuario, disapper , para tener un valor, para un valor que se va a cambiar, etc.

6) lo suficientemente intuitivo para que los programadores no puedan crear las secuencias de comandos. Con un poco de entrenamiento. Hemos tenido un éxito limitado. Algunas personas de QA pueden escribir las pruebas, algunas luchan.

7) tienen herramientas de informes, incluido el correo electrónico de usuarios individuales. Sí, utilizando el marco STAF puede publicar resultados en un servidor web, enviar correos electrónicos, etc.

Answer 2

Ver User Interface Testing.

Answer 3

Las aplicaciones de escritorio o web tienen el mismo patrón de prueba aquí (he trabajado en ambas).

Coloque la menor lógica posible en la interfaz de usuario y pruebe todo lo que está debajo. Entonces dices, ¿pero qué pasa si quiero probar que tal o cual suceda cuando se hace clic en un botón? El método que se llama cuando se hace clic en ese botón debe llamar a otra clase que realmente piensa.

Podría decir, pero estoy usando algunas clases/métodos estáticos que solo pueden existir en mi interfaz de usuario, envuelva esos con un adaptador y utilice esa interfaz para que su código sea comprobable.

Las partes de las pruebas GUI que desea automatizar deben estar automatizadas debajo de la IU. Hay partes de su GUI que no puede automatizar. Verificando para asegurarse de que las cosas "se ven bien", o probando que puedes ver ciertos elementos, etc. Todo eso es lo que tus humanos deberían estar haciendo. Asegurándose de que los eventos se activan correctamente, y de que los valores se devuelven de manera adecuada desde sus objetos comerciales, son todas las pruebas unitarias.

Veo por su pregunta que ya ha decidido que necesita un probador de GUI automatizado, pero esa no es la herramienta adecuada para este trabajo. Si decides usar eso, estás tratando de encontrar la mejor manera de hacer lo incorrecto.

Si cree que esto no se trata de pruebas unitarias porque está probando interacciones GUI, entonces puedo garantizarle que no está realizando pruebas unitarias lo suficientemente cerca de su UI. Si lo fuera, sentiría que la mayor parte de lo que probaría era redundante.

Si no está de acuerdo conmigo, por favor publique algunas razones y haremos esto.

Answer 4

Existen muchas más alternativas (de código abierto) si está probando un producto web. Para un producto de escritorio, algunas herramientas populares de automatización de GUI de escritorio de propósito general a continuación (sin ningún orden en particular). He trabajado con todo esto personalmente, y todos hacen el trabajo. Si opta por ir con una herramienta de proveedor, obtenga los POC para los que está considerando y tome la decisión según la herramienta que mejor se adapte a la compañía en general. Una herramienta puede ser una mejor opción para una aplicación en particular, pero puede haber otros proyectos/aplicaciones para considerar.

• Quick Test Pro (sucesor de HP para WinRunner)
• Rational Functional Tester (sucesor de IBM para Robot)
• TestPartner

Answer 5

Un montón de buenas respuestas aquí, pero yo quería hacer frente a esta declaración de la meta , específicamente:

• lo suficientemente intuitivo para que los no programadores puedan crear el scrip ts

Entiendo por qué quieres esto, pero es mucho más difícil de lo que piensas. Si bien puede encontrar cualquier cantidad de herramientas que indique , reclame para que sea más fácil escribir guiones, en la práctica, necesitará al menos algunas personas en su equipo de automatización que entiendan la programación. Escribir scripts que sean razonablemente robustos va a involucrar una o más de las llamadas de bucle, si/then/else y subrutina. No es el tipo de cosas que los no programadores van a encontrar intuitivas.

Tenga mucho cuidado con la idea de que puede "grabar" a una persona usando una herramienta y luego reproducirla para probarla. Ese tipo de "automatización" a menudo es tan frágil que terminará modificando o regrabando el script para casi todos los cambios en el software.

Answer 6

Viniendo de un sólido fondo de Mercury/HP, recomendaría altamente usar QuickTest Professional para su prueba GUI. Tiene la misma funcionalidad que WinRunner, pero sin mucho código. Se pueden realizar comprobaciones simples de GUI a través de la interfaz QTP con un código VB personalizado mínimo, si corresponde. Las verificaciones de texto junto a las casillas se pueden hacer con simples comparaciones usando la hoja de datos en QTP.

Si está acostumbrado a WinRunner, y conoce VBScript (no tanto TSL), entonces definitivamente miraría a QTP.

En cuanto a sus otros requisitos, QTP también tiene la función Spy, como WinRunner, que enumerará todas las propiedades y acciones que puede realizar en los objetos. Y en cuanto a la simplicidad de uso, en mi trabajo anterior, haríamos que los comprobadores de empresas o sistemas crearan simples secuencias de comandos para el humo, luego las tomaría y codificaría para realizar más pruebas en profundidad (valores de datos múltiples, comprobación de errores, etc.). Y en cuanto a la generación de informes, QTP hará informes sencillos de aprobado/no aprobado/advertencia en las etiquetas que ingrese, junto con los datos personalizados que puede ingresar. Por lo tanto, podría usar una declaración de caso para completar sus valores de salida en función de sus resultados. No enviará correo electrónico directamente, pero si se integra con TestDirector/QualityCenter, puede configurar desde allí, junto con la automatización del inicio de sus scripts y la parametrización de datos desde allí (lo que es bueno enviar de vuelta a los evaluadores deben haber rellenado datos sin estar involucrados en el script).

Pat