WinAppDriver: alternativas para aplicaciones sin árbol de accesibilidad
¿Busca una alternativa a WinAppDriver?Cómo funcionan las pruebas de escritorio en Windows y cómo probar visualmente y sin código apps sin árbol de accesibilidad.
11 min de lecturaPor el equipo de GUI Test Studio
Cuando la herramienta de pruebas no puede ver su aplicación
Usted apunta Inspect al botón Guardar de su aplicación, e Inspect muestra un único panel en blanco.Su localizador no encuentra nada, la prueba de WinAppDriver falla y empieza la búsqueda de una alternativa a WinAppDriver.
El problema rara vez es la herramienta.Casi todas las herramientas de pruebas de escritorio preguntan al árbol de accesibilidad de la aplicación dónde está el botón, y algunas aplicaciones no tienen ninguno.
Esta guía explica cómo funciona la automatización de pruebas de escritorio en Windows, qué aplicaciones no puede ver y cómo probar de todos modos una aplicación de escritorio de Windows así: encontrando cada elemento visualmente, como lo hace una persona.
¿Cómo funciona la automatización de pruebas de escritorio en Windows?
La automatización de pruebas de escritorio es software que maneja una aplicación a través de su interfaz, como lo haría un tester, y comprueba lo que muestra.En Windows, casi toda pasa por Microsoft UI Automation, el framework de accesibilidad que también alimenta a los lectores de pantalla.
Cada aplicación describe su interfaz a Windows como un árbol.La ventana contiene paneles, y los paneles contienen botones, campos y listas, cada uno con un nombre, un tipo y una posición en la pantalla.Microsoft Active Accessibility, o MSAA, es la tecnología anterior que hace lo mismo para los programas más antiguos.
Leer el árbol
La aplicación describe su ventana
Encontrar con un localizador
Un AutomationId, un nombre, un XPath
Actuar
Hacer clic, escribir, seleccionar
Comprobar
Leer un valor en el árbol
Una herramienta de pruebas lee ese árbol, encuentra un elemento con un localizador, como su AutomationId, su nombre o un XPath que recorre el árbol, y después hace clic en él, escribe en él o lee su valor.
Esto funciona bien cuando el árbol está completo.Microsoft incluye la descripción de cada control estándar de Win32, Windows Forms (WinForms) y WPF, así que estos aparecen en el árbol por sí solos.Un control personalizado es distinto: sus desarrolladores deben escribir esa descripción y, sin ella, la documentación de Microsoft indica que el control es en gran parte opaco para UI Automation, que apenas puede informar de algo más que su ubicación.
WinAppDriver y sus alternativas leen el mismo árbol
WinAppDriver, el Windows Application Driver de Microsoft, llevó una automatización al estilo de Selenium a las aplicaciones UWP, Windows Forms, WPF y Win32 clásicas.Su última versión estable en GitHub, la 1.2.1, es de noviembre de 2020, seguida de una versión candidata 1.3 en julio de 2021.El controlador de Appium para Windows construido sobre él está marcado ahora como obsoleto, y su documentación indica el controlador Appium WinCore como su sustituto oficial.
Las alternativas habituales toman cada una un camino distinto hacia el mismo árbol:
- Appium WinCore y NovaWindows son controladores de Appium que trabajan con los elementos de UI Automation, desde una prueba escrita en cualquier lenguaje que admita Appium.
- FlaUI es una biblioteca .NET de código abierto que envuelve las bibliotecas UI Automation de Microsoft para pruebas escritas en C#.
- pywinauto es una biblioteca Python de código abierto con dos backends: la API de Win32 y UI Automation.
- Coded UI, el framework de pruebas de interfaz del propio Visual Studio, está obsoleto: Visual Studio 2019 es la última versión que crea pruebas con él.
- TestComplete y Ranorex son herramientas comerciales que identifican los controles por sus propiedades, y ambas ofrecen automatización basada en imágenes para los controles que no pueden reconocer.
Incluso la guía más reciente de Microsoft para aplicaciones WinUI 3, los comandos winapp ui para agentes de IA, lee el árbol de accesibilidad en vivo y pide a los desarrolladores que asignen un AutomationId a cada control interactivo.
Para ver lado a lado las herramientas de pruebas web, consulte el estudio comparativo.
¿Qué aplicaciones de Windows no tienen árbol de accesibilidad?
Apunte Inspect a cualquiera de ellas y a menudo encontrará un único panel en blanco donde esperaba un formulario.Es la realidad diaria de las pruebas de aplicaciones heredadas, y también de muchas aplicaciones modernas.
| Tipo de aplicación | Lo que suele encontrar una herramienta basada en el árbol |
|---|---|
| Controles dibujados a medida: una cuadrícula, una cinta de opciones, un indicador que la propia aplicación pinta | Un rectángulo, salvo que sus desarrolladores hayan escrito su accesibilidad |
| Programas Delphi (VCL) y Visual Basic 6 | Etiquetas y botones dibujados sin ventana propia, y cuadrículas que ocultan sus celdas tras nombres genéricos |
| Programas MFC con controles dibujados por el propietario | Botones y listas que el propio programa pinta, a menudo sin nombre ni texto |
| Aplicaciones Java Swing y AWT | Nada útil hasta que se activa el Java Access Bridge, que está desactivado de forma predeterminada |
| Videojuegos, visores 3D, lienzos, gráficos y mapas | Una ventana que contiene una imagen |
| Sesiones de Citrix, Escritorio remoto y VMware Horizon | Una única ventana de píxeles en su equipo |
| Aplicaciones dentro de una máquina virtual | La ventana de la máquina virtual, sin nada dentro |
| Aplicaciones Electron creadas sin nombres accesibles | Elementos sin un nombre con el que encontrarlos |
| Plataformas empresariales que dibujan sus formularios a mano | La propia ventana del formulario, y nada en ella |
A veces el árbol existe, pero usted no puede tocar la aplicación: un programa de otro proveedor, una compilación bloqueada para una auditoría, un equipo que no puede añadir AutomationIds por usted.Cualquier herramienta que necesite una compilación de prueba, un agente dentro de la aplicación o un cambio en su código queda entonces fuera de alcance.
Cómo comprobar su propia aplicación en dos minutos
- 1
Abrir una herramienta de inspección
Instale Accessibility Insights for Windows, la herramienta de inspección de Microsoft, o use Inspect del Windows SDK.
- 2
Pasar el ratón sobre los elementos que necesitan sus pruebas
Cada uno debería aparecer con un nombre, un tipo y un AutomationId.
- 3
Interpretar lo que ve
Un solo panel para toda la ventana, o elementos sin nombre, significa que una herramienta basada en el árbol no puede encontrarlos de forma fiable.
Pruebas basadas en imágenes: probar lo que hay en la pantalla
Las pruebas basadas en imágenes son la automatización de pruebas que encuentra los elementos por su aspecto en la pantalla, no por lo que la aplicación dice de ellos.Es como funciona la automatización de pruebas de escritorio sin información de accesibilidad.No necesitan nada de la aplicación: ni árbol, ni localizador, ni cambios en su código.Si usted puede ver un elemento, una prueba puede llegar a él.
Encontrar visualmente
En la pantalla real, en una zona de búsqueda
Actuar de verdad
Entrada real de ratón y teclado
Leer las palabras
El texto tal como lo muestra la pantalla
Comprobar lo que se muestra
Frente a lo que usted espera
SikuliX es el ejemplo clásico de código abierto: usted captura una imagen de cada elemento y escribe cada paso como una línea de script.Las herramientas comerciales ofrecen este enfoque como recurso de respaldo.La documentación de TestComplete, por ejemplo, indica que sus pruebas basadas en imágenes solo se pueden grabar en aplicaciones Android: en una aplicación de escritorio, usted captura las imágenes y añade los comandos de prueba a mano.
Hecha de forma ingenua, una prueba visual tiene puntos débiles bien conocidos.Cada uno tiene una respuesta:
| El punto débil | Lo que lo resuelve |
|---|---|
| Una ventana que se ha movido | Una búsqueda que se amplía a toda la pantalla cuando el elemento no está donde estaba |
| Clics grabados en coordenadas fijas | Cada clic dirigido a donde está ahora su elemento |
| Varios botones idénticos | Una zona de búsqueda alrededor de cada elemento, para que los elementos parecidos se distingan por dónde están |
| Un tono más claro, un borde más suave | Una comparación que ignora el ruido de renderizado y sigue fallando ante una diferencia real que una persona vería |
| Imágenes capturadas a mano | Una grabación que recorta cada imagen por usted |
| Un tamaño de pantalla o un escalado distintos | Grabar con el tamaño de pantalla y el escalado con los que se ejecutan las pruebas |
Una alternativa a WinAppDriver que no necesita árbol
GUI Test Studio es una suite de pruebas de GUI de extremo a extremo para Windows que prueba cualquier aplicación que usted pueda ver en su pantalla, sin código.No elige entre el árbol y la pantalla.
El GTS Engine + AI consulta primero la información de accesibilidad de la aplicación, cuando la hay, y encuentra el elemento visualmente cuando no la hay.
Cómo encuentra GUI Test Studio los elementos explica cómo funcionan juntos los dos caminos.Esto es lo que significa para una aplicación sin árbol, paso a paso.
- 1
Grabar la aplicación
En GUI Test Runner-Recorder, haga clic en Grabar y seleccione Una aplicación.Elija el programa entre las aplicaciones abiertas, o busque uno que todavía no esté en ejecución.Marque la casilla que lo inicia con la prueba y lo cierra al final, para que cada ejecución empiece con la aplicación recién abierta.Después use la aplicación como siempre.
Siempre se graba toda la pantalla.La opción Una aplicación solo decide de dónde salen las comprobaciones automáticas. Elegir una aplicación deja fuera de su prueba la notificación de otro programa, mientras que cada clic y cada tecla que usted pulse se siguen grabando.Consulte Grabar una prueba.
- 2
Cada elemento se guarda de dos maneras
Cada clic recibe una Aserción visual justo antes: una imagen del elemento, su objetivo visual.Cuando la aplicación describe ese elemento a Windows, la prueba guarda también esa descripción.Cuando la aplicación responde con un único panel en blanco, no hay nada que valga la pena guardar, y la imagen sola encuentra el elemento.
Algunos programas dibujan sus formularios a mano y solo describen la propia ventana del formulario.La prueba guarda esa ventana, así que un formulario que se ha movido se vuelve a encontrar donde está ahora.
- 3
Comprobar lo que se muestra
Una Aserción visual comprueba que un elemento está en la pantalla y tiene el aspecto correcto.Una Aserción de texto pregunta a la aplicación qué dice un elemento, y lee las palabras de la pantalla cuando la aplicación no puede decirlo.Una Aserción de texto dinámico comprueba por su formato un valor que cambia en cada ejecución, como una fecha o un número de pedido.
Cada comparación ignora las pequeñas diferencias de renderizado que tiene toda pantalla y sigue detectando las regresiones reales que una persona llamaría un cambio: un color incorrecto, un icono que falta, una palabra que cambió.Consulte Comprobaciones visuales.
- 4
Ejecutarla, dondequiera que se abra la ventana
La prueba reproduce sus clics y sus teclas como entrada real de ratón y teclado, dirigida a donde está ahora cada elemento.Cuando una comprobación no ha encontrado su elemento en su zona de búsqueda al cabo de un segundo, mira también en toda la pantalla, así que una ventana que se ha movido no hace fallar la prueba.El Informe de confianza indica entonces que el elemento se encontró fuera de su zona de búsqueda, y ofrece ampliarla en GUI Test Studio.
En un equipo con varios monitores, una prueba usa una pantalla o todas, y recuerda cuál.
Una ejecución de ejemplo: el Informe de confianza resalta lo que cambió y lo dice en palabras sencillas.
Citrix, Escritorio remoto y máquinas virtuales
Una sesión de Citrix, Escritorio remoto (RDP) o VMware Horizon llega a su equipo como una única ventana de píxeles.Algunas herramientas solo pueden llegar a sus controles cuando están instaladas en el propio servidor remoto, como describe SmartBear para TestComplete.GUI Test Studio prueba la sesión desde el equipo que la muestra, visualmente, como cualquier otra ventana.
Al grabar, elija Una aplicación y la ventana de la sesión, o Un área de la pantalla para uno de sus paneles.Una aplicación en una máquina virtual funciona igual: dé a la máquina virtual un tamaño de ventana fijo, el mismo en todos los equipos que ejecutan las pruebas.Consulte Qué puede probar.
Un programa Delphi de registro de pedidos se ejecuta en un servidor, y sus testers acceden a él a través de Escritorio remoto.Usted graba un pedido en la ventana de la sesión.Cada clic recibe su Aserción visual, y usted añade una Aserción de texto que espera «Pedido guardado».
En la siguiente ejecución, la sesión se abre más a la derecha.Cada comprobación encuentra allí su elemento, y cada clic lo sigue.
Ejecutar pruebas de escritorio en cada compilación
gtr-cli, el ejecutor de línea de comandos, ejecuta una prueba exactamente igual que el botón Ejecutar prueba.Añade lo que necesita un pipeline: un código de salida, un archivo JUnit y todas las evidencias de un fallo en una sola carpeta.
gtr-cli run tests --countdown 0 --junit results\junit.xml --artifacts results\artifactsUna prueba de escritorio se reproduce en una pantalla real, así que el agente de compilación necesita una sesión de escritorio de Windows desbloqueada.Una máquina virtual con un tamaño de pantalla fijo funciona bien como agente de pruebas.La guía de CI/CD explica su configuración paso a paso.
Preguntas
¿Qué puedo usar en lugar de WinAppDriver?
Para una aplicación con un árbol de accesibilidad completo, los controladores Appium WinCore y NovaWindows, FlaUI y pywinauto leen Windows UI Automation desde código.Para una aplicación sin árbol, o para probar sin código, use una herramienta que encuentre los elementos visualmente, como GUI Test Studio, que además pregunta primero al árbol cuando lo hay.
¿Se sigue manteniendo WinAppDriver?
Su última versión estable en GitHub es la 1.2.1, de noviembre de 2020, seguida de una versión candidata 1.3 en julio de 2021.La documentación del proyecto Appium indica que Microsoft lleva años sin mantener el servidor de WinAppDriver, y señala el controlador Appium WinCore como el sustituto oficial de su propio controlador para Windows.
¿Cómo probar una aplicación que no tiene árbol de accesibilidad?
Pruébela visualmente: encuentre cada elemento en la pantalla real por su aspecto, actúe con entrada real de ratón y teclado, lea las palabras de la pantalla y compare lo que se muestra con lo que espera.GUI Test Studio construye todo esto a partir de una grabación, así que no hay ninguna imagen que capturar a mano ni ningún script que escribir.
¿Puedo automatizar pruebas de una aplicación en una sesión de Citrix o de Escritorio remoto?
Sí, desde el equipo que muestra la sesión.La sesión llega a ese equipo como una única ventana de píxeles, así que la prueba encuentra sus elementos visualmente, como en cualquier otra ventana, sin instalar nada en el servidor remoto.
¿Las pruebas basadas en imágenes fallan cuando se mueve la ventana?
No, si se hacen bien.GUI Test Studio dirige cada clic a donde está ahora su elemento, y una comprobación que no encuentra su elemento en su zona de búsqueda al cabo de un segundo mira también en toda la pantalla, así que una ventana que se ha movido no hace fallar la prueba.
¿GUI Test Studio funciona también con aplicaciones WPF y Windows Forms?
Sí.Cuando una aplicación describe su interfaz a Windows, como hacen las aplicaciones WPF y Windows Forms, el GTS Engine + AI le pregunta primero y guarda esa descripción con cada comprobación.También se guarda la imagen, así que la prueba sigue encontrando el elemento si alguna vez la respuesta de la aplicación se queda corta.
WinAppDriver, Windows, Visual Studio, Selenium, Appium, FlaUI, pywinauto, TestComplete, Ranorex, SikuliX, Delphi, Java, Citrix, VMware Horizon y Electron son marcas comerciales de sus respectivos propietarios.
¿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.