Can LLMs Test Terminal User Interfaces?

Imaginez que vous êtes un développeur de jeux vidéo. Vous avez construit un monde magnifique et complexe avec des montagnes, des villes et des personnages, mais vous avez oublié de tester si les portes s'ouvrent réellement ou si le joueur reste coincé dans un mur. Dans le monde du logiciel, c'est un cauchemar. Pour éviter cela, les programmeurs utilisent des « testeurs automatisés » — des assistants robotiques qui cliquent sur des boutons, tapent des commandes et tentent de casser le logiciel pour trouver des bugs avant que les vrais utilisateurs ne le fassent.

Pendant longtemps, nous avons eu deux principaux types de logiciels à tester. Premièrement, il y a les Interfaces Utilisateur Graphiques (GUI), comme les applications sur votre téléphone ou votre ordinateur. Elles sont comme des pièces élégantes et colorées avec des portes, des fenêtres et des boutons étiquetés. Les testeurs peuvent facilement demander à l'ordinateur : « Où est le bouton 'Démarrer' ? » et cliquer dessus. Deuxièmement, il y a les Interfaces en Ligne de Commande (CLI), qui sont comme de vieux télégraphes. Vous tapez un code secret, et l'ordinateur répond par du texte. Elles sont faciles à tester car elles sont simples : tapez ceci, obtenez cela.

Mais il existe un troisième type de logiciel, plus sournois, appelé Interface Utilisateur en Terminal (TUI). Considérez ces interfaces comme des applications « rétro-futuristes ». Elles ressemblent aux vieux télégraphes (juste du texte sur un écran noir), mais elles se comportent comme les pièces élégantes. Elles ont des curseurs mobiles, des menus contextuels et des états complexes qui changent au fur et à mesure que vous tapez. Elles sont populaires auprès des hackers, des administrateurs système et même des assistants de codage IA. Le problème ? Nous ne savons pas vraiment comment les tester correctement. Elles sont trop complexes pour les testeurs de télégraphes simples, mais elles manquent des « boutons étiquetés » dont les testeurs de pièces élégantes ont besoin. Cette étude pose une grande question : les robots d'Intelligence Artificielle (IA) modernes peuvent-ils apprendre à tester ces applications textuelles délicates, ou sont-ils tout aussi confus que nous ?

---

La grande histoire de l'enquêteur TUI

Les chercheurs derrière cette étude ont décidé de jouer les détectives. Ils ont rassemblé une vaste collection de 197 applications TUI du monde réel — allant des gestionnaires de fichiers aux moniteurs de système — et les ont soumises à un test de résistance rigoureux. Mais d'abord, ils devaient résoudre un mystère : À quel point ces applications sont-elles bien testées actuellement ?

Ils ont scruté le code de ces 197 applications et ont découvert un secret choquant. Seulement environ 12 % du code de test tentait réellement d'interagir avec l'écran. Pire encore, près de la moitié des tests qui touchaient l'écran ne tapaient jamais une seule touche ! Ils vérifiaient simplement si l'écran présentait le bon aspect lors de l'ouverture de l'application, comme si l'on vérifiait la peinture d'une voiture sans jamais démarrer le moteur. Il s'avère que la plupart des TUI sont testées les yeux fermés.

L'équipe a donc construit ses propres outils pour voir ce qui se passerait si elle laissait l'IA et le hasard en liberté sur ces applications. Ils ont créé un laboratoire « headless » (un ordinateur sans écran, juste un terminal virtuel) et ont encapsulé chaque application dans un conteneur spécial. Ils ont ensuite organisé une course entre quatre stratégies différentes :

1. Le Singe Aléatoire : Un robot qui tape simplement des touches au hasard le plus vite possible.
2. Le Guide IA : Un modèle de langage étendu (LLM) intelligent qui regarde l'écran et décide de ce qu'il faut taper ensuite.
3. Le Guide IA avec une Carte : Le même robot intelligent, mais cette fois-ci, il a également déduit les bons « codes de lancement » (arguments) pour démarrer correctement les applications.
4. Le Scénariste IA : Un robot qui lit le code source et écrit un plan de test avant de commencer.

Ils ont testé ces stratégies contre les 197 applications, donnant à chacune exactement 600 secondes (10 minutes) pour trouver des bugs.

Les Résultats : Qui gagne ?

Les résultats ont été surprenants et un peu contre-intuitifs.

1. Le robot « intelligent » n'est pas le plus rapide.
Lorsque les chercheurs ont examiné le nombre de bugs trouvés par chaque stratégie par exécution, le Singe Aléatoire a en fait trouvé le plus de plantages. Pourquoi ? Parce qu'il était incroyablement rapide. En 600 secondes, le robot aléatoire pouvait taper des centaines de touches. Les robots IA, plus réfléchis et « intelligents », passaient la majeure partie de leur temps à réfléchir et à attendre leurs réponses, ils ne parvenaient donc à taper qu'une douzaine de touches dans le même laps de temps.

2. Mais le robot « intelligent » est beaucoup plus efficace.
Voici le rebondissement : si vous mesurez leur efficacité par pression de touche, les robots IA étaient 13 fois meilleurs que le singe aléatoire. Le singe aléatoire lançait des fléchettes dans le noir et en touchait quelques-unes par chance. Les robots IA visaient avec précision. Ils étaient capables de trouver des bugs « liés à l'entrée » (input-gated) — des plantages qui ne surviennent que si vous tapez une séquence spécifique de touches pour déverrouiller un menu caché. Le singe aléatoire n'a jamais trouvé le code, mais l'IA, oui.

3. Le « Code de Lancement » fut le véritable héros.
La plus grande percée n'était pas l'intelligence de l'IA, mais sa capacité à comprendre comment démarrer les applications. De nombreux TUI nécessitent des fichiers ou des arguments spécifiques pour ouvrir leur interface. Sans eux, elles s'arrêtent immédiatement. La stratégie qui utilisait l'IA pour dériver automatiquement les entrées de lancement a trouvé le plus de bugs et a couvert le plus de code. Il s'avère que l'on ne peut pas tester une voiture si l'on ne sait pas comment tourner la clé.

4. Le piège du « Crash ».
Les chercheurs ont également découvert un piège majeur dans la façon dont nous comptons habituellement les bugs. Ils ont découvert que 82 % des « plantages » (programmes s'arrêtant de manière inattendue) étaient en réalité des programmes disant simplement : « Hé, j'ai besoin d'un fichier ! » ou « On m'a dit de m'arrêter ! ». Ce ne sont pas de vrais bugs ; c'est un comportement normal. Si vous comptez simplement chaque fois qu'un programme s'arrête, vous obtenez une fausse alerte. L'équipe a dû construire un « détecteur de crash » spécial qui analyse le texte réel à l'écran pour voir s'il s'agit d'une véritable erreur ou d'une sortie polie. Une fois le bruit filtré, ils ont trouvé 179 vrais bugs valides à travers les 197 applications.

5. Plus de Couverture de Code $\neq$ Plus de Bugs.
Dans le test de logiciels, les gens croient généralement que si l'on couvre plus de lignes de code, on trouve plus de bugs. L'étude suggère que ce n'est pas vrai pour les TUI. Ils ont découvert que les tests qui trouvaient le plus de plantages avaient souvent une couverture de code plus faible. Pourquoi ? Parce que trouver un plantage interrompt immédiatement le test ! Le test est coupé court, il ne peut donc jamais atteindre le reste du code. Cela signifie que pour les TUI, compter le nombre de lignes de code touchées est une mauvaise façon de mesurer la qualité d'un test.

L'essentiel

L'étude conclut que le test automatisé de ces interfaces textuelles est possible, mais qu'il est loin d'être résolu. Aucun modèle d'IA n'a été le vainqueur incontesté ; en fait, un simple testeur aléatoire était compétitif car il était plus rapide. La véritable clé du succès résidait dans les stratégies hybrides : utiliser l'IA pour comprendre comment démarrer l'application et naviguer vers le bon état, puis utiliser un test aléatoire à haute vitesse pour tester l'interface sous pression.

Les auteurs nous avertissent également que nous avons besoin de meilleurs outils. La méthode actuelle de test (vérifier simplement si le programme s'arrête) est pleine de fausses alertes. Ils ont publié leurs propres outils, tuicov et tuibot, pour aider les autres à tester ces applications correctement. Le message est clair : les TUI sont une partie immense et croissante de notre monde logiciel, mais elles sont actuellement le « Far West » du test. Nous avons les outils pour commencer à les dompter, mais nous devons cesser de nous appuyer sur les vieilles règles et commencer à concevoir des tests qui comprennent la nature textuelle unique de ces interfaces.