Integración de perfiles de navegador con Selenium

Selenium controla navegadores mediante el estándar WebDriver. Un perfil añade estado y configuración a esa sesión, por lo que integrarlo va más allá de elegir un ejecutable. El runner debe poseer el lanzamiento, el directorio de almacenamiento, la política de red, la limpieza y la evidencia de la sesión completa. Esa responsabilidad evita que dos workers escriban en el mismo perfil y facilita reproducir fallos.

Un perfil no garantiza que un sitio acepte una tarea automatizada, ni Selenium cambia las reglas de acceso del sitio. Use la integración solo con aplicaciones propias o autorizadas para pruebas. Antes de iniciar, defina la tarea del usuario y el resultado esperado, mantenga las credenciales fuera de los fixtures y deténgase cuando la aplicación indique un límite de acceso o de política.

La configuración más fiable tiene un runner, un proceso de navegador activo y un único responsable del perfil. El almacenamiento persistente es una decisión del producto, no un requisito predeterminado: una prueba funcional breve puede usar un directorio temporal aislado, mientras que una prueba de continuidad puede usar un directorio persistente administrado si ya se definieron retención, acceso y eliminación. Documente la decisión.

Propiedad del lanzamiento

El runner debe elegir explícitamente el binario cuando hay varias instalaciones. Registre versiones de navegador, driver y runner, la revisión del runner y el binario elegido junto al resultado. Los ejemplos oficiales de Selenium para Chrome muestran la selección del binario y los argumentos; no establecen compatibilidad con cualquier navegador personalizado.

Ejemplo mínimo de inicio

Este ejemplo de Python selecciona un binario y un directorio user-data de Chromium aislado. Sustituya ambas rutas por rutas administradas en el nodo y visite solo una aplicación autorizada para la prueba.

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.binary_location = "/path/to/approved/browser"
options.add_argument("--user-data-dir=/path/to/browser-state")

driver = webdriver.Chrome(options=options)
try:
    driver.get("https://app.example.test/settings")
    assert driver.current_url.startswith("https://app.example.test/")
finally:
    driver.quit()

El directorio user-data guarda el estado de ejecución de Chromium. Una configuración de perfil separada describe el comportamiento elegido para la sesión. Este ejemplo solo muestra la propiedad de Selenium y del user-data de Chromium. Si una aplicación tiene además una configuración de perfil, pásela únicamente por el punto de integración documentado por ese producto; no deduzca una opción a partir de este ejemplo, no use la misma ruta ni copie la configuración dentro del directorio user-data.

El driver y el navegador deben ser compatibles para establecer una sesión WebDriver. Las herramientas de detección de versiones pueden ayudar, pero los entornos administrados suelen fijar ambos componentes para repetir las pruebas. Si falla la creación de sesión, confirme primero el binario elegido y el driver, antes de modificar el perfil: una incompatibilidad de lanzamiento no se corrige cambiando cookies, locale ni estado guardado.

El runner debe ser la única capa que controle el ciclo del proceso: inicia el driver, este inicia o conecta con el navegador previsto según el diseño aprobado y el mismo runner cierra la sesión. Mezclar un navegador iniciado manualmente, un driver automático y un segundo script de limpieza puede dejar procesos o bloqueos; hágalo solo si las responsabilidades están documentadas.

En un despliegue remoto, el directorio del perfil debe existir en el nodo que ejecuta el navegador, no solo en la máquina que envía los comandos. Ese nodo también interpreta las rutas del binario, las descargas, los certificados y la red. Un Grid debe ofrecer capacidades de nodo y una política de almacenamiento estables, sin recibir rutas locales que no existan en el host remoto.

Clasifique el fallo antes de reintentar: binario no disponible, driver incompatible, directorio de perfil ilegible, bloqueo existente o navegador que sale durante el inicio requieren responsables distintos. Repetir con las mismas entradas puede dejar más procesos huérfanos sin aportar evidencia.

El lanzamiento debe conservar el aislamiento normal de procesos del navegador y los controles del host requeridos por el despliegue. No reduzca sandbox, permisos de archivos ni validación de certificados para iniciar una sesión. Si el entorno no cumple los requisitos, márquelo como no compatible y corrija la imagen del host. Guarde secretos en el almacén de credenciales de la plataforma y pase solo las referencias necesarias; el registro puede indicar que había autenticación disponible, pero nunca copiar secretos ni conservar contraseñas o códigos de recuperación en capturas.

Límite del perfil y del almacenamiento

Un perfil de Chromium contiene preferencias, bases de datos, cachés y estado de extensiones. No debe modificarse mientras el navegador lo usa. Asigne un directorio diferente a cada sesión concurrente para evitar escrituras y bloqueos compartidos. La documentación de Chromium sobre el directorio de datos de usuario distingue ese directorio de sus subdirectorios de perfiles y documenta el argumento de inicio; una configuración de producto independiente no sustituye a ninguno de ellos.

Elija almacenamiento efímero o persistente según la tarea. El efímero permite empezar desde un estado vacío conocido, por ejemplo en una prueba de primera ejecución o de consentimiento. El persistente sirve para comprobar una continuidad autorizada en la que debe sobrevivir la misma relación de usuario tras reiniciar. Para este último, defina responsable, plazo de retención, controles de acceso, decisión sobre copias de seguridad y procedimiento documentado de reinicio.

No copie un directorio de perfil activo. Cierre el navegador antes de copiar un fixture administrado, asigne a la copia un identificador propio y compruebe que se abre antes de usarla en una suite más amplia. Si contiene estado de cuenta o datos personales, sustitúyalos por una cuenta sintética o consiga autorización explícita y aplique la política habitual de eliminación.

Las cookies, el almacenamiento local, los datos de service workers, los permisos y el historial de descargas pueden afectar a ejecuciones posteriores; registre qué debe persistir. No vacíe automáticamente el directorio si falla una prueba: ponga la sesión en cuarentena, conserve un resultado mínimo y después reiníciela o retírela según la política.

Separe configuración, datos de usuario, credenciales, fixtures y resultados. La guía de gestión de perfiles describe un ciclo de vida más amplio.

El disco local, un volumen de red y un montaje de contenedor pueden diferir en bloqueo, latencia, propiedad y limpieza. Valide el tipo de almacenamiento usado en producción, deje espacio para bases del navegador y descargas y trate un volumen lleno como fallo de infraestructura. Haga copias de perfiles persistentes solo con el navegador cerrado y aplique a la copia la misma política de acceso y eliminación que al original.

Red, locale y contexto de aplicación

Defina red y locale antes del arranque. Un cambio silencioso de ruta dentro de la misma sesión mezcla estados que luego son difíciles de explicar.

Si la prueba requiere proxy, use la ruta aprobada del navegador y verifíquela mediante un endpoint que controle.

No incluya credenciales del proxy ni URI completas en registros, informes o capturas; oculte contraseñas y códigos de recuperación.

Locale abarca idioma, zona horaria, teclado, formato de fecha y datos regionales de la cuenta de prueba. Declare los valores que necesita el recorrido y manténgalos compatibles con el contexto de red. Para probar varias regiones, use perfiles o sesiones separados para que cookies y preferencias guardadas no se crucen.

Las capabilities deben representar cómo se inicia la sesión sin convertirse en una colección copiada de flags. Mantenga una configuración pequeña y propia por entorno admitido, elimine opciones sin requisito documentado y valide el recorrido completo tras actualizar navegador o driver. Un inicio correcto no garantiza que descargas, notificaciones, permisos de medios o tareas largas funcionen como se espera.

La aplicación también necesita un responsable de su estado. Use cuentas de prueba sintéticas cuando sea posible, aísle cada cuenta en su perfil y no la ejecute en paralelo si el producto no lo admite. Haga explícitos los pasos de inicio y cierre de sesión, consentimiento y eliminación de cuenta; no guarde contraseñas ni tokens en informes públicos o fixtures versionados.

Mantenga la diferencia de frameworks en la frontera de integración. Selenium usa WebDriver; las guías de Playwright y Puppeteer se revisan por separado. Los criterios de aceptación de la aplicación deben seguir siendo los mismos aunque cambie la biblioteca de control.

Validar un recorrido autorizado

Empiece con una tarea visible, como abrir ajustes, enviar un formulario sintético, descargar un informe propio o restaurar una sesión autorizada. Defina estado inicial, pantalla esperada, límite de red permitido y señal de finalización; crear una sesión no demuestra que el perfil admita el flujo.

Use aserciones de la aplicación, no detalles incidentales del navegador. Confirme que aparece la página y el idioma previstos, que una preferencia se conserva cuando corresponde y que se gestiona el error visible. Evite recopilar propiedades innecesarias: la evidencia acotada es más fácil de revisar y expone menos del entorno.

Incluya entradas inválidas, permisos opcionales rechazados, navegación interrumpida, directorio ausente y cancelación cuando correspondan. Cuando sea seguro reintentar, conserve la entrada del usuario y compruebe que una acción fallida no se registra como completada. El reintento debe partir de un estado de aplicación conocido, no del estado arbitrario que dejó una excepción.

Las capturas y los registros pueden contener nombres de cuenta, títulos de documentos, mensajes o rutas locales. Recójalos solo cuando una aserción los necesite, oculte los campos sensibles y defina un plazo de eliminación. Prefiera un resultado estructurado con nombre de prueba, revisión de la aplicación, identidad del navegador y estado de éxito o fallo. Un fragmento pequeño del DOM de un fixture propio puede ser más útil y menos sensible que una captura de página completa.

Ejecute el mismo recorrido con un perfil limpio y con el perfil persistente administrado cuando la continuidad sea un requisito. La ejecución limpia muestra si la aplicación depende de estado no declarado; la persistente comprueba si las preferencias previstas y la sesión sobreviven al reinicio. Explique las diferencias según la tarea del usuario, no como una promesa sobre todos los sitios.

Los tiempos de espera deben depender de eventos de la aplicación: navegación completada, botón habilitado, descarga terminada o mensaje accesible. Fije un límite acorde con el objetivo de servicio de la aplicación propia y reporte qué condición no se cumplió. Una pausa fija puede fallar con carga normal; una espera ilimitada puede ocupar el perfil indefinidamente.

Cerrar y recuperar sesiones

Solicite siempre un cierre WebDriver normal al terminar. Así el navegador puede vaciar el almacenamiento administrado y liberar los bloqueos del perfil; espere a que finalice la sesión antes de reutilizar o copiar el directorio. El comando Delete Session de WebDriver cierra la sesión activa, pero una respuesta correcta no demuestra por sí sola que la aplicación haya completado una descarga o una carga. Termine el proceso solo como recuperación excepcional, después de registrar la etapa del fallo, no como cierre estándar de cada prueba.

Si el runner se interrumpe, un supervisor puede identificar los procesos de esa ejecución y marcar el perfil como no disponible hasta resolver la propiedad. No termine procesos de navegador ajenos en un host compartido. Use identificadores específicos de ejecución y una política de limpieza acotada para que la recuperación no afecte a otra sesión.

Una descarga solo termina cuando el navegador y la aplicación confirman su finalización y el archivo esperado está estable. Una carga termina cuando la aplicación confirma la recepción. Defina también el fin de los trabajos en segundo plano; después cierre o cancele explícitamente.

Tras una salida inesperada, conserve un paquete mínimo con la revisión del runner, el binario elegido, la versión del driver, el identificador del perfil, el último paso de aplicación completado y un error redactado. No copie el perfil entero por defecto. Primero reproduzca con un fixture sintético o un perfil limpio; acceda al directorio original solo si la evidencia menor no basta y existe autorización.

Defina el reinicio del perfil: borrar un directorio temporal, restaurar un fixture conocido o crear una nueva identidad persistente. No borre bases de datos parcialmente. Para un perfil persistente administrado, retirarlo suele ser más seguro que limpiarlo de forma quirúrgica. Registre el motivo y elimine el directorio según la política de datos.

Si la aplicación cambia el foco, abre un diálogo o muestra progreso, compruebe que usuarios de teclado y tecnologías de asistencia reciben el mismo mensaje de finalización o error. Una excepción de Selenium no describe lo que vio el usuario. Conserve el estado hasta capturar el resultado accesible y después cierre la sesión sin retener contenido innecesario.

Diagnóstico por etapa

En los fallos de creación de sesión, revise primero la propiedad del lanzamiento: binario elegido, compatibilidad del driver, disponibilidad del nodo, permisos del directorio y bloqueos del perfil. En los fallos de navegación, revise la ruta de red aprobada y la respuesta de la aplicación propia. Si la interfaz queda en un estado incorrecto, revise locale, fixture de cuenta y datos de aplicación guardados. Mantener separadas estas etapas evita que cambios no relacionados oculten el problema original.

Revise las versiones del navegador y del driver junto con la aplicación. Fije una pareja conocida como funcional para obtener ejecuciones repetibles y pruebe las actualizaciones en un recorrido propio pequeño antes de ampliarlas. Si cambia el comportamiento, compare el mismo fixture de perfil y la misma revisión de la aplicación. La validación de versiones explica cómo separar cambios del runtime, las dependencias y la aplicación.

Los nodos remotos plantean capacidad y planificación. Un nodo no debe aceptar más perfiles activos de los que permiten sus límites de memoria, almacenamiento y procesos. Ponga el trabajo en cola en vez de compartir un perfil o dejar que la presión de recursos decida qué prueba falla. Registre la clase del nodo y el tamaño de la carga a alto nivel; mantenga los nombres de host, direcciones y estructura de directorios en registros protegidos.

Un informe de soporte útil termina con el recorrido de usuario afectado, la etapa del fallo, la identidad probada del navegador y el driver, el modo de almacenamiento del perfil y la siguiente acción segura. No afirme compatibilidad universal ni prometa que la automatización es indistinguible de la navegación manual. Selenium ofrece control del navegador para pruebas autorizadas; la fiabilidad depende de propiedad explícita, estado aislado, evidencia controlada y cierre limpio.

Introduzca la ejecución paralela solo después de que una sesión sea repetible. Asigne a cada worker un perfil, directorio de descargas, puerto, cuenta de aplicación e identificador de ejecución únicos. Limite la concurrencia según la capacidad medida del host y conserve una ejecución serial representativa para diagnosticar. Si los fallos solo aparecen bajo carga, compare presión de recursos y tiempos de la aplicación antes de cambiar la configuración del navegador. Registre las horas con un reloj común e incluya el identificador de ejecución en los artefactos para no mezclar capturas, descargas ni registros de workers distintos. Conserve el identificador de ejecución en cada artefacto que pueda separarse del informe, incluida una descarga o un extracto de consola. Así quien opera puede retirar los artefactos de una ejecución sin tocar la evidencia de otra.

Al retirar un perfil, avise al responsable de la cuenta de aplicación y a quienes dependen del calendario de pruebas. Cree el perfil siguiente con un identificador nuevo y un estado inicial explícito, en vez de heredar supuestos anteriores.

Fuentes públicas

• Documentación de Selenium WebDriver
• Opciones de Chrome en Selenium