El modelo de objetos de página (POM) es un patrón de diseño que estructura los scripts de automatización. Su principio consiste en representar cada página web como un objeto independiente, encapsulando sus elementos y operaciones dentro de una clase. Esto aísla los detalles de implementación de la página de los scripts de prueba, lo que facilita el mantenimiento cuando cambia la interfaz.

2. Estrategia ante cambios frecuentes en los elementos de la página.

Se implementa el patrón POM. La ventaja es que solo se requiere actualizar la clase correspondiente a la página modificada, manteniendo los scripts de prueba intactos.

3. Desafíos comunes en la automatización de pruebas.

• Actualizaciones constantes de la interfaz de usuario que obligan a revisar las clases de página.
• Errores en la ejecución, como elementos no localizables o no visibles.
• Necesidad de maximizar la reutilización de código.
• Problemas de localización con componentes dinámicos o editores enriquecidos.

4. Excepciones típicas en Selenium.

• NoSuchElementException: El elemento no existe en el DOM.
• ElementNotInteractableException: El elemento no se puede interactuar (p. ej., está oculto).
• TimeoutException: La espera para un elemento o condición excedió el límite.
• StaleElementReferenceException: La referencia al elemento se volvió obsoleta.

5. Manejo de alertas del navegador.

Se utiliza la interfaz Alert proporcionada por Selenium WebDriver. El flujo consiste en cambiar al contexto de la alerta y luego ejecutar acciones.

from selenium import webdriver
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

# Supongamos que una acción en la página genera la alerta
alert_element = WebDriverWait(driver, 10).until(EC.alert_is_present())
alert = driver.switch_to.alert
texto = alert.text  # Obtener el contenido de la alerta
alert.accept()      # Aceptar la alerta
# alert.dismiss()   # O cancelarla

6. Cambio entre múltiples ventanas o pestañas.

Cuando se abre una nueva ventana, se debe cambiar el foco del controlador a la nueva pestaña.

# Guardar el manejador de la ventana original
original_window = driver.current_window_handle

# Realizar una acción que abre una nueva ventana
# ...

# Obtener todos los manejadores y cambiar al último (nuevo)
all_windows = driver.window_handles
for window in all_windows:
    if window != original_window:
        driver.switch_to.window(window)
        break
# Realizar operaciones en la nueva ventana
# ...
# Regresar a la ventana original
driver.switch_to.window(original_window)

7. Interactuar con elementos dentro de frames.

Cuando un elemento no se localiza, a menudo está contenido dentro de un <iframe>. Primero se debe cambiar el contexto al frame.

# Cambiar al frame por su nombre, id o índice
driver.switch_to.frame("nombre_del_frame")
# o
driver.switch_to.frame(0)  # Primer frame
# o
frame_element = driver.find_element(By.XPATH, "//iframe[@id='mi_frame']")
driver.switch_to.frame(frame_element)

# Realizar operaciones dentro del frame
# ...

# Regresar al contexto principal
driver.switch_to.default_content()

8. Selección de elementos en listas desplegables.

Se utiliza la clase Select para interactuar con elementos <select>.

from selenium.webdriver.support.ui import Select

dropdown = driver.find_element(By.ID, "combo_opciones")
select_obj = Select(dropdown)
select_obj.select_by_visible_text("Opción B")
# También se puede usar select_by_value("valor") o select_by_index(1)

9. Diferencia entre cerrar el navegador y la sesión.

• driver.close(): Cierra la pestaña o ventana actual.
• driver.quit(): Cierra todas las ventanas asociadas al WebDriver y finaliza la sesión, liberando los recursos.

10. Espera implícita vs. Espera explícita.

• Espera implícita (implicitly_wait): Configura un tiempo máximo que el WebDriver debe esperar al buscar caulquier elemento antes de lanzar una excepción. Se aplica globalmente.
• Espera explícita (WebDriverWait): Define condiciones de espera específicas para un elemento o acción en particular. Es más flexible y recomendada.

# Implementación de una espera explícita
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

elemento = WebDriverWait(driver, 15).until(
    EC.visibility_of_element_located((By.ID, "boton_enviar"))
)
elemento.click()

11. Subida de archivos.

Si el elemento de entrada es de tipo <input type="file">, se puede enviar la ruta directa del archivo mediente send_keys().

upload_input = driver.find_element(By.CSS_SELECTOR, "input[type='file']")
upload_input.send_keys("C:\\ruta\\al\\archivo.png")

12. Acciones complejas: ratón y teclado.

La clase ActionChains permite encadenar acciones de interacción.

from selenium.webdriver.common.action_chains import ActionChains

elemento_origen = driver.find_element(By.ID, "arrastrable")
elemento_destino = driver.find_element(By.ID, "zona_destino")

# Ejemplo: arrastrar y soltar
actions = ActionChains(driver)
actions.drag_and_drop(elemento_origen, elemento_destino).perform()

# Ejemplo: pasar el ratón sobre un elemento
menu = driver.find_element(By.ID, "menu")
submenu = driver.find_element(By.ID, "submenu_opcion")
actions.move_to_element(menu).pause(1).click(submenu).perform()

13. Ámbito de las pruebas automatizadas.

Principalmente se enfocan en pruebas de regresión y humo para validar funcionalidades críticas y estables, ahorrando tiempo en ciclos repetitivos.

14. Gestión y ejecución de casos de prueba.

Se emplean marcos de trabajo como unittest o pytest, que proporcionan estructura, descubrimiento de pruebas y generación de informes.

15. Generación de reportes.

Librerías como allure o pytest-html se integran con frameworks como pytest para producir reportes detallados de la ejecución.

16. Estructura de un framwork de automatización.

Un enfoque común es la arquitectura en capas combinada con el patrón POM.

• Capa de Acciones Comunes (Base Page): Métodos genéricos para interactuar con el navegador.
• Capa de Objetos de Página (Page Objects): Clases que modelan las páginas de la aplicación.
• Capa de Casos de Prueba (Test Cases): Scripts que orquestan la lógica de las pruebas.
• Módulos de Soporte: Para configuración, logging, manejo de datos y generación de reportes.

17. Errores en automatización (falsos positivos).

Ocurren por inestabilidad en la localización de elementos, cambios en la aplicación sin actualización correspondiente en los scripts, o problemas de sincronización. La solución implica mejorar la robustez de los localizadores y sincronización.

18. Frameworks de automatización comunes.

• Web: Selenium WebDriver con Python (pytest/unittest), Java (TestNG) o JavaScript (Cypress, Playwright).
• API: Requests (Python), RestAssured (Java), Supertest (JS).
• Móvil: Appium (multiplataforma), UIAutomator2 (Android), XCUITest (iOS).

19. Ciclo de vida típico de la automatización.

1. Análisis de viabilidad y selección de casos.
2. Diseño del framework y preparación del entorno.
3. Desarrollo de scripts de prueba.
4. Ejecución, revisión de resultados y mantenimiento.
5. Integración continua (CI/CD) para ejecuciones programadas.

20. Diferencias entre pruebas web y móviles.

• Plataforma: Web se ejecuta en navegadores; móvil en dispositivos o emuladores.
• Elementos: Los localizadores en móvil a menudo usan accessibility id o resource-id; en web, son más comunes id, name, css.
• Interacciones: Móvil requiere manejo de gestos (swipe, tap prolongado) y orientación.
• Configuración: Appium necesita capacidades (desired_caps) específicas para el dispositivo y aplicación.