Intégrer un profil de navigateur avec Selenium

Selenium pilote les navigateurs selon le standard WebDriver. Un profil ajoute l’état et la configuration de la session ; l’intégration ne consiste donc pas seulement à choisir un exécutable. Le runner doit posséder le lancement, le répertoire de stockage, la politique réseau, le nettoyage et les preuves de toute la session. Cette responsabilité évite que deux workers écrivent dans le même profil et facilite la reproduction des échecs.

Un profil ne garantit pas qu’un site acceptera une tâche automatisée, et Selenium ne modifie pas les règles d’accès du site. Utilisez l’intégration uniquement avec des applications que vous possédez ou êtes autorisé à tester. Avant le lancement, définissez la tâche utilisateur et le résultat attendu, gardez les identifiants hors des fixtures et arrêtez-vous si l’application signale une limite d’accès ou de politique.

La configuration la plus fiable comporte un runner, un processus de navigateur actif et un seul propriétaire du profil. Le stockage persistant est un choix produit, pas une exigence par défaut : un test fonctionnel court peut utiliser un répertoire temporaire isolé, tandis qu’un test de continuité peut utiliser un répertoire persistant géré si la conservation, l’accès et la suppression ont été décidés à l’avance. Consignez ce choix.

Propriété du lancement

Le runner doit choisir le binaire quand plusieurs installations existent. Enregistrez les versions du navigateur, du driver et du runner, la révision du runner et le binaire choisi avec le résultat. Les exemples officiels Selenium pour Chrome montrent le choix du binaire et les arguments ; ils ne prouvent pas la compatibilité avec tout navigateur personnalisé.

Exemple de lancement minimal

Cet exemple Python sélectionne un binaire et un dossier user-data Chromium isolé. Remplacez les deux chemins par des chemins gérés sur le nœud et ouvrez uniquement une application autorisée pour le test.

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()

Le dossier user-data conserve l'état d'exécution de Chromium. Une configuration de profil distincte décrit le comportement choisi pour la session. Cet exemple montre uniquement la responsabilité de Selenium et du user-data Chromium. Si une application possède aussi une configuration de profil distincte, transmettez-la seulement par le point d'intégration documenté par ce produit; ne déduisez pas une option de cet exemple, ne partagez pas le même chemin et ne copiez pas la configuration dans le dossier user-data.

Le driver et le navigateur doivent être assez compatibles pour établir une session WebDriver. Des outils de découverte de version peuvent aider, mais les environnements gérés épinglent souvent les deux composants pour reproduire les tests. Si la création de session échoue, vérifiez d’abord le binaire choisi et le driver avant de modifier le profil : un désaccord au lancement ne se corrige pas en changeant les cookies, la locale ou l’état conservé.

Le runner doit être l’unique couche responsable du cycle du processus : il lance le driver, qui lance ou rejoint le navigateur prévu selon la conception approuvée, puis le même runner ferme la session. Mélanger navigateur lancé manuellement, driver automatique et second script de nettoyage peut laisser des processus ou des verrous ; ne le faites que si les responsabilités sont documentées.

Dans un déploiement distant, le répertoire de profil doit exister sur le nœud qui exécute le navigateur, et pas seulement sur la machine qui envoie les commandes. Ce nœud interprète aussi le chemin du binaire, les téléchargements, les certificats et le réseau. Une grille doit fournir des capacités de nœud stables et une politique de stockage sans recevoir de chemins locaux inexistants sur l’hôte distant.

Classez l’échec avant de réessayer : binaire indisponible, driver incompatible, répertoire illisible, verrou de profil existant ou navigateur qui quitte au démarrage ont des responsables différents. Répéter sans changer les entrées peut laisser davantage de processus orphelins sans apporter de preuve.

Le lancement doit conserver l’isolation normale des processus du navigateur et les contrôles hôte exigés par le déploiement. Ne réduisez ni le sandbox, ni les permissions de fichiers, ni la validation des certificats pour démarrer une session. Si l’environnement ne fournit pas les prérequis, déclarez-le non pris en charge et corrigez l’image hôte. Gardez les secrets dans le coffre d’identifiants de la plateforme et ne transmettez que les références nécessaires ; le compte rendu peut signaler que l’authentification était disponible, sans copier de secret. Une capture ne doit jamais conserver mot de passe ou code de récupération.

Limite du profil et du stockage

Un profil Chromium contient préférences, bases, caches et état d'extensions. Il ne faut pas le modifier pendant que le navigateur le possède. Attribuez un répertoire distinct à chaque session concurrente pour éviter des écritures et verrous partagés. La documentation Chromium sur le répertoire des données utilisateur distingue ce répertoire de ses sous-répertoires de profils et documente l'argument de lancement ; une configuration de produit séparée ne remplace ni l'un ni les autres.

Choisissez un stockage éphémère ou persistant selon la tâche. L’éphémère permet de repartir d’un état vide connu, par exemple pour un test de premier lancement ou de consentement. Le persistant sert à vérifier une continuité autorisée où la même relation utilisateur doit survivre à un redémarrage. Pour ce dernier, définissez propriétaire, durée de conservation, contrôles d’accès, décision de sauvegarde et procédure documentée de remise à zéro.

Ne copiez pas un répertoire de profil actif. Fermez le navigateur avant de copier une fixture gérée, attribuez un identifiant propre à la copie et vérifiez qu’elle s’ouvre avant de l’utiliser dans une suite plus large. Si elle contient un état de compte ou des données personnelles, remplacez-les par un compte synthétique ou obtenez une autorisation explicite et appliquez la politique habituelle de suppression.

Cookies, stockage local, données des service workers, permissions et historique de téléchargement peuvent affecter les exécutions suivantes ; consignez ce qui doit persister. Ne videz pas automatiquement le dossier après un test en échec : mettez la session en quarantaine, gardez un résultat minimal, puis réinitialisez-la ou retirez-la selon la politique.

Séparez configuration, données utilisateur, identifiants, fixtures et résultats. Le guide des profils donne un modèle de cycle de vie.

Disque local, volume réseau et montage de conteneur peuvent différer pour le verrouillage, la latence, la propriété et le nettoyage. Validez le type de stockage utilisé en production, gardez assez d’espace pour les bases du navigateur et les téléchargements, et traitez un volume plein comme une panne d’infrastructure. Ne sauvegardez un profil persistant que navigateur fermé et appliquez à la copie les mêmes règles d’accès et de suppression qu’à l’original.

Réseau, locale et contexte applicatif

Définissez réseau et locale avant le démarrage. Un changement silencieux de route dans la même session mélange des états difficiles à interpréter.

Si le test requiert un proxy, utilisez le chemin réseau approuvé du navigateur et vérifiez-le au moyen d’un endpoint que vous contrôlez.

N’inscrivez pas les identifiants proxy ni les URI complètes dans les journaux, rapports ou captures ; masquez mots de passe et codes de récupération.

La locale comprend la langue, le fuseau horaire, le clavier, le format de date et les données régionales du compte de test. Déclarez les valeurs nécessaires au parcours et gardez-les compatibles avec le contexte réseau. Pour couvrir plusieurs régions, utilisez des profils ou sessions séparés afin que cookies et choix stockés ne se croisent pas.

Les capabilities décrivent le démarrage de la session sans devenir une collection d’options copiées. Gardez une petite configuration maîtrisée pour chaque environnement pris en charge, supprimez les options sans exigence documentée et validez tout le parcours après une mise à jour du navigateur ou du driver. Un lancement réussi ne garantit pas que téléchargements, notifications, permissions média ou tâches longues se comportent comme prévu.

L’état de l’application doit également avoir un responsable. Utilisez des comptes de test synthétiques si possible, isolez chaque compte dans son profil et évitez l’usage parallèle si le produit ne le permet pas. Faites de la connexion, déconnexion, du consentement et de la suppression des étapes explicites ; ne conservez ni mots de passe ni jetons dans des rapports publics ou fixtures versionnées.

Conservez la différence de framework à la frontière d'intégration. Selenium utilise WebDriver; les guides Playwright et Puppeteer sont distincts. Les critères d’acceptation de l’application doivent rester les mêmes même si la bibliothèque de contrôle change.

Valider un parcours autorisé

Commencez par une tâche visible, par exemple ouvrir les réglages, envoyer un formulaire synthétique, télécharger un rapport maîtrisé ou restaurer une session autorisée. Définissez l’état de départ, l’écran attendu, la limite réseau autorisée et le signal d’achèvement ; la création d’une session ne prouve pas que le profil convient au parcours.

Utilisez des assertions liées à l’application plutôt qu’à des détails fortuits du navigateur. Vérifiez la page et la langue attendues, la persistance d’une préférence si nécessaire et le traitement d’une erreur visible. Évitez les propriétés inutiles : une preuve restreinte est plus simple à examiner et révèle moins de l’environnement.

Ajoutez les valeurs invalides, les permissions facultatives refusées, la navigation interrompue, le dossier absent et l'annulation lorsqu'ils concernent le parcours. Quand une nouvelle tentative est sûre, conservez la saisie utilisateur et vérifiez qu’une action échouée n’est pas enregistrée comme terminée. La reprise doit repartir d’un état applicatif connu, et non de l’état arbitraire laissé par une exception.

Les captures et les journaux peuvent contenir des noms de compte, titres de document, messages ou chemins locaux. Ne les recueillez que si une assertion en a besoin, masquez les champs sensibles et fixez une durée de suppression. Préférez un résultat structuré avec le nom du test, la révision de l’application, l’identité du navigateur et le statut. Un petit extrait DOM d’une fixture maîtrisée peut être plus utile et moins sensible qu’une capture pleine page.

Exécutez le même parcours avec un profil propre et avec le profil persistant géré lorsque la continuité est requise. L’exécution propre révèle si l’application dépend d’un état non déclaré ; l’exécution persistante vérifie que les préférences prévues et la session survivent au redémarrage. Expliquez les différences par la tâche utilisateur, sans généraliser à tous les sites.

Les attentes doivent représenter des événements applicatifs : navigation terminée, bouton activé, téléchargement achevé ou message accessible. Fixez un délai maximal lié à l’objectif de service de l’application maîtrisée et indiquez la condition non satisfaite. Une pause fixe peut échouer sous charge ordinaire ; une attente illimitée peut immobiliser un profil indéfiniment.

Fermer et reprendre les sessions

Demandez toujours une fermeture WebDriver normale à la fin. Elle permet au navigateur de vider le stockage géré et de libérer les verrous du profil ; attendez la fin de la session avant de réutiliser ou copier le répertoire. La commande Delete Session de WebDriver ferme une session active, mais une réponse positive ne prouve pas à elle seule que le téléchargement ou l’envoi de l’application est terminé. Ne tuez le processus qu’en récupération exceptionnelle, après avoir consigné l’étape de l’échec, et non à la fin normale de chaque test.

Après une interruption du runner, un superviseur peut identifier les processus de cette exécution et rendre le profil indisponible jusqu'à la résolution de sa propriété. Ne terminez pas les processus de navigateur sans rapport sur un hôte partagé. Utilisez des identifiants propres à l’exécution et une politique de nettoyage bornée afin que la récupération ne touche pas la session d’un autre worker.

Un téléchargement est terminé quand le navigateur et l'application confirment sa fin et que le fichier attendu est stable. Un envoi est terminé quand l'application confirme sa réception. Définissez aussi la fin du travail en arrière-plan ; fermez ensuite la session ou annulez explicitement.

Après une sortie inattendue, conservez un paquet minimal avec la révision du runner, le binaire choisi, la version du driver, l’identifiant du profil, la dernière étape applicative achevée et une erreur expurgée. Ne copiez pas tout le profil par défaut. Reproduisez d’abord avec une fixture synthétique ou un profil propre ; n’accédez au répertoire original que si ces éléments ne suffisent pas et si l’autorisation le permet.

Définissez la remise à zéro : supprimer un répertoire temporaire, restaurer une fixture connue ou créer une nouvelle identité persistante. Ne supprimez pas des bases partiellement. Pour un profil persistant géré, le retrait est souvent plus sûr qu’un nettoyage chirurgical. Consignez le motif et supprimez le répertoire selon la politique de données.

Si l’application déplace le focus, ouvre une boîte de dialogue ou affiche une progression, vérifiez que les personnes au clavier et les technologies d’assistance reçoivent la même information de fin ou d’erreur. Une exception Selenium ne décrit pas ce que l’utilisateur a vu. Gardez l’état le temps de capturer le résultat accessible, puis fermez la session sans retenir de contenu inutile.

Diagnostiquer par étape

En cas d’échec de création de session, examinez d’abord la responsabilité du lancement : binaire choisi, compatibilité du driver, disponibilité du nœud, droits du répertoire et verrous du profil. En cas d’échec de navigation, vérifiez le chemin réseau approuvé et la réponse de l’application maîtrisée. Pour un état d’interface incorrect, examinez aussi la locale, la fixture de compte et les données applicatives stockées. Séparer ces étapes évite qu’un changement sans rapport masque le problème initial.

Les versions du navigateur et du driver doivent être examinées avec celles de l’application. Épinglez une paire connue comme fonctionnelle pour obtenir des exécutions reproductibles, puis testez les mises à jour sur un petit parcours maîtrisé avant de les généraliser. Si le comportement change, comparez la même fixture de profil et la même révision de l’application. La validation des versions explique comment séparer runtime, dépendances et application.

Les nœuds distants posent des questions de capacité et d’ordonnancement. Un nœud ne doit pas accepter plus de profils actifs que ses limites de mémoire, de stockage et de processus ne le permettent. Mettez le travail en file d’attente au lieu de partager un profil ou de laisser la pression des ressources décider quel test échoue. Consignez à haut niveau la classe du nœud et la taille de la charge ; gardez noms d’hôte, adresses et structure des répertoires dans les dossiers protégés des opérateurs.

Un rapport d’assistance utile indique le parcours utilisateur touché, l’étape en échec, l’identité du navigateur et du driver testés, le mode de stockage du profil et la prochaine action sûre. Ne revendiquez pas une compatibilité universelle et ne promettez pas qu’une automatisation est indiscernable d’une navigation manuelle. Selenium contrôle le navigateur pour des tests autorisés ; la fiabilité repose sur une responsabilité explicite, un état isolé, des preuves maîtrisées et une fermeture propre.

N’introduisez l’exécution parallèle qu’après avoir rendu une session reproductible. Attribuez à chaque worker un profil, un dossier de téléchargements, un port, un compte applicatif et un identifiant d’exécution uniques. Limitez la concurrence selon la capacité mesurée de l’hôte et gardez une exécution séquentielle représentative pour le diagnostic. Si les échecs n’apparaissent qu’en charge, comparez la pression des ressources et le calendrier applicatif avant de modifier la configuration du navigateur. Utilisez une horloge commune et l’identifiant d’exécution dans les artefacts afin de ne pas mélanger captures, téléchargements et journaux de workers distincts. Conservez l’identifiant d’exécution avec tout artefact détachable du rapport, y compris un fichier téléchargé ou un extrait de console. L’opérateur peut ainsi supprimer les éléments d’une exécution sans toucher aux preuves d’une autre.

Lorsqu’un profil est retiré, avertissez le propriétaire du compte applicatif et les personnes qui dépendent du calendrier de tests. Le nouveau profil doit recevoir un nouvel identifiant et un état de départ explicite, sans hériter silencieusement des anciennes hypothèses.

Sources publiques

• Documentation Selenium WebDriver
• Options Chrome de Selenium