🤖 machine learning

Autonomous QA Agent: A Retrieval-Augmented Framework for Reliable Selenium Script Generation

L'article présente l'Agent de Questions-Réponses Autonome, un cadre de Génération Augmentée par la Récupération qui améliore considérablement la précision des scripts Selenium en ancrant la génération de code dans la documentation spécifique au projet et les structures HTML réelles, atteignant un taux de succès d'exécution de 90 % contre 30 % pour les LLM standards.

Auteurs originaux : Dudekula Kasim Vali

Publié 2026-05-05

📖 4 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : Dudekula Kasim Vali

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayiez d'enseigner à un robot très intelligent, mais légèrement maladroit, comment naviguer dans une maison spécifique pour accomplir une tâche, comme « préparer une tasse de café ».

Le Problème : Le Robot Maladroit
Dans le monde des tests logiciels, ce robot est une Intelligence Artificielle (IA) appelée Modèle de Langage de Grande Taille (LLM). Si vous demandez à une IA standard d'écrire un script pour « cliquer sur le bouton d'achat d'un site web », elle fera de son mieux. Cependant, comme elle n'a pas vu le site web spécifique dont vous parlez, elle doit deviner.

Elle pourrait deviner que le bouton s'appelle #submit-button. Mais sur votre site web réel, le bouton s'appelle #btn-pay-now. L'IA « hallucine » : elle invente des détails qui semblent justes mais qui sont complètement faux. Dans l'article, c'est comme un robot essayant d'ouvrir une porte avec une clé qu'il a inventée, plutôt qu'avec la clé qui correspond réellement à la serrure. Lorsque le robot tente d'utiliser sa fausse clé, le script plante et le test échoue.

La Solution : L'« Agent QA Autonome »
Les auteurs de cet article ont construit un système plus intelligent appelé Agent QA Autonome. Imaginez cet agent comme un robot qui ne se contente pas de deviner ; il se rend d'abord à la bibliothèque pour lire les plans et examiner la maison réelle avant de commencer à travailler.

Voici comment cela fonctionne, en utilisant une analogie simple :

La Bibliothèque (La Base de Connaissances) : Avant que le robot ne fasse quoi que ce soit, le système prend deux éléments et les place dans une bibliothèque numérique :
- Les Instructions : Les exigences écrites (comme une recette ou un manuel utilisateur).
- Les Plans : La structure de code réelle du site web (le HTML), qui montre exactement où se trouve chaque bouton et chaque boîte.
La Recherche (Récupération) : Lorsque vous demandez au robot de « Tester le processus de paiement », il ne se contente pas de deviner. Il recherche immédiatement dans sa bibliothèque. Il trouve la page spécifique concernant « Paiement » et récupère les plans exacts de cette page. Il voit : « Ah, le bouton 'Payer' a l'identifiant btn_pay, et non submit. »
L'Écriture (Génération) : Maintenant, le robot écrit le script en utilisant les réelles informations qu'il vient de trouver. Il ne devine plus ; il suit la carte.

Les Résultats : Une Course entre Deux Robots
Les chercheurs ont testé ce nouveau système contre un robot IA standard en utilisant 20 scénarios d'achat différents (comme ajouter des articles au panier ou les payer).

Le Robot Standard (Sans Bibliothèque) : Il a obtenu la syntaxe du script correcte (la grammaire était bonne), mais il a échoué à trouver les boutons 70 % du temps car il devinait. Il n'a réussi que 30 % des tests.
L'Agent Autonome (Avec Bibliothèque) : Parce qu'il a consulté les vrais noms des boutons, il a réussi 90 % des tests. Il a obtenu la grammaire correcte 100 % du temps.

Pourquoi Cela Compte
L'article soutient que le plus grand problème dans les tests automatisés n'est pas que l'IA ne puisse pas écrire de code ; c'est que l'IA ne connaît pas l'« adresse » spécifique des éléments sur lesquels elle doit cliquer. En donnant à l'IA un système « Augmenté par la Récupération » (une façon de consulter des faits avant de parler), ils ont empêché le robot d'inventer de fausses adresses.

Ce que l'Article NE Prétend PAS
Il est important de noter ce que cet article ne dit pas :

Il ne prétend pas que cela fonctionne pour tous les types de logiciels (comme les applications bancaires ou de santé) pour l'instant ; ils ne l'ont testé que sur un faux magasin en ligne.
Il ne dit pas que le robot peut se corriger lui-même si le site web change demain (bien qu'ils mentionnent cela comme une idée future).
Il ne prétend pas être meilleur que les outils commerciaux coûteux que les humains doivent configurer manuellement ; ils l'ont seulement comparé à une IA « brute » sans bibliothèque.

En Résumé
L'article présente un outil qui empêche l'IA de deviner lors des tests de sites web. En forçant l'IA à lire les « plans » réels du site web (HTML) et les « instructions » (docs) avant d'écrire du code, le système crée des tests fiables qui fonctionnent réellement, transformant un devineur maladroit en un travailleur précis.

Résumé Technique : Agent QA Autonome

Définition du Problème

L'article aborde le goulot d'étranglement critique dans le développement logiciel moderne où l'Assurance Qualité (QA) prend du retard par rapport aux cycles Agile et DevOps rapides. Un défi majeur est le « fossé sémantique » entre les exigences lisibles par l'homme (langage naturel, maquettes) et le code de test exécutable par la machine (scripts Selenium). Bien que les Grands Modèles de Langage (LLM) puissent générer du code, ils souffrent d'un problème de « codeur aveugle » : dépourvus de connaissance de l'Application Sous Test (AUT) spécifique, ils hallucinent fréquemment des éléments d'interface utilisateur inexistants (par exemple, deviner un identifiant comme #submit alors que l'identifiant réel est #btn-confirm). Cela entraîne des taux d'échec élevés dans l'exécution des scripts. Les approches existantes, telles que les Tests Basés sur les Modèles (MBT), sont trop complexes à maintenir, tandis que la génération standard par LLM manque de l'ancrage nécessaire dans les contextes d'applications spécifiques.

Méthodologie

Les auteurs proposent l'Agent QA Autonome, un cadre de Génération Augmentée par Récupération (RAG) conçu pour ancrer la génération de scripts de test à la fois dans les exigences fonctionnelles et la réalité structurelle effective de l'application.

Architecture du Système

Le système est une architecture modulaire basée sur des microservices comprenant cinq couches :

Frontend : Une interface Streamlit pour le téléchargement de documents et la génération de tests.
API : Une couche FastAPI gérant l'orchestration et les points de terminaison RESTful.
Service : Encapsule la logique métier, y compris l'analyse des documents et le pipeline RAG.
Couche de Données : Utilise ChromaDB comme base de données vectorielle pour stocker des plongements de haute dimension.
Couche de Modèle : Intègre Llama 3.1-8b-instant via l'API de Groq pour une inférence à faible latence.

Pipeline RAG et Ingestion

L'innovation centrale est un pipeline d'ingestion multimodal qui traite :

Exigences Textuelles : PRD et spécifications au format Markdown, PDF et JSON.
Contexte Structurel : Fichiers HTML bruts représentant le DOM de l'AUT.

La stratégie de prétraitement implique un Séparateur de Texte Caractéristique Récursif (morceaux de 1000 caractères, chevauchement de 200 caractères) pour le texte. Pour le HTML, les scripts et les styles sont supprimés, ne conservant que les balises structurelles (div, input, button) et les attributs (id, class, name) essentiels pour les sélecteurs Selenium.

Processus de Génération

Le pipeline suit une formulation mathématique stricte :

Plongement : Les morceaux de texte et HTML sont mappés dans un espace vectoriel de 384 dimensions utilisant all-MiniLM-L6-v2.
Récupération : Pour une requête utilisateur (par exemple, « Tester le flux de commande »), le système récupère les $k$ meilleurs morceaux (généralement $k=3$ ) ayant la plus grande similarité cosinus. Crucialement, il filtre et fusionne à la fois les morceaux de documentation et de HTML.
Fusion de Contexte et Prompting : Le système construit un prompt qui sépare explicitement la documentation récupérée ([DOCUMENTATION]) de la structure HTML ([HTML STRUCTURE]).
Contraintes : Le prompt impose des contraintes telles que « Utiliser UNIQUEMENT les IDs du HTML fourni » et « Ajouter WebDriverWait pour les éléments dynamiques ».
Génération : Le LLM génère un script Selenium Python basé sur ce contexte ancré.

Contributions Clés

Architecture RAG Nouvelle pour la QA : Un système spécialisé qui récupère deux types de contextes distincts : les exigences fonctionnelles textuelles et le contexte structurel HTML/DOM, contrairement aux systèmes RAG génériques qui se concentrent uniquement sur le code ou le texte.
Pipeline d'Ingestion Multimodal : Un pipeline robuste capable de traiter divers formats (Markdown, PDF, JSON, HTML) pour construire une base de connaissances complète.
Génération de Scripts Sensible au Contexte : Une méthode démontrée pour générer des scripts Selenium ancrés dans des structures HTML réelles, réduisant considérablement les erreurs de localisation d'éléments.
Évaluation Reproductible : Une configuration expérimentale détaillée avec analyse statistique sur 20 scénarios de test, fournissant une référence pour les tests pilotés par l'IA.

Résultats Expérimentaux

Le système a été évalué sur une application de commerce électronique personnalisée avec 127 éléments DOM répartis sur quatre pages. L'évaluation a comparé l'Agent QA Autonome (RAG) à une Ligne de Base LLM Standard (Llama 3.1-8b sans contexte).

Métriques Clés (Moyenne sur 3 exécutions) :

Validité Syntaxique : Le RAG a atteint 100% (contre 95% pour la Ligne de Base).
Résolution d'Éléments : Le RAG a atteint 95% (contre 40% pour la Ligne de Base). Cette métrique mesure la précision des sélecteurs pour localiser les éléments DOM cibles.
Succès d'Exécution : Le RAG a atteint 90% (contre 30% pour la Ligne de Base). Cela mesure les scripts s'exécutant du début à la fin sans exceptions.

Significativité Statistique :
Des tests t à deux échantillons ont confirmé que les améliorations sont statistiquement significatives ( $p < 0.001$ ) avec de grandes tailles d'effet (Cohen's $d = 3.2$ pour la résolution, $d = 3.8$ pour l'exécution).

Étude d'Ablation :

RAG Texte-Seulement : 60% de résolution.
RAG HTML-Seulement : 85% de résolution.
RAG Complet (Texte + HTML) : 95% de résolution.
Cela confirme que la compréhension structurelle du DOM est obligatoire pour l'automatisation de l'interface utilisateur, car les exigences sémantiques seules sont insuffisantes.

Analyse des Échecs :
Le taux d'échec de 10% de l'agent RAG a été attribué à :

Chronométrage des Éléments Dynamiques : Éléments apparaissant uniquement après des animations JavaScript non capturées dans les instantanés HTML statiques.
Contexte Ambigu : Contexte de désambiguïsation insuffisant lorsque plusieurs éléments similaires existaient.

Signification et Revendications

L'article revendique que le problème d'hallucination dans la génération de code basée sur les LLM peut être efficacement atténué grâce à une architecture RAG spécifique au domaine. En traitant l'AUT comme une source de connaissances à ingérer plutôt que comme une boîte noire, le système permet aux LLM d'agir comme des ingénieurs QA compétents.

Les auteurs estiment une réduction de 60 à 70% du temps de rédaction de scripts par les ingénieurs QA en automatisant l'identification des sélecteurs et la génération de code squelette. Ils soutiennent que bien que le LLM Standard soit plus rapide (4s contre 13,2s de latence de bout en bout), l'approche RAG est plus rentable lorsqu'on prend en compte le temps de débogage manuel requis pour le taux d'échec de 70% de la ligne de base.

Ce travail se positionne comme une fondation pour des suites de tests « auto-écrits, auto-réparateurs », bien que les auteurs reconnaissent modestement les limitations concernant l'ingestion HTML statique (défi pour les Applications Page Unique) et la nécessité d'une validation supplémentaire à travers divers domaines au-delà du commerce électronique.