Primero la accesibilidad, la visión cuando la aplicación no dice nada: cómo encuentra GUI Test Studio cada elemento
La mayoría de las pruebas de extremo a extremo fallan porque ya no encuentran un elemento.El GTS Engine + AI encuentra cada elemento de dos maneras: pregunta a la aplicación mediante su información de accesibilidad, y encuentra el elemento visualmente cuando la aplicación no lo dice.Por qué dos caminos hacia un mismo elemento hacen robusta una prueba, sin ningún localizador que escribir ni mantener.
6 min de lecturaPor el equipo de GUI Test Studio
Por qué fallan las pruebas de extremo a extremo
Pregunte a un equipo por qué sus pruebas de extremo a extremo están en rojo, y la respuesta rara vez es un defecto.Lo más frecuente es que una prueba ya no encontrara un botón: un desarrollador renombró una clase, una actualización del framework cambió la estructura de la página, un diálogo se abrió un poco más abajo, un tema cambió un color.La aplicación estaba bien; la prueba no.
Las pruebas basadas en código encuentran los elementos con localizadores: un id, un selector CSS, un XPath, una posición.Cada uno es una suposición sobre cómo está construida la aplicación, y cada rediseño rompe algunos.Las herramientas basadas en imágenes tienen la debilidad contraria: ven la pantalla, pero no saben nada de lo que la aplicación dice de ella.
Dos caminos hacia un mismo elemento
El GTS Engine + AI, el motor que hay detrás de cada comprobación de GUI Test Studio, no elige entre los dos.Encuentra cada elemento de dos maneras, y usa la que funciona en la pantalla que tiene delante.
Preguntar
La aplicación dice dónde está el elemento
Ver
O el motor lo encuentra visualmente
Comparar
Lo que hay, frente a lo que usted espera
Informar
El veredicto, en palabras sencillas
Primero: preguntar a la aplicación
La mayoría de las aplicaciones describen su propia interfaz a Windows: cada botón, campo, lista y etiqueta con su nombre, su función y su posición en la pantalla.Es la información de accesibilidad que usan los lectores de pantalla, y es precisa e inmediata.Una página web hace lo mismo mediante sus propios elementos.
Cuando una prueba se graba, o se describe en una petición, GUI Test Studio guarda lo que la aplicación dijo sobre cada elemento del que se hizo una comprobación.Cuando la prueba se ejecuta, el motor pide primero ese elemento a la aplicación en vivo: dónde está ahora, si es visible, si algo lo cubre.Una comprobación de texto pregunta a la aplicación qué dice el elemento antes de leer las palabras de la pantalla.
| Lo que dice la aplicación | Lo que aporta a la prueba |
|---|---|
| El nombre y la función del elemento | Se vuelve a encontrar el mismo botón, incluso entre otros que se le parecen |
| Su posición en la pantalla | El elemento se encuentra donde se movió, al instante |
| Si es visible o está cubierto | Se detecta un diálogo o un menú delante de él, nunca se hace clic a través |
| Lo que dice | Una comprobación de texto obtiene las palabras exactas, nunca una mala lectura |
Después: encontrarlo visualmente
Algunas aplicaciones no dicen nada.Un videojuego dibuja sus menús él mismo.Un lienzo, un gráfico o un mapa es una sola imagen para Windows.Un escritorio remoto, una máquina virtual o un teléfono mostrado en su pantalla es una única ventana sin nada dentro.Los programas antiguos dibujados por su propio toolkit parecen un solo panel en blanco.
Ahí, el GTS Engine encuentra el elemento visualmente, en la pantalla en vivo, como lo hace una persona: busca la imagen del elemento en su zona de búsqueda, tolera las pequeñas diferencias que tiene toda pantalla, y distingue los elementos parecidos por dónde están.También toma el relevo cuando la respuesta de la aplicación no se sostiene: un elemento que indica pero que está oculto, cubierto o lejos de donde debería estar.
Por qué dos caminos hacen robusta una prueba
Cada camino cubre el punto débil del otro.A la información de accesibilidad no le importa el aspecto de un elemento, así que un tema nuevo, una fuente o un escalado de pantalla distinto no lo pierden.A la visión no le importa cómo se construyó la aplicación, así que una clase renombrada, un framework nuevo o una aplicación sin ninguna información de accesibilidad tampoco lo pierden.
| Qué cambió | Qué sigue encontrando el elemento |
|---|---|
| Se reescribió el código que hay detrás del botón | Ambos: la aplicación lo sigue nombrando, y sigue teniendo el mismo aspecto |
| La ventana se movió, o el diseño se desplazó | La aplicación dice dónde está ahora, y la visión lo encuentra ahí |
| Un color o un tema nuevos | La información de accesibilidad de la aplicación |
| Un videojuego, un lienzo, un escritorio remoto | La visión |
| Varios botones idénticos | Los nombres de la aplicación y la posición del elemento los distinguen |
El resultado es una prueba que sigue encontrando lo que busca mientras su aplicación cambia a su alrededor, y que solo falla por un motivo: lo que vería el usuario está mal.
Encontrar es la mitad de la comprobación
Una vez encontrado el elemento, el GTS Engine compara lo que hay en la pantalla con lo que usted espera: la imagen, las palabras, la disposición.Ignora el ruido que tiene toda pantalla, el suavizado y la compresión, y detecta las regresiones reales, lo que una persona llamaría un cambio: un color incorrecto, un icono que falta, una palabra que cambió de mayúsculas a minúsculas.
Cuando una comprobación falla, el Análisis inteligente con IA, la parte de IA opcional del motor, puede echar una segunda mirada y explicar la diferencia en palabras sencillas, con un modelo en la nube y su propia clave o un modelo local en su propio equipo, uno nuestro o uno suyo.Consulte Análisis inteligente con IA.
Nada que configurar
No hay ningún localizador que escribir, ningún ajuste de accesibilidad que activar, ningún modo que elegir.Grabe la prueba usted mismo, o descríbala en una petición a Claude, a ChatGPT o a un modelo de IA en su propio equipo: GUI Test Studio guarda lo que necesita de cada elemento, y el motor decide en cada ejecución qué camino lo encuentra.Todo se ejecuta en su propio equipo.
Preguntas
¿GUI Test Studio usa el árbol de accesibilidad?
Sí.El GTS Engine + AI primero pregunta a la aplicación dónde está un elemento, mediante su información de accesibilidad en Windows, o mediante los propios elementos de la página web en un navegador.Solo encuentra el elemento visualmente en la pantalla cuando la aplicación no lo dice.
¿Y si mi aplicación no tiene información de accesibilidad?
La prueba funciona igualmente.Los juegos, los lienzos, los escritorios remotos y los programas dibujados por su propio kit de herramientas no exponen nada, así que el GTS Engine encuentra sus elementos visualmente, en la pantalla, como lo hace una persona.
¿Tengo que escribir localizadores o selectores?
No.GUI Test Studio guarda por sí mismo lo que necesita de cada elemento cuando la prueba se graba o se describe en un prompt.No hay ningún localizador, selector ni identificador de elemento que escribir o mantener.
¿La comprobación sigue siendo visual cuando el elemento se encuentra mediante la accesibilidad?
Sí.Encontrar el elemento es la primera mitad de una comprobación.La segunda mitad siempre compara lo que hay en la pantalla con lo que usted espera, de modo que una prueba detecta lo que verían sus usuarios, como un color incorrecto o un icono que falta.
¿Listo para grabar su primera prueba?
Todas las funciones, durante 15 días.
¿Prefiere verlo con el tipo de aplicación que prueba?Reserve una llamada gratuita de 30 minutos con nuestro equipo.