Pruebas de interfaz gráfica de usuario

Los sistemas de planificación determinan una ruta desde el estado inicial hasta el estado objetivo mediante el uso de operadores. Como ejemplo sencillo de un problema de planificación, dadas dos palabras y una operación que reemplaza una letra en una palabra por otra, el objetivo podría ser transformar una palabra en 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 operaciones posibles. Estas 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, según el evaluador, permitiría probar el sistema. El sistema de planificación determina una ruta desde el estado inicial hasta el estado objetivo, que se convierte en el plan de prueba.

Utilizar 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 muy beneficiosa para el probador:

1. Los planes siempre son válidos. El sistema genera un plan válido y correcto que utiliza los operadores para alcanzar el estado objetivo, o bien ningún plan. Esto resulta beneficioso, ya que se puede perder mucho tiempo creando manualmente un conjunto de pruebas debido a casos de prueba inválidos que el evaluador creía que funcionarían, pero no fue así.
2. Un sistema de planificación se centra en el orden. A menudo, para probar una función específica, el caso de prueba debe ser complejo y seguir una ruta a través de la interfaz gráfica de usuario (GUI), donde las operaciones se realizan en un orden determinado. Si se realiza manualmente, esto puede dar lugar a errores y, además, puede resultar bastante difícil y laborioso.
3. Por último, y lo más importante, un sistema de planificación está orientado a objetivos. El evaluador centra la generación del conjunto de pruebas en lo más importante: probar la funcionalidad del sistema.

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 interfaz gráfica de usuario). Al usar un sistema de planificación, la ruta se gestiona automáticamente y el evaluador puede concentrarse en qué función probar. Una ventaja adicional es que un sistema de planificación no tiene restricciones al generar la ruta y, a menudo, puede encontrar una ruta que el evaluador no había previsto. Este problema es muy importante de abordar. ^{[ 7 ]}

Otro método para generar casos de prueba de interfaz gráfica de usuario (GUI) simula a un usuario principiante. Un usuario experto tiende a seguir una ruta directa y predecible a través de la GUI, mientras que un usuario principiante seguiría una ruta más aleatoria. Por lo tanto, es probable que un usuario principiante 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 usuarios principiantes. Se ha propuesto el uso de algoritmos genéticos para resolver este problema. ^{[ 7 ]} Las rutas que sigue un usuario principiante a través del sistema no son aleatorias. En primer lugar, un usuario principiante aprende con el tiempo y, por lo general, no comete los mismos errores repetidamente; y, en segundo lugar, un usuario principiante sigue un plan y probablemente posee cierto conocimiento del dominio o del sistema.

Los algoritmos genéticos funcionan de la siguiente manera: se crea un conjunto de genes aleatoriamente y se les somete a una tarea. Los genes que mejor la completan se conservan y los que no, se descartan. El proceso se repite replicando los genes que sobreviven y completando el resto del conjunto con más genes aleatorios. Finalmente, un gen (o un pequeño conjunto de genes, si se establece un umbral) será el único gen del conjunto y, naturalmente, el que mejor se ajuste al problema planteado.

En el caso de las pruebas de interfaz gráfica de usuario (GUI), el método funciona de la siguiente manera: cada gen es esencialmente una lista de valores enteros aleatorios de longitud fija. Cada uno de estos genes representa una ruta a través de la GUI. Por ejemplo, para un árbol de widgets dado, el primer valor del gen (cada valor se denomina alelo) seleccionaría el widget sobre el que operar; los alelos siguientes completarían la entrada del widget según el número de entradas posibles (por ejemplo, un cuadro de lista desplegable tendría una entrada: el valor seleccionado en la lista). El éxito de los genes se evalúa mediante un criterio que premia el mejor comportamiento de un usuario principiante.

Kasik y George introdujeron un sistema para realizar pruebas de interfaz gráfica de usuario (GUI) para el sistema de ventanas X, extensible a cualquier sistema de ventanas. ^{[ 7 ]} El sistema de ventanas X proporciona funcionalidad (a través de XServer y su protocolo) para enviar dinámicamente la entrada de la GUI y obtener la salida de la GUI del programa sin usarla directamente. Por ejemplo, se puede llamar a XSendEvent() para simular un clic en un menú desplegable, etc. Este sistema permite a los investigadores automatizar la generación de casos de prueba y las pruebas para cualquier aplicación, de manera que se pueda crear un conjunto de casos de prueba para usuarios principiantes.

Un método popular en el entorno de la interfaz de línea de comandos (CLI) es la captura y reproducción. Este método consiste en capturar la pantalla del sistema como una imagen de mapa de bits en diferentes momentos durante las pruebas. Esta captura permite al evaluador reproducir el proceso de prueba y comparar las pantallas de salida con las esperadas. Esta validación puede automatizarse, ya que las pantallas serían idénticas si la prueba se supera y diferentes si falla.

El uso de captura/reproducción funcionó bastante bien en el mundo de la CLI, pero existen problemas significativos cuando se intenta implementarlo en un sistema basado en GUI. ^{[ 8 ]} El problema más evidente es que la pantalla en un sistema GUI puede verse diferente aunque el estado del sistema subyacente sea el mismo, lo que dificulta enormemente la validación automatizada. 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 para un sistema de validación automatizado.

Para combatir este y otros problemas, los evaluadores han ido "debajo del capó" y recopilado datos de interacción de la 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 que está desacoplado de la apariencia de la GUI. Ahora, solo se capturan los flujos 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 simplificarse utilizando una arquitectura MVC  , por ejemplo, y haciendo que la vista ( es decir, la GUI en este caso) sea lo más simple posible mientras que el modelo y el controlador contienen toda la lógica. Otro enfoque es utilizar la tecnología de asistencia integrada del software para utilizar una interfaz HTML o una arquitectura de tres capas que también permite separar mejor la interfaz de usuario del resto de la aplicación.

Otra forma de realizar pruebas en una interfaz gráfica de usuario (GUI) es integrar un controlador en la GUI para que se puedan enviar comandos o eventos al software desde otro programa. ^{[ 7 ]} Este método de envío y recepción directa de eventos a un sistema es muy recomendable durante las pruebas, ya que permite automatizar completamente las pruebas de entrada y salida y elimina el error del usuario.