En ingeniería de software , la prueba de interfaz gráfica de usuario es el proceso de probar la interfaz gráfica de usuario (GUI) de un producto para garantizar que cumpla con sus especificaciones. Esto normalmente se hace mediante el uso de una variedad de casos de prueba .
Para generar un conjunto de casos de prueba , los diseñadores de pruebas intentan cubrir toda la funcionalidad del sistema y ejercitar completamente la propia GUI . La dificultad para realizar esta tarea es doble: lidiar con el tamaño del dominio y las secuencias. Además, el evaluador enfrenta más dificultades cuando tiene que realizar pruebas de regresión .
A diferencia de un sistema CLI (interfaz de línea de comandos), una GUI puede tener operaciones adicionales que deben probarse. Un programa relativamente pequeño como Microsoft WordPad tiene 325 operaciones GUI posibles. [1] En un programa grande, el número de operaciones puede ser fácilmente de un orden de magnitud mayor.
El segundo problema es el de la secuenciación. Algunas funciones del sistema sólo pueden lograrse con una secuencia de eventos GUI. Por ejemplo, para abrir un archivo, es posible que el usuario primero tenga que hacer clic en el menú Archivo, luego seleccionar la operación Abrir, usar un cuadro de diálogo para especificar el nombre del archivo y enfocar la aplicación en la ventana recién abierta. Aumentar el número de operaciones posibles aumenta exponencialmente el problema de secuenciación. Esto puede convertirse en un problema grave cuando el evaluador crea casos de prueba manualmente.
Las pruebas de regresión también suelen ser un desafío con las GUI. Una GUI puede cambiar significativamente, aunque la aplicación subyacente no lo haga. Una prueba diseñada para seguir una determinada ruta a través de la GUI puede fallar ya que un botón, elemento de menú o cuadro de diálogo puede haber cambiado de ubicación o apariencia.
Estos problemas han impulsado el dominio de problemas de pruebas de GUI hacia la automatización. Se han propuesto muchas técnicas diferentes para generar automáticamente conjuntos de pruebas completos y que simulen el comportamiento del usuario.
La mayoría de las técnicas de prueba intentan basarse en las utilizadas anteriormente para probar programas CLI, pero pueden tener problemas de escala cuando se aplican a las GUI. Por ejemplo, el modelado basado en máquinas de estados finitos [2] [3] , donde un sistema se modela como una máquina de estados finitos y se utiliza un programa para generar casos de prueba que ejercitan todos los estados, puede funcionar bien en un sistema que tiene una capacidad limitada. número de estados, pero puede volverse demasiado complejo y difícil de manejar para una GUI (consulte también pruebas basadas en modelos ).
Un enfoque novedoso para la generación de conjuntos de pruebas, adaptado de una técnica CLI [4], implica el uso de un sistema de planificación. [5] La planificación es una técnica bien estudiada del dominio de la inteligencia artificial (IA) que intenta resolver problemas que involucran cuatro parámetros:
Los sistemas de planificación determinan un camino desde el estado inicial hasta el estado objetivo mediante el uso de operadores. Como ejemplo simple de un problema de planificación, dadas dos palabras y una sola operación que reemplaza una sola letra de una palabra por otra, el objetivo podría ser cambiar una palabra por otra.
En [1] los autores utilizaron el planificador IPP [6] para demostrar esta técnica. Primero se analiza la interfaz de usuario del sistema para determinar las posibles operaciones. Estos se convierten en los operadores utilizados en el problema de planificación. A continuación se determina un estado inicial del sistema y se especifica un estado objetivo que el evaluador considera que permitiría ejercitar el sistema. El sistema de planificación determina un camino desde el estado inicial hasta el estado objetivo, que se convierte en el plan de prueba.
Usar un planificador para generar los casos de prueba tiene algunas ventajas específicas sobre la generación manual. Un sistema de planificación, por su propia naturaleza, genera soluciones a los problemas de planificación de una manera que resulta muy beneficiosa para el evaluador:
Al crear manualmente un conjunto de pruebas, el evaluador se centra más en cómo probar una función (es decir, la ruta específica a través de la GUI). Al utilizar un sistema de planificación, se cuida la ruta y el evaluador puede concentrarse en qué función probar. Un beneficio adicional de esto es que un sistema de planificación no está restringido de ninguna manera al generar la ruta y, a menudo, puede encontrar una ruta que el evaluador nunca anticipó. Es muy importante combatir este problema. [7]
Otro método para generar casos de prueba de GUI simula a un usuario novato. Un usuario experto de un sistema tiende a seguir un camino directo y predecible a través de una GUI, mientras que un usuario novato seguiría un camino más aleatorio. Entonces, es probable que un usuario novato explore más estados posibles de la GUI que un experto.
La dificultad radica en generar conjuntos de pruebas que simulen el uso del sistema por parte de "novatos". Se han propuesto utilizar algoritmos genéticos para resolver este problema. [7] Los caminos de los principiantes a través del sistema no son caminos aleatorios. En primer lugar, un usuario novato aprenderá con el tiempo y, por lo general, no cometerá los mismos errores repetidamente y, en segundo lugar, un usuario novato está siguiendo un plan y probablemente tenga algún conocimiento del dominio o del sistema.
Los algoritmos genéticos funcionan de la siguiente manera: un conjunto de 'genes' se crean aleatoriamente y luego se someten a alguna tarea. Los genes que mejor completan la tarea se conservan y los que no se descartan. El proceso se repite nuevamente con los genes supervivientes que se replican y el resto del conjunto se completa con más genes aleatorios. Con el tiempo, un gen (o un pequeño conjunto de genes si existe algún umbral establecido) será el único gen del conjunto y, naturalmente, será el que mejor se adapte al problema dado.
En el caso de las pruebas de GUI, el método funciona de la siguiente manera. Cada gen es esencialmente una lista de valores enteros aleatorios de una longitud fija. Cada uno de estos genes representa un camino a través de la GUI. Por ejemplo, para un árbol determinado de widgets, el primer valor en el gen (cada valor se llama alelo) seleccionaría el widget sobre el que operar, los siguientes alelos luego completarían la entrada al widget dependiendo del número de entradas posibles. al widget (por ejemplo, un cuadro de lista desplegable tendría una entrada... el valor de la lista seleccionada). El éxito de los genes se puntúa mediante un criterio que premia el mejor comportamiento "novato".
En [7] se describe un sistema para realizar estas pruebas para el sistema de ventanas X, pero extensible a cualquier sistema de ventanas. [7] El sistema X Window proporciona funcionalidad (a través de XServer y el protocolo de los editores) para enviar dinámicamente entradas de GUI y obtener salidas de GUI. desde el programa sin utilizar directamente la GUI. Por ejemplo, se puede llamar a XSendEvent() para simular un clic en un menú desplegable, etc. Este sistema permite a los investigadores automatizar la creación y las pruebas de genes, de modo que para cualquier aplicación determinada que se esté probando, se pueda crear un conjunto de casos de prueba de usuarios novatos.
Al principio, las estrategias se migraron y adaptaron a partir de las estrategias de prueba de CLI.
Un método popular utilizado en el entorno CLI es la captura/reproducción. La reproducción de captura es un sistema en el que la pantalla del sistema se "captura" como un gráfico de mapa de bits en varios momentos durante la prueba del sistema. Esta captura permitió al evaluador "reproducir" el proceso de prueba y comparar las pantallas en la fase de salida de la prueba con las pantallas esperadas. Esta validación podría automatizarse ya que las pantallas serían idénticas si el caso se aprobara y diferentes si el caso fallara.
El uso de captura/reproducción funcionó bastante bien en el mundo CLI, pero existen problemas importantes cuando se intenta implementarlo en un sistema basado en GUI. [8] El problema más obvio que uno encuentra es que la pantalla en un sistema GUI puede verse diferente mientras el estado del sistema subyacente es el mismo, lo que hace que la validación automatizada sea extremadamente difícil. Esto se debe a que una GUI permite que los objetos gráficos varíen en apariencia y ubicación en la pantalla. Las fuentes pueden ser diferentes, los colores o tamaños de las ventanas pueden variar, pero la salida del sistema es básicamente la misma. Esto sería obvio para un usuario, pero no obvio para un sistema de validación automatizado.
Para combatir este y otros problemas, los evaluadores han ido "bajo el capó" y han recopilado datos de interacción GUI del sistema de ventanas subyacente. [9] Al capturar los 'eventos' de la ventana en registros, las interacciones con el sistema ahora están en un formato desacoplado de la apariencia de la GUI. Ahora, sólo se capturan las transmisiones de eventos. Es necesario cierto filtrado de los flujos de eventos, ya que los flujos de eventos suelen ser muy detallados y la mayoría de los eventos no son directamente relevantes para el problema. Este enfoque puede facilitarse utilizando una arquitectura MVC , por ejemplo, y haciendo que la vista (es decir, la GUI aquí) sea lo más simple posible mientras el modelo y el controlador contienen toda la lógica. Otro enfoque es utilizar la tecnología de asistencia incorporada en el software , utilizar una interfaz HTML o una arquitectura de tres niveles que también permita separar mejor la interfaz de usuario del resto de la aplicación.
Otra forma de ejecutar pruebas en una GUI es crear un controlador en la GUI para que se puedan enviar comandos o eventos al software desde otro programa. [7] Este método de enviar y recibir eventos directamente desde un sistema es muy deseable al realizar pruebas, ya que las pruebas de entrada y salida pueden automatizarse completamente y se eliminan los errores del usuario.