Détail du poste
Établissement : Université Grenoble Alpes École doctorale : MSTII - Mathématiques, Sciences et technologies de l'information, Informatique Laboratoire de recherche : Laboratoire de conception et d'intégration des systèmes Direction de la thèse : Ioannis PARISSIS ORCID 0009000201577402 Début de la thèse : 2026-10-01 Date limite de candidature : 2026-06-12T23:59:59 Le principal problème du processus de test de régression vient du grand et croissant volume de tests. En effet, au fur et à mesure qu'une application évolue, le nombre de tests peut augmenter significativement. Ainsi, réexécuter systématiquement tous les tests peut vite devenir incompatible avec les délais de développement et de livraison d'une nouvelle version. Par ailleurs, l'effort et le coût peuvent être sans réel rapport avec la valeur ajoutée des tests. En effet, certains d'entre eux deviennent obsolètes d'une version de l'application à une autre ; d'autres perdent leur pouvoir de détection de défauts ou sont redondants. Conserver, à chaque version d'une application, un ensemble minimal de tests de régression (i.e. détectant toutes les fautes avec un minimum d'effort) est un objectif idéal que plusieurs travaux de recherche ont essayé d'approcher, notamment par l'intermédiaire de l'automatisation et la priorisation (TSP : Test Case Selection and Prioritization). Affecter des priorités aux tests de régression (Prioritization) peut se faire pour plusieurs raisons :
· pour améliorer le taux de détection des défauts d'une suite de tests, c'est-à-dire la probabilité de détecter des défauts plus tôt lors d'une série de tests de régression utilisant cette suite.
· pour augmenter plus rapidement la couverture du code testable dans le système soumis aux tests, ce qui permettrait de satisfaire plus tôt le critère de couverture de code au cours du processus de test.
· pour renforcer leur confiance dans la fiabilité du système testé à un rythme plus soutenu.
· pour augmenter le taux de détection des défauts à haut risque par la suite de tests, afin de les repérer plus tôt dans le processus de test.
· pour augmenter les chances de détecter plus tôt, au cours du processus de test, les défauts liés à des modifications spécifiques du code.
L'apprentissage automatique a été utilisé pour améliorer ces techniques (ML-TSP : Machine Learning Test Selection and Prioritization) en se basant principalement sur des modèles issus de l'apprentissage par renforcement (RL), du regroupement par clusters, du classement et du traitement du langage naturel (NLP). Nous nous appuyons sur le travail de recherche réalisé dans le cadre d'une thèse soutenue récemment à l'université de Franche-Comté par F. Tamagnan sous la direction de Fabrice Bouquet. Elle exploite les traces d'exécution réelles d'une application en fouillant des logs. On peut ainsi en extraire des usages réels de l'application pour en choisir un sous-ensemble, optimal d'un point de vue de la « couverture de l'usage réel », que l'on peut dériver en des suites de tests. L'apprentissage automatique permet d'opérer un regroupement en clusters puis d'en choisir une suite par classe de test.
Dans le cadre de cette proposition du sujet de thèse, nous identifions quatre potentiels axes de recherche :
1. Le premier axe se base sur les 'patrons d'interaction' (patterns métier) : l'idée est de pouvoir utiliser ces patrons directement dans le processus d'apprentissage pour forcer la couverture de scénarios spécifiques pour dépasser la simple analyse statistique.
2. Le second axe vise à étudier les différentes pistes d'utilisation des patterns pour améliorer les modèles. Ainsi, on pourrait utiliser les capacités de compréhension contextuelle des Large Language Models (LLM) pour créer des 'embeddings' de traces plus riches que les méthodes traditionnelles (Word2Vec, Autoencoders), capturant ainsi mieux la sémantique métier.
3. Le troisième axe est l'étude de la transformation automatique des traces sélectionnées issues des méthodes précédentes en de scripts de test qui pourront être exécutés sur le système réel.
4. Le dernier axe cible la confiance sur les tests ainsi construits à travers la mise en place de métriques. Ces dernières peuvent mesurer la complétude - par exemple Usage Pattern Coverage (UPC) - pour identifier les 'trous' dans le référentiel actuel par rapport à l'usage réel. L'activité de test de régression dans le développement logiciel consiste à s'assurer, à travers l'exécution de tests prédéterminés, que la nouvelle version d'une application ne va pas compromettre la réalisation correcte des fonctionnalités déjà présentes dans la précédente version.
Les tests de régression évoluent ainsi avec les versions des applications associées et peuvent être, d'une version à l'autre :
- retenus tels quels ;
- modifiés pour prendre en compte les modifications du code les concernant ;
- supprimés, car leur utilité n'est plus avérée dans la nouvelle version de l'application.
La création et la maintenance de tests de régression, outre son importance évidente pour la qualité d'un produit logiciel, est un enjeu économique majeur pour l'industrie du logiciel : gérer et exécuter les tests de régression peut vite devenir très coûteux.
Améliorer les processus de test de régression
Le profil recherché
Connaissance de problématiques de test et de vérification.
Une première expérience avec des outils d'apprentissage automatique serait un plus.
Publiée le 16/05/2026 - Réf : d4ca263c50f03279802fbcf034e2d23e