Gains :
- Capacité à produire un code de test d'interface utilisateur robuste avec l'intelligence artificielle, y compris data-testid, open wait et assert qui vérifie le résultat réel de l'utilisateur
- Capacité à éviter les tests fragiles (mauvais sélecteur, attente aveugle) et à rendre les tests faciles à maintenir dans la structure Page Object Model
- Possibilité de tester chaque test d'interface utilisateur produit en cassant le code et de détecter et corriger les faux tests réussis
Chaque clic, chaque remplissage de formulaire, chaque transition de page qu'un utilisateur effectue dans un navigateur ne peut pas être testé encore et encore à la main. C'est pourquoi l'automatisation des tests d'interface utilisateur (interface utilisateur ; ces tests imitent le comportement de l'utilisateur en pilotant par programme un vrai navigateur) existe. Selenium, Playwright et Cypress sont les outils les plus courants pour ce travail. L'intelligence artificielle (IA) est hautement compétente pour écrire le code de ces outils : vous décrivez un cas de test, l'IA vous donne une ébauche d'un script d'automatisation réalisable. Mais ici, l'avertissement central de ce module entre à nouveau en jeu : le code de test de l'interface utilisateur produit par l'IA peut souvent être des tests fragiles qui « s'allument en vert mais vérifient la mauvaise chose » ou battent au vent. Votre travail ne consiste pas à exécuter ce code, mais à vous assurer qu'il vérifie réellement la bonne chose.
Dans cette unité, nous visons à produire des tests d'interface utilisateur robustes, maintenables et véritablement validants avec l'IA ; Vous apprendrez à éviter les tests fragiles.
Les trois piliers d’un test d’interface utilisateur solide
1. Corriger le localisateur d'éléments. Un test utilise un sélecteur pour trouver l'élément sur la page. L'IA produit souvent des sélecteurs fragiles : chemins XPath longs (adresse trop dépendante de la structure de la page), sélecteurs basés sur les noms de classes CSS (se cassent lorsque la conception change). La méthode robuste consiste à utiliser des attributs stables tels que data-testid que le développeur a ajoutés pour les tests. Imposer cela explicitement à l’IA.
2. Attente explicite. La principale source de vulnérabilité dans les tests d’interface utilisateur est le timing. Le sommeil constant(3) (attente aveugle) est une mauvaise pratique : parfois cela ne suffit pas, parfois cela fait perdre du temps. La bonne méthode consiste à utiliser une attente explicite, qui dit "attendez que cet élément apparaisse". Le dramaturge le fait en grande partie automatiquement ; Dans Selenium, vous devez le demander explicitement.
3. Affirmation significative. Le test doit vérifier le résultat que l'utilisateur verra réellement, comme « le numéro de commande est apparu à l'écran », et pas seulement « la page chargée ». Si le test produit par l'IA ne comporte pas d'assertion ou est sans importance, ce test produit une pseudo-réussite (1ère unité).
Attention : lorsque vous voyez pour la première fois un test d'interface utilisateur généré par l'IA, vérifiez trois choses au maximum : les sélecteurs sont-ils validés (data-testid), les attentes sont-elles activées (pas de veille aveugle) et l'assertion vérifie-t-elle le résultat réel de l'utilisateur ? Si ces trois éléments sont corrects, le test est probablement solide.
Modèle d'objet de page
À mesure que les tests grandissent, l’écriture de sélecteurs à l’intérieur de chaque test devient un cauchemar de maintenance. Le modèle d'objet de page (POM — modèle de conception qui rassemble les sélecteurs et les actions pour chaque page/écran dans une seule classe) conserve le sélecteur au même endroit ; Lorsque l'interface change, vous la mettez à jour dans un seul fichier. Faire en sorte que l’IA produise les tests dans une structure POM, plutôt que directement ; Cela rend la maintenance radicalement plus facile.
Invite faible/Invite forte
Faible : "Écrivez un test Selenium pour la page de connexion."
Strong : "Écrivez un test de flux de connexion avec Playwright (TypeScript). Les sélecteurs utilisent uniquement data-testid ; n'utilisez pas le contrôle de ce que l'utilisateur voit, pas du titre de la page."
Invite puissante ; L'outil donne le langage, la politique de sélection, la stratégie d'attente, l'architecture (POM) et les attentes d'affirmation expressive.
Indépendance des données de test et de l’environnement
Un test d'interface utilisateur solide est non seulement écrit correctement, mais crée et nettoie également ses propres données de test. Les tests générés par l'IA sont souvent liés à un utilisateur ou à un enregistrement supposé exister déjà dans l'environnement (« connectez-vous en tant qu'utilisateur administrateur »). Cette hypothèse est rompue lorsque le test s'exécute dans un autre environnement ou après un autre test (problème de dépendance d'ordre dans l'unité 9). La vérité est que chaque test crée les données dont il a besoin au début du test (ou les prépare avec un appel API) et les nettoie à la fin. Demandez explicitement à l'IA de "configurer toutes les données dont dépend ce test dans le test ; ne supposez pas de données prêtes à l'emploi provenant de l'extérieur".
Un autre point critique est de ne pas effectuer de tests d’interface utilisateur avec des données utilisateur réelles. Si une copie de la base de données de production est utilisée dans l'environnement de test, ces enregistrements sont des données de personnes réelles ; des captures d'écran et des enregistrements de test peuvent révéler ces données. Utiliser des comptes de test synthétiques (fictifs) ; il protège à la fois la confidentialité et rend les tests reproductibles. Réaliser un test « annulation de commande » avec un compte client réel est une erreur à la fois éthique et opérationnelle.
Astuce : limitez le plus possible les tests d'interface utilisateur ; Confiez la vérification réelle à l’API et aux tests unitaires, qui sont rapides et stables. Les tests d'interface utilisateur sont coûteux et fragiles : utilisez-les uniquement pour valider un véritable flux d'utilisateurs de bout en bout (logique de pyramide de test).
Comparaison de véhicules
fonctionnalité
sélénium
dramaturge
cyprès
langues
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
veille automatique
Non (à la main)
Oui (fort)
Oui
Multi-navigateur
large
Chrome/Firefox/WebKit
À dominante chrome
tendance à la fragilité
Élevé (veille manuelle)
faible
faible
Facilité d'apprentissage
moyen
facile
facile
fonctionnement en parallèle
Grille requise
intégré
Résident/payant
Lorsque vous demandez un code à AI, indiquez clairement à quel véhicule il appartient ; Sinon, cela pourrait produire un code confus et non fonctionnel.
Quatre modèles copiables
1) Génération de tests d'interface utilisateur solide :
Votre rôle : ingénieur senior en automatisation des tests. Rédiger des tests avec [outil + langage] pour le flux suivant : [flow].Règles : - Sélecteurs data-testid uniquement ; Utilisation de la classe XPath/CSS. - Pas de sommeil aveugle ; Utilisez l'attente explicite/automatique. - Appliquer le modèle d'objet de page. - Laissez chaque assertion vérifier le résultat réel de l'utilisateur. Commentez au début de chaque test les critères d’acceptation que vous validez.
2) Contrôle de la fragilité :
Examinez le test d'interface utilisateur suivant pour déterminer la fragilité : - Y a-t-il un sélecteur instable (long
3) Conversion en objet de page :
Convertissez le code de test simple suivant en structure de modèle d'objet de page. Déplacez les sélecteurs et les actions vers les classes de pages ; Laissez le fichier de test lire uniquement le flux du scénario. [Outil/langue].Code : [coller le code]
4) Preuve de pseudo-transition :
Prouvez que ce test d'interface utilisateur valide réellement : quelle modification dois-je apporter au code de l'application qui rendra ce test ROUGE ? Si vous ne parvenez pas à trouver un changement susceptible d'interrompre le test, celui-ci est inadéquat ; ajouter des assertions manquantes.Test : [coller le test]
trois mini-cases
Cas 1 — Libération du sélecteur fragile. Sur les 40 tests réalisés par une équipe avec l'IA, 70 % ont été interrompus après une mise à jour de l'interface ; aucun d’entre eux n’était de véritables bugs, c’étaient tous des sélecteurs XPath fragiles. L'équipe a converti les tests en une base de données-testid avec le modèle « frility check ». Au cours des trois mises à jour suivantes de l’interface, le nombre de fausses coupures est tombé à zéro ; le temps de maintenance est passé de 6 heures à 30 minutes par semaine.
Cas 2 – Faux test d’interface utilisateur réussi. L'IA a produit un test « Ajouter au panier » ; le test était vert. Lorsque le modèle de « fausse preuve de passage » était exécuté, le test semblait vérifier uniquement le clic sur le bouton et le titre de la page, sans jamais vérifier si le compteur de panier avait augmenté ou non. Même si la logique du panier était complètement brisée, le test a réussi. Ajout de la true assert (le badge du panier étant "1").
Cas 3 — Piège d’attente aveugle. Dans le test Selenium produit par AI, il y avait du sommeil (2) après chaque étape ; 60 tests ont duré 14 minutes et se sont encore interrompus de temps en temps. Après passage en attente d'ouverture (attendre que l'élément soit cliquable) le temps est descendu à 5 minutes et la fragilité a disparu. L'attente aveugle était à la fois lente et peu fiable.
Erreurs courantes
- Accepter des sélectionneurs fragiles. Utiliser les longs XPaths générés par l'IA tels quels ; Les tests crashent au premier changement d'interface.
- Laisser le « sommeil » aveugle. « Résoudre » le timing avec une attente fixe ; à la fois lent et indécis.
- Affirmation triviale. Vérifiez simplement que la page est chargée ; ne pas vérifier le résultat réel de l'utilisateur (fake-pass).
- Développez sans POM. Distribuer des sélecteurs à chaque test ; Mise à jour manuelle de dizaines de fichiers lorsque l'interface change.
- Ne précisant pas l'outil. Ne pas dire à l'IA quel outil/langage vous souhaitez ; obtenir du code désordonné et qui ne fonctionne pas.
- Faire confiance lorsque vous exécutez le code généré et que vous le réussissez. Ne pas tester en cassant le code.
En résumé
L'automatisation des tests d'interface utilisateur vérifie le comportement de l'utilisateur en pilotant le navigateur réel avec le programme. L'IA génère ce code rapidement, mais il existe deux gros pièges : les tests fragiles (mauvais sélecteur, attente aveugle) et les faux tests de réussite (assertion incomplète/triviale). Les trois piliers d'un test d'interface utilisateur solide sont le sélecteur de validation (data-testid), l'attente explicite et l'assertion qui vérifie le résultat réel de l'utilisateur. La génération de tests dans le modèle d'objet de page simplifie radicalement la maintenance. Testez chaque test généré avec la question « quel changement va casser cela ? »
Tâche de candidature
Sélectionnez un flux d'utilisateurs de votre propre projet (par exemple, connexion ou recherche). Demandez à l'IA d'écrire des tests avec le modèle « Génération de tests d'interface utilisateur robuste ». Ensuite : (1) vérifier et réparer les sélecteurs et attendre avec un "vérification de fragilité", (2) prouver que chaque test se valide effectivement avec une "preuve de pseudo-réussite", (3) casser le code et observer que le test devient rouge. Signalez le nombre de tests produits et corrigés, ainsi que le nombre de vulnérabilités et de pseudo-passes que vous avez trouvés.
liste de contrôle
- [ ] J'ai clairement donné à l'IA l'outil, le langage, la politique de sélection et l'architecture (POM).
- [ ] J'ai vérifié que les sélecteurs sont data-testid.
- [ ] Je me suis assuré d'utiliser l'attente explicite/automatique au lieu du sommeil aveugle.
- [ ] J'ai vérifié que chaque assertion vérifie le résultat réel de l'utilisateur.
- [ ] J'ai testé chaque test en cassant le code ; Je l'ai vu devenir rouge.
- [ ] J'ai collecté les tests dans la structure Page Object Model.