Can LLMs Test Terminal User Interfaces?

Stel je voor dat je een videogameontwikkelaar bent. Je hebt een prachtige, complexe wereld gebouwd met bergen, steden en personages, maar je bent vergeten te testen of de deuren wel echt opengaan of dat de speler vast komt te zitten in een muur. In de wereld van software is dit een nachtmerrie. Om dit te voorkomen, gebruiken programmeurs "geautomatiseerde testers"—robotische assistenten die op knoppen klikken, commando's typen en proberen de software kapot te maken om bugs te vinden voordat echte gebruikers dat doen.

Lama tijd hadden we twee hoofdtypen software om te testen. Ten eerste zijn er Grafische Gebruikersinterfaces (GUI's), zoals de apps op je telefoon of computer. Deze zijn als luxe, kleurrijke kamers met gelabelde deuren, ramen en knoppen. Testers kunnen de computer gemakkelijk vragen: "Waar is de 'Start'-knop?" en erop klikken. Ten tweede zijn er Command-Line Interfaces (CLI's), zoals oude telegrafen. Je typt een geheime code en de computer antwoordt met tekst. Deze zijn makkelijk te testen omdat ze simpel zijn: typ dit, krijg dat.

Maar er is een derde, sluipend type software genaamd een Terminal User Interface (TUI). Denk aan deze als "retro-futuristische" apps. Ze zien eruit als de oude telegrafen (gewoon tekst op een zwart scherm), maar ze gedragen zich als de luxe kamers. Ze hebben bewegende cursors, pop-upmenu's en complexe staten die veranderen terwijl je typt. Ze zijn populair bij hackers, systeembeheerders en zelfs AI-coderingsassistenten. Het probleem? We weten niet echt hoe we ze goed moeten testen. Ze zijn te complex voor de simpele telegraaf-testers, maar ze missen de "gelabelde knoppen" die de testers van de luxe kamers nodig hebben. Dit artikel stelt een grote vraag: kunnen moderne kunstmatige intelligentie (AI)-robots leren om deze lastige tekstgebaseerde apps te testen, of zijn ze net zo verward als wij?

---

Het Grote TUI-detectiveverhaal

De onderzoekers achter dit artikel besloten detective te spelen. Ze verzamelden een enorme collectie van 197 echte TUI-applicaties—van bestandsbeheerders tot systeemmonitoren—en onderwierpen deze aan een strenge stresstest. Maar eerst moesten ze een mysterie oplossen: Hoe goed worden deze apps momenteel getest?

Ze keken in de code van deze 197 apps en ontdekten een schokkend geheim. Slechts ongeveer 12% van de testcode probeerde daadwerkelijk met het scherm te communiceren. Nog erger was dat bijna de helft van de tests die het scherm wel aanraakten, nooit een enkele toets heeft getypt! Ze controleerden alleen of het scherm er goed uitzag wanneer de app opstartte, alsover het controleren van de lak van een auto zonder de motor ooit te starten. Het blijkt dat de meeste TUI's met hun ogen dicht worden getest.

Daarna bouwde het team hun eigen tools om te zien wat er zou gebeuren als ze AI en willekeur de vrije loop lieten op deze apps. Ze creëerden een "headless" lab (een computer zonder scherm, alleen een virtuele terminal) en plaatsten elke app in een speciale container. Vervolgens organiseerden ze een race tussen vier verschillende strategieën:

1. De Willekeurige Aap: Een robot die zo snel mogelijk willekeurige toetsen typt.
2. De AI-Gids: Een slim Large Language Model (LLM) dat naar het scherm kijkt en beslist wat de volgende toets moet zijn.
3. De AI-Gids met een Kaart: Dezelfde slimme robot, maar deze heeft ook de juiste "lanceercodes" (argumenten) uitgevogeld om de apps correct op te starten.
4. De AI-Scriptschrijver: Een robot die de broncode leest en een testplan schrijft voordat hij begint.

Ze draalden deze strategieën tegen de 197 apps, waarbij elke strategie precies 600 seconden (10 minuten) kreeg om bugs te vinden.

De Resultaten: Wie wint er?

De resultaten waren verrassend en een beetje tegenintuïtief.

1. De "Slimme" Robot is niet de snelste.
Wanneer de onderzoekers keken naar hoeveel bugs elke strategie vond per run, vond de Willekeurige Aap er feitelijk de meeste crashes. Waarom? Omdat hij ongelooflijk snel was. In 600 seconden kon de willekeurige robot honderden toetsen typen. De AI-robots, die bedachtzaam en "slim" waren, besteedden de meeste tijd aan nadenken en wachten op hun antwoorden, waardoor ze in dezelfde tijd slechts een dozijn toetsen konden typen.

2. Maar de "Slimme" Robot is veel efficiënter.
Hier zit de twist: Als je meet hoe goed ze zijn per toetsaanslag, waren de AI-robots 13 keer beter dan de willekeurige aap. De willekeurige aap gooide gewoon met blinddoek pijltjes en raakte er een paar door geluk. De AI-robots mikten zorgvuldig. Zij waren uniek in staat om "input-gated" bugs te vinden—crashes die alleen optreden als je een specifieke reeks toetsen typt om een verborgen menu te ontgrendelen. De willekeurige aap ontdekte de code nooit, maar de AI wel.

3. De "Lanceercode" was de echte held.
De grootste doorbraak was niet de intelligentie van de AI; het was het vermogen om de apps correct op te starten. Veel TUI's hebben specifieke bestanden of argumenten nodig om hun interface überhaupt te openen. Zonder deze elementen stoppen ze direct. De strategie die AI gebruikte om automatisch lanceer-inputs af te leiden, vond de meeste bugs en deق de meeste code. Het blijkt dat je een auto niet kunt testen als je niet weet hoe je de sleutel moet omdraaien.

4. De "Crash"-valstrik.
De onderzoekers ontdekten ook een belangrijke valstrik in de manier waarop we bugs gewoonlijk tellen. Ze vonden dat 82% van de "crashes" (programma's die onverwacht stoppen) eigenlijk gewoon programma's waren die zeiden: "Hé, ik heb een bestand nodig!" of "Ik ben aangestuurd om te stoppen!". Dit zijn geen echte bugs; het is normaal gedrag. Als je simpelweg elke keer telt dat een programma stopt, krijg je vals alarm. Het team moest een speciale "crashdetector" bouwen die naar de werkelijke tekst op het scherm kijkt om te zien of het een echte fout is of een beleefde afsluiting. Nadat ze de ruis hadden weggefilterd, vonden ze 179 echte, geldige bugs over de 197 apps.

5. Meer Code Coverage $\neq$ Meer Bugs.
In softwaretesten geloven mensen meestal dat als je meer regels code dekt, je meer bugs vindt. Het artikel suggereert dat dit niet waar is voor TUI's. Ze ontdekten dat de tests die de meeste crashes vonden, vaak een lagere code coverage hadden. Waarom? Omdat het vinden van een crash de test onmiddellijk stopt! De test wordt afgebroken, waardoor het nooit de rest van de code kan dekken. Dit betekent dat voor TUI's het tellen van hoeveel regels code geraakt zijn, een slechte manier is om te meten hoe goed een test is.

De Kernboodschap

Het artikel concludeert dat geautomatiseerd testen voor deze tekstgebaseerde interfaces mogelijk is, maar dat het nog lang niet is opgelost. Geen enkel AI-model was de duidelijke winnaar; sterker nog, een eenvoudige willekeurige tester was competitief omdat hij sneller was. De echte sleutel tot succes was hybride strategieën: het gebruik van AI om te bepalen hoe je de app start en naar de juiste staat navigeert, en vervolgens het gebruik van snelle willekeurige testen om de interface te belasten.

De auteurs waarschuwen ons ook dat we betere tools nodig hebben. De huidige manier van testen (alleen kijken of het programma stopt) zit vol met vals alarm. Ze hebben hun eigen tools uitgebracht, tuicov en tuibot, om anderen te helpen deze apps op de juiste manier te testen. De boodschap is duidelijk: TUI's zijn een groot, groeiend deel van onze softwarewereld, maar ze zijn momenteel het "wilde westen" van het testen. We hebben de middelen om ze te temmen, maar we moeten stoppen met vertrouwen op oude regels en beginnen met het ontwerpen van tests die begrijpen wat de unieke, tekstgebaseerde aard van deze interfaces inhoudt.