¿Otra vez «element not found»? Cómo probar cuando fallan los selectores y los localizadores
¿«Element not found»?Por qué se rompen selectores y localizadores (IDs dinámicos, shadow DOM, iframes, canvas) y cómo probar sin ningún localizador que mantener.
«Element not found» significa que su prueba buscó un elemento con un localizador y nada coincidió a tiempo.La solución rara vez es un localizador mejor: es una prueba que comprueba lo que ve el usuario.
Todo ingeniero de QA conoce esa mañana: veinte pruebas en rojo y ni un solo defecto real.Un desarrollador cambió el nombre de una clase, el equipo de diseño movió un banner, una actualización del framework cambió los identificadores.Este artículo explica por qué se rompen los localizadores, cómo corregir el error cuando aparece, dónde se detienen las soluciones habituales y cómo probar sin un selector que mantener.
¿Qué significa «element not found»?
Definición
Un error «element not found» significa que la prueba pidió un elemento con un localizador y nada en la página coincidió antes del tiempo de espera.
- Un localizador, también llamado selector, es la dirección que usa la prueba para el elemento: un identificador, un selector CSS, un XPath, un rol y un nombre, un texto.
- Selenium lanza NoSuchElementException, Playwright termina la acción con un tiempo de espera agotado, y cada framework tiene su propio nombre para ello.
Al final el mensaje siempre es el mismo: la prueba perdió el elemento, lo perdiera o no el usuario.
La propia página de solución de problemas de Selenium da tres causas probables: busca en el lugar equivocado, busca en el momento equivocado, o el localizador cambió desde que escribió el código.Solo la última tiene que ver con el localizador en sí, y es la que crece con cada versión.
#save-8f3a2c
Una nueva compilación genera otro identificador
.btn-primary
Un rediseño cambia el nombre de la clase
text=Save
La versión francesa dice Enregistrer
//div[3]/form/button[2]
Se añade un banner encima del formulario
En la pantalla
SaveSin cambios para el usuario
¿Por qué se rompen los selectores y los localizadores?
Un localizador es una suposición sobre cómo está construida la aplicación.Cualquier cosa que cambie la construcción sin cambiar lo que ve el usuario puede romperlo.
| Qué cambió | Qué localizadores se rompen | ¿Lo notó el usuario? |
|---|---|---|
| Identificadores y nombres de clase generados | Un identificador o una clase escritos por el framework, distintos en cada compilación o carga de página | No |
| Un rediseño o una refactorización | Las cadenas CSS y los XPath que siguen la estructura de la página | A menudo no |
| Una prueba A/B | Cualquier localizador de la variante que su prueba no esperaba | Solo los usuarios de esa variante |
| Una traducción | Los localizadores por texto visible o nombre accesible | No, si la traducción es correcta |
| Shadow DOM e iframes | Los localizadores que no pueden entrar en el componente o en el marco | No |
| Una lista virtualizada | Los localizadores de una fila que no se dibuja hasta que se desplaza a la vista | No |
| Un canvas, un juego o una aplicación sin árbol de accesibilidad | Todos los localizadores: no hay nada dentro a lo que apuntar | No |
Identificadores dinámicos y nombres de clase generados
Muchos frameworks escriben sus propios identificadores y nombres de clase, como save-8f3a2c o css-1x7hq.Son únicos, lo que los hace parecer localizadores perfectos, y cambian en la siguiente compilación.Una prueba grabada sobre ellos pasa hoy y falla tras el siguiente despliegue, en una página que nadie tocó.
Rediseños, refactorizaciones y pruebas A/B
Un selector CSS como .form > div:nth-child(3) button o un XPath como //div[3]/form/button[2] describe un camino a través de la página.Envuelva el formulario en un nuevo contenedor, añada un banner encima o cambie el orden de dos campos, y el camino lleva a otra parte.Una prueba A/B hace lo mismo a propósito: la mitad de los visitantes recibe una página para la que sus localizadores no se escribieron.
La documentación de Playwright lo dice claramente: los selectores XPath y CSS pueden estar ligados a la estructura del DOM, y pueden romperse cuando esta cambia.
Localización y localizadores por texto
Los localizadores por texto, etiqueta o nombre accesible sobreviven a un rediseño, por eso se recomiendan.No sobreviven a una traducción.Un botón encontrado por el nombre Save no se encuentra cuando la versión francesa dice Enregistrer, así que un producto localizado necesita un localizador por idioma, o un identificador de prueba.
Shadow DOM e iframes
Un iframe es una página dentro de la página, y un componente web guarda sus elementos internos en una shadow root.Selenium solo conoce los elementos del documento de nivel superior, así que hay que indicar a una prueba de código que entre primero en el marco, o informa de que el elemento no existe.Algunos localizadores, como XPath, no pueden entrar en un componente en absoluto.
Listas y cuadrículas virtualizadas
Una tabla de diez mil filas es rápida porque no las dibuja todas.AG Grid, una cuadrícula de datos muy usada, explica que solo dibuja lo que se ve en la pantalla, más una pequeña reserva de filas por encima y por debajo.La fila 500 no está en la página hasta que alguien se desplaza hasta ella, así que un localizador no la encuentra, mientras que una persona simplemente se desplazaría.
Cómo corregir un error «element not found»
En Selenium, Playwright o Cypress, corregir el error es trabajo suyo, y vuelve con cada versión.En GUI Test Studio no hay ningún localizador que corregir.
| Qué salió mal | En un framework de código | En GUI Test Studio |
|---|---|---|
| El elemento aparece tarde | Usted escribe una espera para la condición correcta | Cada comprobación espera por sí sola hasta su tiempo límite |
| El elemento está en un marco o una shadow root | Usted escribe la entrada en el marco o el componente | El elemento se encuentra donde está dibujado en la pantalla |
| Un rediseño cambió los identificadores o la estructura | Usted reescribe el localizador, a menudo en muchas pruebas | Nada que reescribir: otra vía, o su imagen, lo encuentra |
| El elemento cambió a propósito | Usted edita el código de la prueba | Un clic en el informe acepta el nuevo aspecto |
Cuando una prueba de GUI Test Studio se detiene en un elemento, estos cinco pasos lo resuelven, sin programar nada.
- 1
Abra el Informe de confianza de la ejecución
El informe se abre tras cada ejecución, en el primer fallo.Muestra la imagen esperada junto a la pantalla en el momento en que la comprobación se rindió, para que vea si el elemento faltaba, estaba tapado o estaba en otro sitio.
- 2
Compruebe dónde empezó la ejecución
Una prueba empieza en la pantalla en la que empezó su grabación.Si la aplicación estaba en otra página o tenía otros datos, déjela como estaba y vuelva a ejecutar la prueba.
- 3
Amplíe la zona de búsqueda si el elemento se movió lejos
Cuando no se encuentra nada en la zona de búsqueda de una comprobación, la búsqueda ya se amplía por sí sola a toda la pantalla.Si el elemento está ahora en otro sitio de forma definitiva, haga clic en Ampliar la zona de búsqueda en el informe y defina la nueva zona en GUI Test Studio.
- 4
Acepte un cambio hecho a propósito
Si el elemento se ve distinto porque el diseño cambió, haga clic en Aceptar la imagen real como esperada en el Informe de confianza y guarde.La prueba queda al día, sin código que editar.
- 5
Informe del defecto si el elemento desapareció de verdad
Si el elemento ya no está, la prueba hizo su trabajo.Haga clic en Informe de defecto para registrarlo como PDF o como incidencia de Jira, con las imágenes adjuntas.
CSS, XPath, rol o identificador de prueba: cada localizador tiene su punto débil
Los equipos que escriben pruebas de código eligen un localizador para cada elemento que tocan.Cada tipo falla a su manera.
| Localizador | Ejemplo | Se rompe cuando | Sobrevive a |
|---|---|---|---|
| Identificador o clase generados | #save-8f3a2c | La siguiente compilación | Casi nada |
| Selector CSS | .form button.primary | Cambian las clases o la estructura | Un texto nuevo o una traducción |
| XPath | //div[3]/form/button[2] | Se añade cualquier cosa encima o alrededor | Una clase nueva |
| Rol y nombre accesible | role=button, name=Save | La etiqueta cambia o se traduce | Rediseños y refactorizaciones |
| Identificador de prueba | data-testid=save-order | Un desarrollador lo elimina o le cambia el nombre | Rediseños, traducciones, refactorizaciones |
Cada estrategia desplaza el riesgo en lugar de eliminarlo.
- Un rol y un nombre dependen de las palabras, que cambian con cada traducción y cada retoque de texto.
- Un identificador de prueba depende de un hábito: cada desarrollador debe añadirlo, conservarlo y no reutilizarlo nunca, en cada componente, durante toda la vida del producto.
- CSS y XPath dependen de la estructura, que es justo lo que cambian las refactorizaciones.
XPath o selector CSS es la pregunta más frecuente, y importa menos de lo que parece.CSS es más corto y más fácil de leer; XPath puede subir por la página y buscar texto.Ambos describen cómo está construida la página, así que ambos se rompen de la misma forma.
En GUI Test Studio nadie elige un localizador.Una prueba grabada guarda por sí sola varias vías hacia cada elemento, como muestran las secciones siguientes.
¿La automatización de pruebas con autorreparación corrige los localizadores rotos?
Las herramientas de autorreparación guardan detalles adicionales de cada elemento mientras una prueba pasa.Cuando el localizador principal deja de coincidir, buscan el elemento con esos detalles y continúan.
La autorreparación es útil, con tres límites que conviene conocer.
Sigue partiendo de un localizador, así que necesita un elemento en la página hacia el que repararse.
Convierte un cambio en un éxito, así que cada reparación necesita que una persona la revise, o un cambio real se esconde detrás.
No puede ayudar donde no hay ningún elemento: un canvas, un juego, una pantalla remota.
Donde todo localizador se detiene: canvas, juegos y aplicaciones sin árbol de accesibilidad
Todas las estrategias anteriores suponen que la aplicación describe sus elementos.Muchas no lo hacen, y no hay ningún localizador que escribir, ni bueno ni malo.
| Aplicación | Lo que puede alcanzar un localizador |
|---|---|
| Un canvas, un gráfico, un mapa, una escena WebGL | Un solo elemento que contiene una imagen |
| Un juego | Una sola ventana: el juego dibuja sus menús él mismo |
| Flutter en la web | Nada hasta que la aplicación activa su accesibilidad: Flutter dibuja su interfaz en un canvas, y su accesibilidad es opcional en la web |
| Qt, Java Swing, Delphi y otras aplicaciones de escritorio dibujadas a medida | Poco o nada, según cómo se dibuje cada control |
| Citrix, Escritorio remoto y máquinas virtuales | Una sola ventana de píxeles en su ordenador |
Para las aplicaciones de escritorio de Windows, Alternativas a WinAppDriver para aplicaciones sin árbol de accesibilidad indica qué programas se describen y cuáles no.
Si su prueba solo ve lo que la aplicación describe, una aplicación que no describe nada no se puede probar.El usuario, en cambio, ve todos los botones.
Automatización de pruebas sin selectores que mantener
GUI Test Studio, que automatiza pruebas de extremo a extremo en Windows, toma otro camino: nadie escribe ni mantiene un selector.Usted graba la prueba haciendo el flujo usted mismo, o la describe en un prompt, y cada comprobación trata de lo que ve el usuario.
| La comprobación | Lo que comprueba |
|---|---|
| Aserción visual | Un elemento está en la pantalla y tiene el aspecto esperado: su imagen, encontrada y comparada |
| Aserción de texto | Un texto está en la pantalla, leído donde debe estar |
| Aserción de texto dinámico | Un valor tiene la forma correcta, como una fecha, un importe o un número de pedido, sea cual sea su valor |
| Aserción de disposición | Los elementos están donde deben estar unos respecto a otros |
Para encontrar cada elemento, el GTS Engine + AI usa dos caminos.Primero pregunta a la aplicación: la información de accesibilidad que una aplicación de Windows da sobre sus controles, o los propios elementos de una página web.Cuando la aplicación no dice nada, encuentra el elemento a la vista, en la pantalla.Cómo encuentra GUI Test Studio los elementos en la pantalla explica ambos caminos en detalle.
En una página web: varios caminos hacia un mismo elemento
En una prueba web, GUI Test Studio guarda varios caminos hacia cada elemento sobre el que actúa, ordenados: su identificador de prueba, su identificador, su rol y su nombre, su etiqueta, su texto de ejemplo, su texto y, al final, su lugar en la página.Un identificador que parece generado por un framework pasa hacia el final de la lista, después de todo lo que una persona puede leer.
Los caminos hacia el botón Save, probados en orden
- 1Su identificador de pruebadata-testid="save"Eliminado en una refactorización
- 2Su rol y su nombrerole=button · name=SaveEncontrado
- 3Su textoSaveNo hace falta
- 4Su lugar en la páginaform > button:nth-of-type(2)No hace falta
Así, un identificador de prueba eliminado o una clase renombrada no detienen la prueba: el siguiente camino sigue encontrando el elemento.Los mismos caminos llegan a los elementos dentro de una raíz shadow, y permiten que una prueba generada para un teléfono abra el menú que allí esconde un enlace.
Esto último es lo que permite que una sola prueba web grabada se ejecute en Chrome, Edge, Firefox y en teléfonos emulados, como muestran las pruebas en varios navegadores a partir de una sola grabación.
En una aplicación de escritorio: primero el control, después la pantalla
En una aplicación de Windows, una comprobación hecha sobre un botón guarda lo que la aplicación dijo de ese botón: su nombre, su tipo, dónde estaba.En cada ejecución, el motor pide primero ese botón a la aplicación en marcha, y busca su imagen dentro del recuadro que da la aplicación.Entre varios botones idénticos, toma el más cercano al lugar donde estaba el grabado.
Una comprobación de texto pregunta a la aplicación qué dice el elemento antes de leer las palabras en la pantalla, así que una palabra difícil de leer en la pantalla se comprueba igualmente con lo que la aplicación dice de verdad.
En todo lo demás: a la vista
Un juego, un canvas, una sesión de Citrix o un programa sin árbol de accesibilidad se prueba a la vista, sin añadir nada a la aplicación.La comprobación busca la imagen del elemento en su zona de búsqueda, y una comprobación de texto lee las palabras en la pantalla.
Un panel dibuja su gráfico de ventas en un canvas, así que ningún localizador puede llegar a una barra o a una leyenda.Usted graba un clic en la barra de marzo y añade una aserción visual de la leyenda.El clic se apunta a través de la imagen de la barra, y la leyenda se comprueba tal como la ve el usuario.
Qué pasa cuando el elemento se mueve o cambia
Una prueba que no depende de un solo localizador tiene que lidiar igualmente con el cambio.Esto es lo que hace GUI Test Studio en cada paso.
Preguntar
La aplicación dice dónde está el elemento
Mirar
O su imagen se encuentra en su zona de búsqueda
Ampliar
Nada allí: toda la pantalla
Informar
Dónde se encontró, y por qué
Cada paso cubre un tipo de cambio distinto.
- Una ventana que se movió, un diseño que se desplazó o una lista que se desplazó: la aplicación dice dónde está ahora el elemento, o su imagen se encuentra allí.
- Un elemento que salió de su zona de búsqueda: cuando no se encuentra nada allí, la búsqueda se amplía a toda la pantalla, y el Informe de confianza indica que el elemento se encontró fuera de su zona, con un enlace para ampliarla.
- Una palabra que el reconocimiento de texto lee mal: una comprobación de texto pregunta a la aplicación qué dice el elemento.
- Un elemento web cuyo primer localizador se rompió: el siguiente camino lo encuentra, y la ejecución anota qué camino cambió.
Los clics también siguen al elemento: cada clic se apunta a través de la comprobación que lo precede, así que cuando el botón se mueve, el clic se mueve con él.Consulte las comprobaciones visuales y las comprobaciones de texto para ver cómo se configura cada una.
Lo que todavía depende de usted
Ningún enfoque hace que todo cambio salga gratis.Estos son los casos en que decide una persona.
| Situación | Qué hacer |
|---|---|
| El aspecto de un elemento cambió a propósito | La comprobación falla con la imagen esperada y la real una al lado de la otra.Haga clic en Aceptar la imagen real como esperada en el Informe de confianza y guarde. |
| El tamaño de pantalla o el escalado difieren de la grabación | Una comprobación a la vista compara imágenes, así que ejecute con el mismo tamaño de pantalla y escalado, o mantenga un perfil de línea base para cada uno. |
| La aplicación no empieza donde empezó la grabación | Devuelva la aplicación al estado en que empezó la grabación: la misma página, los mismos datos, las mismas ventanas abiertas. |
| Una prueba A/B sirve otra variante | Fije la variante en su entorno de pruebas, o mantenga un perfil de línea base para cada variante. |
| El elemento desapareció de verdad | Es un defecto.La prueba falla, y el informe muestra qué se esperaba y dónde. |
Aceptar un nuevo aspecto explica la actualización con un clic, y pruebas inestables y falsos positivos explica cómo una comprobación distingue el ruido inofensivo de un cambio real.
Para los defectos visuales que una comprobación basada en localizadores deja pasar sin verlos, lea los defectos visuales que sus pruebas automatizadas no ven.
Lo esencial
- 1«Element not found» suele ser un problema de la prueba, no un defecto: el localizador, el momento o el contexto fallan más a menudo que la aplicación.
- 2Los localizadores se rompen por razones corrientes: identificadores generados, rediseños, pruebas A/B, traducciones, shadow DOM, iframes y listas virtualizadas.
- 3Cada estrategia desplaza el riesgo: CSS y XPath dependen de la estructura, los roles y los nombres de las palabras, los identificadores de prueba de un hábito del equipo, la autorreparación de una revisión.
- 4Algunas aplicaciones no le dan nada a un localizador: canvas, juegos, sesiones de Citrix y aplicaciones sin árbol de accesibilidad solo se pueden probar a la vista.
- 5GUI Test Studio no tiene selectores ni localizadores que mantener: pregunta primero a la aplicación, encuentra el elemento a la vista cuando la aplicación no lo dice y comprueba lo que ve el usuario.
Preguntas
¿Qué significa «element not found» en la automatización de pruebas?
Significa que la prueba pidió un elemento con un localizador, como un identificador, un selector CSS o un XPath, y nada en la página coincidió a tiempo.En Selenium aparece como NoSuchElementException, en Playwright como un tiempo de espera agotado.Puede que falte el elemento, pero lo más frecuente es que fallen el localizador, el momento o el contexto.
¿Por qué mi prueba encuentra el elemento en local pero no en CI?
Normalmente porque la ejecución es distinta, no el código.Un agente de compilación más lento muestra el elemento más tarde que su portátil, una pantalla más pequeña lo esconde tras un menú, otros datos de prueba cambian su texto, o una prueba A/B sirve otra variante.Mire la captura o el vídeo de la ejecución fallida antes de cambiar el localizador.
¿Qué es mejor, XPath o un selector CSS?
Ninguno es seguro por sí solo.Ambos describen cómo está construida la página, así que ambos se rompen cuando cambia su estructura, como advierte la documentación de Playwright.Un rol y un nombre o un identificador de prueba duran más, pero cada uno se sigue escribiendo y manteniendo a mano.En GUI Test Studio nadie escribe ninguno: la prueba guarda sus propias vías hacia cada elemento.
¿Cómo manejo los identificadores dinámicos en Selenium o Playwright?
No construya una prueba sobre ellos: un identificador que cambia en cada compilación o en cada carga de página no puede encontrar dos veces el mismo elemento.En una prueba de código eso significa escribir y mantener otro localizador a mano.En GUI Test Studio no hay nada que escribir: una prueba web pasa un identificador que parece generado al final de su lista de vías hacia el elemento, después de todo lo que una persona puede leer.
¿Funciona la automatización de pruebas con autorreparación?
Ayuda cuando cambia un atributo y el elemento sigue ahí.No puede recuperar un elemento que de verdad desapareció, y sigue partiendo de un localizador que alguien escribió y tiene que mantener.Revise cada reparación, o puede esconder un cambio real.
¿Cómo se prueba una aplicación que no tiene árbol de accesibilidad?
A la vista, en la pantalla.Los juegos, los canvas, los gráficos, las sesiones de Citrix y de Escritorio remoto y muchos programas dibujados a medida no exponen nada a lo que pueda llegar un localizador.GUI Test Studio encuentra sus elementos por su imagen y comprueba el texto leído en la pantalla, sin cambiar nada en la aplicación.
¿Se pueden automatizar pruebas de extremo a extremo sin selectores ni localizadores?
Sí.En GUI Test Studio usted graba una prueba o la describe en un prompt, y no hay selectores ni localizadores que mantener.Cada comprobación es una imagen, un texto, la forma de un valor o una disposición en la pantalla, y el GTS Engine + AI encuentra cada elemento preguntando primero a la aplicación, y a la vista cuando esta no lo dice.
¿Qué pasa cuando un botón cambia a propósito?
La comprobación falla y muestra la imagen esperada y la real una al lado de la otra.Si el cambio es deseado, haga clic en Aceptar la imagen real como esperada en el Informe de confianza y guarde: la prueba queda al día, sin código que editar.
Selenium, Playwright, Cypress, AG Grid, Flutter, Qt, Java, Delphi, Citrix, Chrome, Edge, Firefox y Windows son marcas de sus respectivos propietarios.
Sigue leyendo
Todos los artículos
Fiabilidad de las pruebas
Pruebas inestables: causas, costes y cómo acabar con los falsos positivos
12 min de lectura
Pruebas visuales
Pruebas de capturas de pantalla píxel a píxel perfectas: por qué fallan y qué detecta los bugs visuales reales
12 min de lectura
Automatización de pruebas
Pruebas manuales frente a pruebas automatizadas: por qué las pruebas manuales se quedan cortas en las pruebas de extremo a extremo
15 min de lectura