Can LLMs Test Terminal User Interfaces?

Stellen Sie sich vor, Sie sind ein Videospielentwickler. Sie haben eine wunderschöne, komplexe Welt mit Bergen, Städten und Charakteren erschaffen, aber Sie haben vergessen zu testen, ob die Türen tatsächlich aufgehen oder ob der Spieler in einer Wand stecken bleibt. In der Welt der Software ist das ein Albtraum. Um dies zu verhindern, nutzen Programmierer „automatisierte Tester“ – Roboterassistenten, die auf Knöpfe klicken, Befehle eintippen und versuchen, die Software kaputt zu machen, um Fehler zu finden, bevor echte Benutzer sie bemerken.

Lange Zeit hatten wir zwei Hauptarten von Software zu testen. Erstens gibt es grafische Benutzeroberflächen (GUIs), wie die Apps auf Ihrem Telefon oder Computer. Diese sind wie schicke, farbenfrohe Räume mit beschrifteten Türen, Fenstern und Knöpfen. Tester können den Computer leicht fragen: „Wo ist der ‚Start‘-Button?“ und darauf klicken. Zweitens gibt es Kommandozeilen-Schnittstellen (CLIs), die wie alte Telegrafen funktionieren. Sie tippen einen geheimen Code ein, und der Computer antwortet mit Text. Diese sind einfach zu testen, weil sie simpel sind: Tippe dies, erhalte das.

Aber es gibt einen dritten, hinterlistigen Typ von Software namens Terminal-Benutzeroberfläche (TUI). Denken Sie an diese als „retro-futuristische“ Apps. Sie sehen aus wie die alten Telegrafen (nur Text auf einem schwarzen Bildschirm), aber sie verhalten sich wie die schicken Räume. Sie haben bewegliche Cursor, Pop-up-Menüs und komplexe Zustände, die sich ändern, während man tippt. Sie sind beliebt bei Hackern, Systemadministratoren und sogar KI-Coding-Assistenten. Das Problem dabei? Wir wissen nicht wirklich, wie wir sie richtig testen sollen. Sie sind zu komplex für die einfachen Telegrafen-Tester, aber ihnen fehlen die „beschrifteten Knöpfe“, die die Tester der schicken Räume benötigen. Diese Arbeit stellt die große Frage: Können moderne Künstliche Intelligenz (KI)-Roboter lernen, diese kniffligen textbasierten Apps zu testen, oder sind sie genauso verwirrt wie wir?

---

Die große TUI-Detektivgeschichte

Die Forscher hinter dieser Arbeit beschlossen, Detektiv zu spielen. Sie sammelten eine riesige Sammlung von 197 realen TUI-Anwendungen – alles von Dateimanagern bis hin zu Systemmonitoren – und unterzogen sie einem strengen Stresstest. Aber zuerst mussten sie ein Rätsel lösen: Wie gut werden diese Apps aktuell getestet?

Sie blickten in den Code dieser 197 Apps und fanden ein schockierendes Geheimnis. Nur etwa 12 % des Testcodes versuchten tatsächlich, mit dem Bildschirm zu interagieren. Schlimmer noch: Fast die Hälfte der Tests, die den Bildschirm überhaupt berührten, tippte niemals eine einzige Taste ein! Sie prüften lediglich, ob der Bildschirm beim Öffnen der App korrekt aussah – so, als würde man die Lackierung eines Autos prüfen, aber niemals den Motor starten. Es stellt sich heraus, dass die meisten TUIs mit geschlossenen Augen getestet werden.

Also baute das Team seine eigenen Werkzeuge, um zu sehen, was passieren würde, wenn man KI und dem Zufall freien Lauf ließe. Sie erstellten ein „Headless“-Labor (einen Computer ohne Bildschirm, nur mit einem virtuellen Terminal) und verpackten jede App in einen speziellen Container. Dann ließen sie einen Wettlauf zwischen vier verschiedenen Strategien antreten:

1. Der Zufalls-Affe: Ein Roboter, der einfach so schnell er kann, wahllos Tasten drückt.
2. Der KI-Guide: Ein intelligentes Large Language Model (LLM), das auf den Bildschirm schaut und entscheidet, was als Nächstes getippt wird.
3. Der KI-Guide mit einer Karte: Derselbe smarte Roboter, der diesmal jedoch auch die korrekten „Start-Codes“ (Argumente) herausgefunden hat, um die Apps ordnungsgemäß zu starten.
4. Der KI-Drehbuchautor: Ein Roboter, der den Quellcode liest und vor dem Start einen Testplan schreibt.

Sie ließen diese Strategien gegen die 197 Apps antreten und gaben jeder genau 600 Sekunden (10 Minuten) Zeit, um Fehler zu finden.

Die Ergebnisse: Wer gewinnt?

Die Ergebnisse waren überraschend und etwas kontraintuitiv.

1. Der „smarte“ Roboter ist nicht der schnellste.
Als die Forscher untersuchten, wie viele Bugs jede Strategie pro Durchlauf fand, fand der Zufalls-Affe tatsächlich die meisten Abstürze. Warum? Weil er unglaublich schnell war. In 600 Sekunden konnte der zufällige Roboter hunderte von Tasten eingeben. Die KI-Roboter, die „intelligent“ und „bedacht“ waren, verbrachten die meiste Zeit mit Nachdenken und Warten auf ihre Antworten, sodass sie im gleichen Zeitraum nur etwa ein Dutzend Tasten eingeben konnten.

2. Aber der „smarte“ Roboter ist viel effizienter.
Hier liegt der Clou: Wenn man misst, wie gut sie pro Tastendruck sind, waren die KI-Roboter 13 Mal besser als der Zufalls-Affe. Der Zufalls-Affe war wie jemand, der im Dunkeln blind Pfeile wirft und durch Glück ein paar trifft. Die KI-Roboter hingegen zielten präzise. Sie waren in der Lage, „eingabegesteuerte“ Bugs zu finden – Abstürze, die nur auftreten, wenn man eine bestimmte Sequenz von Tasten eingibt, um ein verstecktes Menü freizuschalten. Der Zufalls-Affe hat den Code nie gefunden, aber die KI schon.

3. Der „Start-Code“ war der wahre Held.
Der größte Durchbruch war nicht die Intelligenz der KI, sondern ihre Fähigkeit, die Apps korrekt zu starten. Viele TUIs benötigen spezifische Dateien oder Argumente, um überhaupt ihre Benutzeroberfläche anzuzeigen. Ohne diese beenden sie sich sofort. Die Strategie, die die KI nutzte, um automatisch Start-Eingaben abzuleiten, fand die meisten Bugs und deckte den meisten Code ab. Es zeigt sich: Man kann ein Auto nicht testen, wenn man nicht weiß, wie man den Schlüssel dreht.

4. Die „Crash-Falle“.
Die Forscher entdeckten auch eine große Falle in der Art und Weise, wie wir Bugs normalerweise zählen. Sie fanden heraus, dass 82 % der „Abstürze“ (unerwartetes Beenden des Programms) eigentlich nur darauf zurückzuführen waren, dass die Programme sagten: „Hey, ich brauche eine Datei!“ oder „Ich wurde angewiesen, aufzuhören!“. Das sind keine echten Bugs; das ist normales Verhalten. Wenn man einfach jedes Mal zählt, wenn ein Programm stoppt, erhält man Fehlalarme. Das Team musste einen speziellen „Crash-Detektor“ bauen, der den tatsächlichen Text auf dem Bildschirm analysiert, um zu sehen, ob es sich um einen echten Fehler oder nur um ein höfliches Beenden handelt. Nach dem Filtern des Rauschens fanden sie 179 echte, valide Bugs über die 197 Apps hinweg.

5. Mehr Codeabdeckung $\neq$ Mehr Bugs.
In der Softwareprüfung herrscht oft der Glaube, dass man mehr Fehler findet, wenn man mehr Codezeilen abdeckt. Die Arbeit legt nahe, dass dies für TUIs nicht gilt. Sie fanden heraus, dass die Tests, die die meisten Abstürze fanden, oft eine geringere Codeabdeckung hatten. Warum? Weil ein Fund eines Absturzes den Test sofort beendet! Der Test wird abgebrochen, sodass er nie den Rest des Codes abdecken kann. Das bedeutet, dass das Zählen der berührten Codezeilen für TUIs ein schlechter Weg ist, um die Qualität eines Tests zu messen.

Das Faz-it

Die Arbeit kommt zu dem Schluss, dass automatisiertes Testen für diese textbasierten Schnittstellen möglich ist, aber noch lange nicht gelöst. Kein einzelnes KI-Modell war der klare Gewinner; tatsächlich war ein einfacher Zufallstester konkurrenzfähig, weil er schneller war. Der wahre Schlüssel zum Erfolg war eine Hybrid-Strategie: Die KI nutzen, um die App zu starten und den richtigen Zustand zu erreichen, und dann einen Hochgeschwindigkeits-Zufallstester nutzen, um die Benutzeroberfläche unter Stress zu setzen.

Die Autoren warnen uns auch, dass wir bessere Werkzeuge benötigen. Die aktuelle Art des Testens (nur zu prüfen, ob das Programm stoppt) ist voller Fehlalarme. Sie haben ihre eigenen Werkzeuge, tuicov und tuibot, veröffentlicht, um anderen zu helfen, diese Apps richtig zu testen. Die Botschaft ist klar: TUIs sind ein riesiger, wachsender Teil unserer Softwarewelt, aber sie sind derzeit der „Wilde Westen“ des Testens. Wir haben die Werkzeuge, um sie zu zähmen, aber wir müssen aufhören, uns auf alte Regeln zu verlassen, und anfangen, Tests zu entwickeln, die die einzigartige, textbasierte Natur dieser Schnittstellen verstehen.