A4Q Selenium Tester Examen de práctica #3 — Preguntas y respuestas
Todas las preguntas de este examen de práctica, con la respuesta correcta marcada y una justificación escrita para cada opción a continuación — para leer y repasar, no una prueba cronometrada.
¿Qué afirmación describe correctamente la relación entre la interfaz WebDriver y la clase ChromeDriver en los bindings de Selenium para Java?
ChromeDriver implementa la interfaz WebDriver, por lo que la variable puede declararse con el tipo WebDriver
Correcto — programar contra la interfaz mantiene la prueba independiente del navegador.
WebDriver extiende ChromeDriver, por lo que ChromeDriver es el tipo padre
Invertido — la interfaz es la abstracción y la clase la implementa.
Son clases no relacionadas y deben convertirse (cast) en tiempo de ejecución
Incorrecto — están relacionadas por la relación implements, no requiere cast.
WebDriver es una interfaz; ChromeDriver es una implementación específica del navegador, por eso la declaración recomendada es WebDriver driver = new ChromeDriver();
Durante una ejecución se han abierto varias ventanas del navegador. ¿Cuál es la diferencia entre llamar a driver.close() y driver.quit()?
close() cierra solo la ventana actual; quit() cierra todas las ventanas y finaliza la sesión
Correcto — es el comportamiento definido de ambos comandos.
close() finaliza la sesión; quit() solo cierra la ventana actual
Invertido — quit() es el que finaliza toda la sesión.
Son alias y se comportan igual
Incorrecto — difieren cuando hay más de una ventana abierta.
close() borra cookies; quit() borra la caché del navegador
Incorrecto — ninguno de los comandos borra cookies ni caché.
close() cierra solo la ventana/pestaña actual; quit() cierra todas las ventanas y finaliza la sesión de WebDriver.
¿En qué se diferencian findElement() y findElements() cuando ningún elemento coincide con el localizador?
findElement() lanza NoSuchElementException, mientras que findElements() devuelve una lista vacía
Correcto — findElements no lanza excepción ante ausencia de coincidencias, devuelve tamaño 0.
Ambos lanzan NoSuchElementException
Incorrecto — findElements devuelve una lista vacía en lugar de lanzar.
Ambos devuelven null
Incorrecto — findElement lanza excepción, no devuelve null.
findElement() devuelve una lista vacía; findElements() lanza
Invertido — es al revés.
findElement() lanza NoSuchElementException; findElements() devuelve una lista vacía.
¿Cuáles de las siguientes son implementaciones legítimas específicas del navegador de la interfaz WebDriver? (Elija dos.)
ChromeDriver
Correcto — la implementación del driver para Google Chrome.
FirefoxDriver
Correcto — la implementación del driver para Mozilla Firefox (mediante GeckoDriver).
SeleniumIDEDriver
Incorrecto — no existe tal clase; Selenium IDE es una herramienta de grabación y reproducción.
RemoteBrowserManager
Incorrecto — no es una clase real de Selenium; las ejecuciones remotas usan RemoteWebDriver.
ChromeDriver y FirefoxDriver son implementaciones reales de WebDriver. SeleniumIDEDriver y RemoteBrowserManager no existen en los bindings.
Un tester escribe el siguiente código Java contra un formulario de login: driver.get("https://shop.example/login"); WebElement user = driver.findElement(By.id("username")); user.sendKeys("alice"); WebElement pass = driver.findElement(By.id("password")); pass.sendKeys("secret"); driver.findElement(By.id("login-btn")).click(); El campo con id 'username' ya contiene el valor 'guest' de un paso anterior. ¿Qué valor tiene el campo tras ejecutar el código?
guestalice
Correcto — sendKeys añade; sin clear() permanece 'guest' y se agrega 'alice'.
alice
Incorrecto — esto requeriría llamar a clear() antes de sendKeys, lo que no ocurre.
guest
Incorrecto — sendKeys sí agrega 'alice', el valor cambia.
Se lanza una excepción porque el campo no está vacío
Incorrecto — sendKeys no exige un campo vacío y no lanza nada aquí.
sendKeys() añade texto al contenido existente; no lo borra. Así que 'guest' + 'alice' = 'guestalice'. Para reemplazar, llamar antes a user.clear().
Necesita leer el valor actual mostrado dentro de un cuadro de texto <input>. ¿Qué enfoque es correcto?
element.getAttribute("value")
Correcto — el contenido del input se expone mediante el atributo/propiedad value.
element.getText()
Incorrecto — getText() devuelve el texto interno visible, que para un <input> suele estar vacío.
element.getTagName()
Incorrecto — eso devuelve la etiqueta del elemento ('input'), no su valor.
element.getCssValue("value")
Incorrecto — getCssValue lee propiedades CSS, no el valor del campo.
En los controles de formulario el valor visible está en el atributo/propiedad 'value', por eso se usa getAttribute("value"). getText() devuelve el texto visible de elementos que no son input y suele estar vacío para inputs.
¿Qué API de Selenium está diseñada para gestos de usuario complejos como pasar el ratón sobre un menú, arrastrar y soltar o pulsar una combinación de teclas?
La clase Actions
Correcto — modela gestos de entrada compuestos mediante un builder y perform().
La clase Select
Incorrecto — Select maneja solo opciones de listas desplegables <select>.
La interfaz Alert
Incorrecto — Alert maneja diálogos JavaScript (alert/confirm/prompt).
La interfaz Navigation
Incorrecto — Navigation maneja back/forward/refresh/to, no gestos.
La clase Actions construye secuencias de interacciones de bajo nivel (moveToElement, dragAndDrop, keyDown, etc.) y las ejecuta con perform().
Una lista desplegable <select id='country'> permite elegir un país. ¿Cuál es la forma más limpia con un helper de Selenium para elegir la opción con la etiqueta 'Germany'?
new Select(element).selectByVisibleText("Germany")
Correcto — la clase Select es la API prevista para listas desplegables.
element.sendKeys("Germany")
Funciona parcialmente en algunos navegadores, pero no es el enfoque fiable previsto para <select>.
element.click() y luego escribir el texto
Incorrecto — un <select> nativo no acepta texto libre de esta forma.
new Dropdown(element).choose("Germany")
Incorrecto — no existe una clase Dropdown en los bindings de Selenium.
Envolver el elemento en la clase Select y llamar a selectByVisibleText("Germany"). Select ofrece métodos específicos para elementos <select>.
Según las buenas prácticas de Selenium, ¿qué estrategia de localización debe preferirse cuando el elemento objetivo tiene un atributo id único y estable?
By.id
Correcto — la primera opción preferida cuando existe un id único y estable.
Un XPath absoluto desde la raíz <html>
Incorrecto — el XPath absoluto es la estrategia más frágil y se rompe ante cualquier cambio estructural.
By.linkText en un enlace cercano
Incorrecto — apunta a un elemento distinto y depende del texto visible.
By.tagName
Incorrecto — el nombre de etiqueta suele coincidir con muchos elementos y no es único.
By.id es el localizador más rápido y robusto porque los id deben ser únicos y rara vez se ven afectados por cambios de diseño.
Considere este fragmento HTML: <div class="cart"> <ul> <li class="item" data-sku="A100">Keyboard</li> <li class="item" data-sku="B200">Mouse</li> <li class="item" data-sku="C300">Monitor</li> </ul> </div> ¿Qué localizador único selecciona exactamente el <li> del Mouse y nada más?
By.cssSelector("li.item[data-sku='B200']")
Correcto — el valor único data-sku aísla exactamente la fila del Mouse.
By.className("item")
Incorrecto — coincide con los tres elementos <li>.
By.tagName("li")
Incorrecto — también coincide con los tres elementos de lista.
By.cssSelector(".cart ul li")
Incorrecto — selecciona todos los <li> descendientes, no solo el Mouse.
El atributo data-sku es único por ítem, por lo que el selector CSS li.item[data-sku='B200'] localiza el Mouse. Seleccionar por índice o solo por clase coincide con varios ítems.
Debe localizar un botón Submit sin id ni clase estable, pero que siempre contiene el texto visible 'Place order'. ¿Qué XPath lo localiza de forma fiable independientemente del marcado circundante?
//button[normalize-space()='Place order']
Correcto — coincide por texto recortado y tolera espacios circundantes.
/html/body/div[2]/form/div[3]/button
Incorrecto — una ruta absoluta se rompe cuando cambia la estructura circundante.
//button[1]
Incorrecto — basado en índice y coincide con el primer botón que aparezca.
//button[@id='place-order']
Incorrecto — el elemento no tiene id, por lo que esto no coincide con nada.
//button[normalize-space()='Place order'] coincide por el texto visible recortado y es robusto ante espacios y posición. Una ruta absoluta o basada en índice es frágil.
¿Cuál es la diferencia clave entre los selectores CSS 'div p' (con espacio) y 'div > p'?
El espacio selecciona cualquier <p> descendiente; '>' selecciona solo un <p> hijo directo
Correcto — combinador de descendiente vs. combinador de hijo.
Son equivalentes; el '>' es solo cosmético
Incorrecto — seleccionan conjuntos de elementos distintos.
El espacio selecciona hijos directos; '>' selecciona cualquier descendiente
Invertido — es al revés.
'>' solo funciona en XPath, no en CSS
Incorrecto — '>' es un combinador de hijo válido en CSS.
'div p' coincide con cualquier <p> descendiente de un <div> a cualquier profundidad; 'div > p' coincide solo con <p> que sea hijo directo de un <div>.
Dado el elemento <a href="/help" class="nav-link active">Help Center</a>, ¿cuáles de los siguientes localizadores lo localizarían correctamente? (Elija dos.)
By.linkText("Help Center")
Correcto — coincide el texto visible exacto del enlace.
By.cssSelector("a.nav-link.active")
Correcto — encadenar ambos nombres de clase en CSS es válido y coincide con este enlace.
By.className("nav-link active")
Incorrecto — By.className acepta un solo nombre de clase, no una combinación separada por espacios.
By.linkText("Help")
Incorrecto — linkText requiere el texto completo; para una subcadena use partialLinkText.
By.linkText("Help Center") coincide con el texto visible completo; By.cssSelector("a.nav-link.active") coincide con ambas clases. By.className no admite dos clases en una sola cadena, y el texto parcial dado no coincide.
¿Qué afirmación sobre By.name y By.id es correcta?
id debe ser único por página, mientras que name puede compartirse entre varios elementos
Correcto — p. ej., un grupo de radios comparte un name.
name siempre debe ser único, id puede repetirse
Invertido — es id el que debería ser único.
Ninguno puede usarse con findElement
Incorrecto — tanto By.id como By.name funcionan con findElement.
By.name solo funciona en elementos ancla <a>
Incorrecto — name aplica a controles de formulario y otros, no solo anclas.
Ambos son localizadores basados en atributos, pero solo id debe ser único por documento; name puede compartirse entre varios elementos (p. ej., radios de un mismo grupo).
Una tabla de resultados tiene filas como: <tr><td class="name">Order 42</td><td class="status">Shipped</td></tr> Necesita la celda de estado que está en la misma fila que la celda de nombre con 'Order 42'. ¿Qué XPath expresa esta relación?
//td[@class='name'][normalize-space()='Order 42']/following-sibling::td[@class='status']
Correcto — se ancla en el texto conocido y salta a la celda hermana de estado.
//td[@class='status']
Incorrecto — coincide con cada celda de estado, no con la ligada a Order 42.
//td[@class='name']/td[@class='status']
Incorrecto — la celda de estado es hermana, no hija de la celda de nombre.
//tr[normalize-space()='Order 42']
Incorrecto — selecciona la fila, no la celda de estado solicitada.
Partir de la celda de nombre por su texto y pasar a la celda hermana de estado: //td[@class='name'][normalize-space()='Order 42']/following-sibling::td[@class='status'].
¿Qué selector CSS coincide con un <input> cuyo atributo id empieza por el prefijo 'user_'?
input[id^='user_']
Correcto — ^= significa 'el valor del atributo empieza por'.
input[id$='user_']
Incorrecto — $= significa 'termina con', no 'empieza por'.
input[id*='user_']
Casi, pero *= significa 'contiene en cualquier lugar', no específicamente un prefijo.
input[id~='user_']
Incorrecto — ~= coincide con una palabra separada por espacios, para listas tipo clase.
El operador 'empieza por' es ^=, por lo que input[id^='user_'] coincide con id como user_name, user_email, etc.
¿Cuál es el propósito principal del patrón de diseño Page Object Model (POM) en la automatización con Selenium?
Encapsular los localizadores y acciones de una página en una clase, mejorando el mantenimiento y la reutilización
Correcto — ese es exactamente el objetivo de mantenibilidad de POM.
Hacer que las pruebas sean más rápidas cacheando respuestas HTTP
Incorrecto — POM es un patrón estructural, no un mecanismo de rendimiento/caché.
Eliminar la necesidad de una instancia de WebDriver
Incorrecto — los page objects siguen usando un WebDriver internamente.
Generar datos de prueba automáticamente
Incorrecto — POM no se ocupa de la generación de datos de prueba.
POM encapsula los localizadores e interacciones de una página en una clase dedicada, de modo que los cambios de UI se corrigen en un solo lugar y las pruebas siguen siendo legibles y mantenibles.
En un Page Object bien diseñado, ¿dónde deben ubicarse normalmente las aserciones de la prueba (p. ej., comprobar que un mensaje de error es igual a una cadena esperada)?
En los métodos de prueba, no dentro del page object
Correcto — mantiene los page objects reutilizables y sin lógica específica de la prueba.
Dentro de cada definición de localizador
Incorrecto — los localizadores solo identifican elementos; no contienen aserciones.
En el constructor de WebDriver
Incorrecto — la configuración del driver no tiene nada que ver con las aserciones.
En la consola de desarrollador del navegador
Incorrecto — eso no forma parte de la estructura de la prueba automatizada.
Las aserciones pertenecen a los métodos de prueba/paso, no al page object. El page object expone estado (getters, métodos de acción); la prueba decide qué es correcto.
Un tester escribe este método de page object para una página de login: public HomePage login(String u, String p) { driver.findElement(By.id("user")).sendKeys(u); driver.findElement(By.id("pass")).sendKeys(p); driver.findElement(By.id("submit")).click(); return new HomePage(driver); } ¿Por qué devolver un nuevo objeto HomePage se considera buena práctica de POM aquí?
Modela la navegación resultante y permite encadenar con fluidez acciones de HomePage
Correcto — devolver el objeto de la página destino refleja el flujo de navegación real.
Porque afirma que el login tuvo éxito
Incorrecto — el método no contiene aserción; la verificación queda en la prueba.
Porque cierra la sesión de WebDriver
Incorrecto — aquí nada finaliza el driver.
Porque evita usar localizadores
Incorrecto — el método sigue usando localizadores By.id.
Un login exitoso navega a la página de inicio, por lo que devolver el siguiente page object permite encadenar llamadas con fluidez y modela el flujo real de páginas. No realiza ninguna aserción por sí mismo.
¿Qué ventaja aporta POM cuando un desarrollador renombra el id del botón de login de 'login' a 'signin'?
El localizador se corrige en un solo lugar, por lo que no hay que editar los scripts de prueba
Correcto — los localizadores centralizados son el beneficio clave de mantenibilidad de POM.
Selenium detecta el cambio de nombre automáticamente
Incorrecto — Selenium no puede adivinar un id renombrado; una persona debe actualizar el localizador.
Los datos de prueba se regeneran
Incorrecto — renombrar un localizador no tiene relación con los datos de prueba.
El navegador ya no necesita un driver
Incorrecto — sin relación; siempre se requiere un driver.
Solo hay que cambiar el único localizador dentro del page object; todas las pruebas que llaman al método del page object siguen funcionando sin cambios.
¿Cuáles de las siguientes son características recomendadas de una clase page object bien diseñada? (Elija dos.)
Expone métodos de acción legibles (p. ej., login, search) en vez de localizadores en crudo
Correcto — las pruebas deben hablar en acciones de negocio, no en detalles de elementos.
Mantiene sus localizadores privados/encapsulados dentro de la clase
Correcto — la encapsulación mantiene el mantenimiento localizado en el page object.
Contiene las aserciones de la prueba para cada escenario
Incorrecto — las aserciones pertenecen a las pruebas, para mantener reutilizables los page objects.
Usa Thread.sleep() antes de cada acción para dar estabilidad
Incorrecto — las esperas fijas son un antipatrón; usar esperas explícitas.
Un page object debe exponer métodos de acción/getter significativos y mantener los localizadores privados dentro de la clase. No debe incrustar aserciones ni esperas fijas codificadas.
¿Cómo apoya la PageFactory al Page Object Model en los bindings de Selenium para Java?
Inicializa campos anotados con @FindBy para que las búsquedas de elementos se conecten automáticamente
Correcto — esa es la función de PageFactory.initElements.
Lanza el navegador automáticamente
Incorrecto — el driver, no PageFactory, lanza el navegador.
Escribe las aserciones por ti
Incorrecto — PageFactory no tiene relación con las aserciones.
Convierte XPath en CSS automáticamente
Incorrecto — PageFactory no realiza tal conversión.
PageFactory inicializa campos anotados con @FindBy mediante PageFactory.initElements(driver, this), aportando WebElements localizados de forma diferida y reduciendo el código repetitivo.
¿Cuál es la diferencia esencial entre una espera implícita y una espera explícita en Selenium WebDriver?
La espera implícita se aplica globalmente a todas las búsquedas; la explícita apunta a una condición específica
Correcto — esa es la distinción definitoria.
La espera implícita es para un elemento específico; la explícita es global
Invertido — es al revés.
Ambas pausan el hilo un número fijo de segundos sin importar el estado
Incorrecto — eso describe Thread.sleep, no las esperas implícita/explícita, que son condicionales.
No hay diferencia; los términos son intercambiables
Incorrecto — se comportan de forma bastante distinta.
Una espera implícita fija un tiempo de sondeo global para las búsquedas de elementos; una espera explícita (WebDriverWait + ExpectedConditions) espera una condición específica sobre un elemento específico.
¿Por qué se desaconseja en general usar Thread.sleep(5000) para esperar un elemento en pruebas de Selenium?
Desperdicia tiempo cuando el elemento está listo pronto pero puede quedarse corto en cargas lentas, causando lentitud e inestabilidad
Correcto — las esperas fijas son lentas y poco fiables.
Porque Thread.sleep no es compatible con Java
Incorrecto — es Java válido; el problema es que es una mala estrategia de sincronización.
Porque borra cookies como efecto secundario
Incorrecto — dormir no afecta a las cookies.
Porque solo funciona en modo headless
Incorrecto — Thread.sleep funciona sin importar el modo headless.
Una espera fija siempre aguarda todo el tiempo aunque el elemento aparezca antes (lento) y aún puede ser demasiado corta en una carga lenta (inestable). Las esperas explícitas sondean y continúan en cuanto se cumple la condición.
Un tester quiere hacer clic en un botón solo cuando sea clicable, esperando hasta 10 segundos. ¿Qué fragmento es correcto? A) new WebDriverWait(driver, Duration.ofSeconds(10)).until(ExpectedConditions.elementToBeClickable(By.id("go"))).click(); B) driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)); driver.findElement(By.id("go")).click(); ¿Cuál es la solución de espera explícita adecuada para la condición de clicable?
Opción A
Correcto — elementToBeClickable es la condición que cumple el requisito.
Opción B
Incorrecto — la espera implícita solo garantiza presencia, no que el elemento sea clicable.
Ambas son igualmente correctas
Incorrecto — solo A espera la clicabilidad; B solo espera la presencia.
Ninguno compilará
Incorrecto — ambos son Java válido; la cuestión es cuál cumple el requisito de clicable.
La opción A usa WebDriverWait con la ExpectedCondition elementToBeClickable — exactamente la espera explícita necesaria. La opción B es una espera implícita que solo espera la presencia, no la clicabilidad.
Una suite de pruebas establece una espera implícita de 10 segundos y, en una prueba, también usa un WebDriverWait explícito de 15 segundos sobre el mismo elemento. El equipo observa esperas impredecibles, a veces muy largas. ¿Cuál es la causa más probable?
Mezclar esperas implícitas y explícitas, cuyos tiempos pueden combinarse de forma impredecible
Correcto — la recomendación oficial es no combinar ambos mecanismos de espera.
La espera explícita siempre anula la implícita, por lo que no puede haber conflicto
Incorrecto — no se anulan limpiamente; por eso se desaconseja mezclarlas.
Las esperas implícitas se ignoran una vez importado WebDriverWait
Incorrecto — importar una clase no desactiva la configuración de espera implícita.
El driver del navegador es demasiado antiguo
Incorrecto — el síntoma apunta a la mezcla de esperas, no a la versión del driver.
Mezclar esperas implícitas y explícitas puede hacer que sus tiempos de espera se combinen de forma impredecible. Se recomienda usar solo esperas explícitas y no establecer una espera implícita.
¿Qué ExpectedCondition debe usar para esperar hasta que un elemento esté presente en el DOM y visible en la página antes de leer su texto?
ExpectedConditions.visibilityOfElementLocated(locator)
Correcto — asegura presencia y visibilidad.
ExpectedConditions.invisibilityOfElementLocated(locator)
Incorrecto — eso espera a que el elemento desaparezca, lo contrario de lo necesario.
ExpectedConditions.numberOfWindowsToBe(1)
Incorrecto — comprueba el número de ventanas, sin relación con la visibilidad del elemento.
ExpectedConditions.titleIs("Home")
Incorrecto — comprueba el título de la página, no la presencia/visibilidad del elemento.
visibilityOfElementLocated espera a que el elemento esté tanto presente en el DOM como mostrado (tamaño > 0, visible), que es lo necesario antes de leer el texto.
¿Qué distingue a un FluentWait de un WebDriverWait básico?
FluentWait permite fijar una frecuencia de sondeo personalizada e ignorar excepciones específicas
Correcto — esos son los ajustes adicionales que expone FluentWait.
FluentWait se ejecuta sin ninguna instancia de WebDriver
Incorrecto — sigue operando sobre un driver/elemento.
FluentWait solo puede esperar títulos de página
Incorrecto — puede esperar cualquier condición mediante una Function/ExpectedCondition.
FluentWait desactiva todos los tiempos de espera
Incorrecto — sigue teniendo un tiempo total; solo añade control de sondeo/ignorar.
FluentWait permite configurar el intervalo de sondeo y qué tipos de excepción ignorar, dando un control más fino que un WebDriverWait por defecto (que es en sí un FluentWait especializado).
¿Qué par de comandos carga ambos una URL dada en la ventana actual del navegador?
driver.get(url) y driver.navigate().to(url)
Correcto — ambos cargan la URL; get es abreviatura de navigate().to.
driver.open(url) y driver.load(url)
Incorrecto — ni open() ni load() existen en la API de WebDriver.
driver.goTo(url) y driver.browse(url)
Incorrecto — no son métodos reales de WebDriver.
driver.get(url) y driver.click(url)
Incorrecto — click() actúa sobre un elemento, no carga una URL.
driver.get(url) y driver.navigate().to(url) abren ambos la URL indicada; get() es esencialmente una forma abreviada de navigate().to().
Un tester ejecuta esta secuencia: driver.navigate().to("https://site/a"); driver.navigate().to("https://site/b"); driver.navigate().back(); driver.navigate().forward(); ¿Qué página se muestra al final?
https://site/b
Correcto — atrás a /a y luego adelante vuelve a /b.
https://site/a
Incorrecto — back() llega a /a, pero forward() luego avanza a /b.
Una página en blanco
Incorrecto — el historial aún contiene ambas páginas; nada queda en blanco.
Un error, porque forward() no tiene historial
Incorrecto — back() creó historial hacia adelante, así que forward() tiene éxito.
Tras cargar a y luego b, back() vuelve a a y forward() avanza de nuevo a b. Por tanto, la página final es /b.
Después de que un enlace abra una segunda pestaña, ¿por qué debe llamar a driver.switchTo().window(handle) antes de interactuar con la nueva pestaña?
El foco de WebDriver permanece en la pestaña original hasta que cambie explícitamente al handle de la nueva ventana
Correcto — el driver no sigue automáticamente las pestañas recién abiertas.
Porque la nueva pestaña tiene una instancia de WebDriver distinta
Incorrecto — todas las pestañas de una sesión comparten el mismo driver; solo cambia el foco.
Porque las cookies no se comparten entre pestañas
Incorrecto — el motivo es el foco, no las cookies.
Porque la espera implícita se reinicia en la nueva pestaña
Incorrecto — el cambio se refiere al foco de comandos, no al estado de espera.
WebDriver mantiene el foco de comandos en la ventana original hasta que cambie explícitamente. Los comandos enviados antes del cambio siguen apuntando a la pestaña antigua.
Aparece un diálogo JavaScript confirm() preguntando 'Delete this item?'. ¿Qué API de Selenium se usa para aceptarlo?
driver.switchTo().alert().accept()
Correcto — accept() de la interfaz Alert confirma el diálogo.
driver.findElement(By.id("ok")).click()
Incorrecto — un diálogo nativo del navegador no forma parte del DOM, no puede localizarse como elemento.
driver.navigate().refresh()
Incorrecto — refrescar no confirma el diálogo.
driver.quit()
Incorrecto — quit finaliza la sesión en lugar de manejar el diálogo.
Cambiar al alert y aceptarlo: driver.switchTo().alert().accept(). La interfaz Alert maneja diálogos alert/confirm/prompt.
¿Cuáles de los siguientes proporciona la interfaz driver.navigate()? (Elija dos.)
back()
Correcto — navigate().back() va a la entrada anterior del historial.
refresh()
Correcto — navigate().refresh() recarga la página actual.
maximize()
Incorrecto — maximize() pertenece a driver.manage().window(), no a navigate().
accept()
Incorrecto — accept() pertenece a la interfaz Alert, no a navigate().
navigate() ofrece to(url), back(), forward() y refresh(). No ofrece maximize() (eso es de Window) ni un método alert().
Para interactuar con elementos dentro de un <iframe>, ¿qué debe hacer primero una prueba?
Cambiar al frame con driver.switchTo().frame(...)
Correcto — el contenido del iframe solo es accesible tras cambiar al frame.
Refrescar la página para fusionar el iframe en el DOM
Incorrecto — refrescar no fusiona los contextos de frame.
Fijar una espera implícita de al menos 30 segundos
Incorrecto — esperar no elimina la necesidad de cambiar el contexto de frame.
Eliminar el iframe con JavaScript
Incorrecto — eliminar el frame destruye justamente los elementos que se quieren usar.
Hay que cambiar el contexto al frame con driver.switchTo().frame(...) antes de poder alcanzar sus elementos, y volver con switchTo().defaultContent().
Una prueba encuentra una lista de filas, guarda el primer WebElement en una variable y luego dispara una llamada AJAX que vuelve a renderizar toda la tabla. Cuando más tarde llama a .click() sobre el elemento guardado, Selenium lanza StaleElementReferenceException. ¿Cuál es la explicación y solución correctas?
La referencia antigua apunta a un nodo del DOM eliminado; volver a localizar el elemento tras el re-render
Correcto — eso es precisamente lo que significa un elemento obsoleto y cómo resolverlo.
El elemento nunca se encontró; capturar NoSuchElementException en su lugar
Incorrecto — el elemento sí se encontró originalmente; quedó obsoleto tras el re-render.
Añadir Thread.sleep(1000) antes del clic y reutilizar la misma referencia
Incorrecto — dormir no revive una referencia obsoleta; el nodo ya no existe.
Cambiar al frame padre antes de hacer clic
Incorrecto — no hay ningún frame; el problema es la referencia de nodo obsoleta.
La referencia guardada apunta a un nodo del DOM que fue eliminado y recreado por el re-render, por lo que está obsoleta. La solución es volver a localizar el elemento tras el cambio del DOM (idealmente tras una espera explícita), no reutilizar la referencia antigua.
¿Qué práctica reduce más directamente las pruebas de Selenium inestables causadas por problemas de temporización?
Sustituir las esperas fijas por esperas explícitas sobre condiciones precisas
Correcto — esperar por condiciones es el remedio estándar para la inestabilidad de temporización.
Aumentar cada Thread.sleep a 30 segundos
Incorrecto — eso hace las pruebas lentas y aún frágiles, no estables.
Ejecutar toda la suite solo en modo headless
Incorrecto — el modo headless no aborda la sincronización de temporización.
Capturar e ignorar todas las excepciones en la prueba
Incorrecto — tragarse las excepciones oculta fallos en vez de estabilizar la prueba.
Sustituir las esperas fijas por esperas explícitas sobre condiciones precisas sincroniza la prueba con el estado de la aplicación y reduce la inestabilidad por temporización.
¿Por qué depender de datos de prueba fijos y específicos del entorno (p. ej., un usuario que solo existe en un servidor) amenaza la estabilidad de las pruebas?
La prueba puede fallar en otros entornos donde esos datos falten o cambien, sin relación con un defecto real
Correcto — los datos acoplados al entorno hacen los resultados no portables e inestables.
Porque Selenium no puede leer datos de prueba en absoluto
Incorrecto — las pruebas de Selenium sí usan datos; el problema es el acoplamiento a un entorno.
Porque los datos fijos aceleran demasiado las pruebas
Incorrecto — la velocidad no es el problema de estabilidad aquí.
Porque obliga a usar localizadores XPath
Incorrecto — los datos de prueba no determinan la estrategia de localización.
Si los datos faltan o cambian en otro entorno, la prueba falla por motivos ajenos al código bajo prueba. Las pruebas estables preparan o aíslan sus propios datos.
Selenium informa de ElementClickInterceptedException al hacer clic en un botón. ¿Qué indica esto normalmente?
Otro elemento cubre el objetivo en el punto de clic
Correcto — ese es el significado de una intercepción de clic.
El elemento no existe en el DOM
Incorrecto — eso sería NoSuchElementException; aquí el elemento existe pero está cubierto.
La versión del driver del navegador es incompatible
Incorrecto — una incompatibilidad del driver produce otros errores de sesión, no intercepción de clic.
El título de la página es incorrecto
Incorrecto — el título no tiene relación con la intercepción de clic.
Otro elemento (un overlay, una cabecera fija, un banner de cookies o un spinner) cubre el objetivo en el punto de clic, por lo que el clic recaería en el elemento que lo cubre. Esperar a que desaparezca el overlay o desplazar el objetivo a una zona despejada.
¿Cuáles de las siguientes ayudan a que una suite de Selenium sea más independiente y estable? (Elija dos.)
Cada prueba prepara y limpia sus propias precondiciones
Correcto — las pruebas autocontenidas no heredan estado roto de otras.
Las pruebas no dependen de ejecutarse en un orden concreto
Correcto — la independencia de orden permite ejecuciones paralelas y parciales seguras.
Todas las pruebas comparten una única sesión de navegador que nunca se reinicia
Incorrecto — el estado compartido y sin reiniciar se filtra entre pruebas y causa inestabilidad.
Las pruebas posteriores dependen de datos creados por las anteriores
Incorrecto — las dependencias de datos encadenadas hacen que un fallo se propague a muchas.
Que cada prueba prepare y limpie su propio estado y evitar dependencias de orden entre pruebas son prácticas clave de estabilidad. Compartir una sola sesión de navegador entre todas las pruebas y depender del orden de ejecución perjudican la independencia.
¿Por qué se considera un riesgo de estabilidad un XPath absoluto como /html/body/div[3]/div[2]/form/button?
Cualquier cambio en la estructura del DOM circundante lo rompe, aunque el elemento objetivo no cambie
Correcto — las rutas absolutas son frágiles ante cambios de diseño.
El XPath absoluto no es compatible con los navegadores modernos
Incorrecto — es totalmente compatible; el problema es la fragilidad, no la compatibilidad.
Siempre coincide con varios elementos
Incorrecto — una ruta absoluta suele coincidir con un nodo; el problema es la fragilidad.
No puede usarse con findElement
Incorrecto — By.xpath funciona con findElement; la preocupación es la mantenibilidad.
Los XPath absolutos codifican toda la ruta del DOM, por lo que cualquier cambio estructural (un div envoltorio añadido, secciones reordenadas) rompe el localizador aunque el elemento objetivo siga existiendo. Es preferible usar localizadores estables basados en atributos.