Autoren: Steffen Schild, Jakob Bablitschky, Erik Elisath, Alexander Helm
Künstliche Intelligenz (KI) wird mittlerweile von Schüler:innen zur Erledigung von Hausaufgaben eingesetzt. Komplette Anwendungen werden damit nur auf Grundlage einiger Stichpunkte erstellt. KIs wie „ChatGPT“ basieren auf einem Large Language Model und wurden trainiert, um natürliche Sprache zu analysieren und zu generieren. Da Programmiersprachen formale Sprachen mit Regeln sind, können wir hier Parallelen vermuten:
Wie gut ist also eine KI darin, Sourcecode zu analysieren?
Entwickler:innen haben die Herausforderung, gute Unit-Tests zu konzipieren und stoßen dabei oft auf Probleme, wie Zeitmangel, Feature-Druck und fehlende Test-Expertise. Die dadurch entstandenen Fehler sind für Projekte zeit- und kostenintensiv.
Daher haben wir uns innerhalb unserer Community mit genau dieser Problemstellung beschäftigt. Dabei sind wir auf das IDE-Plugin CodiumAI gestoßen. Die gleichnamige Firma CodiumAI verspricht deutliche Vorteile bei der Generierung von guten Unit-Tests direkt in der Ent-wicklungsumgebung. Unser Ziel war es herauszufinden, ob KI uns bei der Erstellung von Unit-Tests unterstützen oder sogar Arbeit abnehmen kann. Wie uns dies gelungen ist, beschreibt dieser Artikel.
Unsere Vorgehensweise
Unit-Tests testen die kleinsten Einheiten in einem Produkt. Im Fall einer Software sind dies die einzelnen Methoden innerhalb einer Klasse. Für unsere Evaluierung haben wir im Folgenden mit State-of-the-Art-Methoden selbst Unit-Tests entworfen und diese mit den von CodiumAI generierten Tests verglichen.
Testobjekt
Anfangs wollten wir anonymisierte Codebeispiele aus unseren aktuellen Projekten verwenden, um eine realistische Komplexität abzubilden. Schnell haben wir festgestellt, dass dieser Ansatz schwer durchzuhalten ist. Die durch die KI erzeugten Unit-Tests werfen bei uns grundlegende Frage-stellungen auf, welche wir anhand zielgerichteter Codebeispiele genauer analysieren wollen.
Wir verwendeten eine simple add-Funktion, die wir aufgrund unserer Expertise um einige Besonderheiten erweiterten: if-Abfrage, logischer Operator, Exception (Abbildung 1).
CodiumAI setzt eine unterstützte Programmiersprache voraus. Damit die Funktion zu unserem Projektcode passt, haben wir sie in TypeScript umgesetzt (Abbildung 2).
Expertenbasiertes Testdesign
Testexpert:innen stehen bewährte Methoden zur Analyse und zum Testentwurf zur Verfügung. Wir haben sie der Reihe nach angewendet:
- Äquivalenzklassenbildung ist wichtig für die Einteilung der Testdaten, in Bezug auf die if-Abfrage. Sie reduziert die Testdaten auf den notwendigen Umfang.
- Die Grenzwertanalyse sichert die Werte ab, an denen sich die Funktion anders verhalten soll.
- Entscheidungstabellen erzeugen eine vollständige Kombinatorik der Eingabeparameter und des logischen Operators.
- Entscheidungsüberdeckung stellt sicher, dass der gesamte Quellcode getestet wird.
Für die Funktion in Abbildung 2 wurden zwei Äquivalenzklassen identifiziert (Tabelle 1).
Mit den oben genannten Methoden leiten wir nun die Testdaten in Tabelle 2 ab.
Heuristiken behandeln typische Fehlerquellen aus Projekten, beispielsweise: unendlich, String statt Number, False/True, leere Eingaben, NULL, 0 bei Division. Sie können angewendet werden, wenn sie Sinn ergeben und technisch umsetzbar sind. Aufgrund der Typsicherheit in TypeScript kompilieren die Aufrufe add(“String1”, “”) und add(NULL, undefined) nicht. Sie können im Testfall nicht verwendet werden, womit sich die Heuristiken reduzieren. Im Sourcecode wird der Additionsoperator der Programmier-sprache direkt verwendet. Diesem vertrauen wir in dem Fall und müssen daher die Korrektheit der Addition nicht separat prüfen. Eine regressionsvermeidende Teststrategie könnte dennoch entsprechende Testfälle vorsehen, falls später bei-spielsweise die Additionsmethode ausgetauscht wird. Wir nehmen einige Testdaten dazu auf, siehe Tabelle 3.
Aus Sicht eines Testexperten ist damit eine ausreichende Menge von Unit-Tests entstanden.
KI-generierte Testfälle
Mit diesen Vorarbeiten ist unsere Erwartungshaltung an eine auf die Erzeugung von Unit-Tests spezialisierte KI formuliert: die Implementierung dieses Testdesigns. Für die Funktion aus Abbildung 2 haben wir durch CodiumAI1 (Version 0.6.15, Stand 3.7.2023) sechs Unit-Tests generiert. Das Ergebnis sehen wir in Abbildung 3. Bei uns hat es eine Mischung aus anfänglicher Begeisterung und späterer Verwunderung hervorgerufen.
Begeistert waren wir zunächst, weil ein methodisches Vorgehen erkennbar scheint. Alle Testfälle ergeben Sinn, sind jedoch weder ausreichend noch vollständig. Es gibt eine vollständige Kombinatorik in den Zeilen 46 – 48 und 59 – 61. Den Wert 0 zu verwenden ist interessant, weil wir hier eine Interpretation des booleschen Wertes False vermuten könnten. Auch auf die Idee, NaN (Not a Number) als Eingabewert statt z. B. undefined zu verwenden, sind wir nicht gekommen.
Ernüchterung entsteht bei genauerem Hinsehen: Viele Unit-Tests liefern keinen Mehrwert, weil sie die gleiche Äquivalenzklasse abdecken (Zeilen 33 – 35, 40 – 41).
Alle Unit-Tests prüfen mehrere erwartete Ergebnisse (expect), was bei einem negativen Testergebnis zu vermehrtem Aufwand bei der Suche nach dem eigentlichen Problem führt.
Die Implementierung der KI ist inkonsequent. Im Vergleich zu anderen Stellen ist die Kombinatorik in den Zeilen 53 – 54 und 66 – 67 unvollständig.
Gleitkommazahlen in Zeile 52ff sind sinnvoll, werden aber nur für die Eingabewerte umgesetzt, nicht für die Additionsergebnisse.
Die Bedeutung des Testfalls in Zeile 58ff ist unklar. Die Bezeichnung ist unvollständig, die inhaltliche Prüfung ist passend zum Sourcecode. Die Struktur legt außerdem eine Grenzwertanalyse nahe, allerdings ohne die korrekten Werte aus Tabelle 2. Unsere Erfahrung mit dem Verhalten von CodiumAI lässt darauf schließen, dass es Probleme mit den Datentypen in TypeScript hat und number hier fälschlich als ganzzahligen Datentyp interpretiert wird.
In Zeile 52ff wurde der Datentyp korrekt erkannt. Von den erwarteten Testfällen wurden nur wenige umgesetzt. Daher haben wir noch einmal gestartet und zwölf Unit-Tests erzeugen lassen, siehe unser Repository. Das Ergebnis ist leider erneut zwiespältig mit positiven und negativen Erkenntnissen, wobei letztere überwiegen. So ist positiv, dass CodiumAI versucht, maximale und mininmale Eingaben zu berücksichtigen und dass die Testdaten Gleitkommawerte in den erwarteten Ergebnissen umfassen.
Negativ fällt u.a. auf, dass trotz angeblicher Unterstützung für TypeScript zwei Unit-Tests von CodiumAI generiert werden, die nicht kompilierbar sind. Außerdem werden Testdaten doppelt verwendet und sieben der Tests betreffen die gleiche Äquivalenzklasse, weshalb sechs überflüssig sind.
Fazit der technischen Analyse
Wir hatten uns etwas mehr von den Ergebnissen aus der Arbeit mit CodiumAI hinsichtlich der Unit-Tests erhofft. Die von CodiumAI generierten Tests dienen einerseits als Inspiration für zumeist vernachlässigte Edge-Cases. Zum Teil wird der Sourcecode durch CodiumAI gut analysiert (Abbildung 5), sowie mit Unit-Tests abgedeckt. Andererseits war eine vollständige Überdeckung unserer Testszenarien mit CodiumAI nicht zu erreichen.
Wir hatten eine höhere Testfallüberdeckung mit besserer Kombinatorik erwartet. Wegen der isolierten Generierung der Tests ist eine Nutzung gemeinsamer Daten oder vorbereitender Schritte nicht möglich. Die Erzeugung von Unit-Tests erfolgt nicht deterministisch. Wir können uns daher nicht auf die Qualität der Testfälle verlassen. Je mehr Tests wir durch CodiumAI generieren ließen, umso geringer wurde deren Sinnhaftig-keit und umso größer die Anzahl fehlerhafter Tests. Generell überwiegen also eher die negativen Eindrücke, die wir anhand der Codebeispiele detailliert aufgezeigt haben.
Praxiscode aus Projekt
Bei der Evaluierung anhand mehrerer Klassen aus einem realen Projekt hat CodiumAI weiterhin sinnvolle Tests generiert. Die bereits geschilderten Probleme blieben bestehen, wobei der Eindruck entstanden ist, dass CodiumAI mit einem komplexeren Code noch mehr Schwierigkeit hat (siehe öffentliches Github Repository der Evaluierung).
Unsere Erkenntnisse
Mit der Evaluierung von CodiumAI möchten wir abschließend einige Pro & Contras aufzeigen.
Hohe Patchrates: Durch das hohe Investment vieler Firmen in „KI“ haben wir ein großes Wachstum im Bereich der KI-Tools. Bei CodiumAI erleben wir regelmäßig neue Funktionen und Bugfixes. Wir konnten schon positive Ver-änderungen beobachten und sind gespannt auf kommende Features.
Zu viel Vertrauen in KI-Tools: Unsere Evaluierung hat schnell gezeigt, dass Vorsicht geboten ist, wieviel Vertrauen man in die KI-Tools von heute legt. Wie bei einem externen Zulieferer müssen die Arbeitsergebnisse vor der produktiven Verwendung geprüft werden.
Noch nicht ausgereift: Aus technischer Sicht fällt schnell auf, dass CodiumAI in der Beta-Phase steckt. Die Probleme bei der strukturellen Analyse des Sourcecodes führen zu fehlerhaft erzeugten Testdaten und nicht lauffähigen Unit-Tests. Mit Typisierung und Sichtbarkeit von Methoden kommt das Tool nicht zurecht. Die Methodik im Testdesign ist nicht ausgereift.
Für unerfahrene Entwickler:innen wenig hilfreich: Zu oft muss noch selbst Hand angelegt werden, um die mithilfe von KI generierten Tests zu korrigieren, zu vervollständigen und lauffähig zu machen. CodiumAI bietet dabei zu wenig Unterstützung. Eine unreflektierte, unbegleitete Ver-wendung birgt mehr Gefahren als Nutzen.
Inspiration bei Testautomatisierung: Beim Erstellen von Grundgerüsten für automatisierte Testfälle können KI-Tools zumindest anfangs Arbeit abnehmen und Inspiration liefern. Erfahrene Testautomatisierer erkennen Fehler und schlechte Strukturen in den generierten Tests und können diese schnell ausbessern und erweitern.
Datenschutz: CodiumAI ist ein cloud-basiertes Plugin. Der Sourcecode wird zur Analyse an die CodiumAI Server übertragen. CodiumAI nimmt Datenschutz laut eigenen Angaben sehr ernst. In Bezug auf Sicherheitsstandards vieler Firmen kann dies trotzdem ein Problem darstellen .
Kein Ersatz für Test-Know-How: Schlussendlich muss man sagen, dass KI-Tools keinen Ersatz für echte Testerfahrung bieten. Dafür sind die Ergebnisse methodisch zu inkonsistent und nicht verlässlich.
Ausblick
Insgesamt sehen wir hierbei deutlich die Grenzen aktueller KI-Implementierung. Dennoch sind wir davon überzeugt, dass hier ein sehr interessanter Ansatz mit viel Potential vorliegt.
Die Autoren:
Steffen Schild (ALTEN GmbH) ist Diplom Informatiker und agiler Testspezialist aus Leidenschaft. Als Leiter des Fachbereichs Test koordiniert er Wissensaustausch und Weiterbildung. Als ISTQB-Trainer und Conference Speaker diskutiert er sein Mindset gerne mit anderen. In agilen Kundenprojekten setzt er seine Erfahrung um.
Erik Elisath (ALTEN GmbH) ist seit 2022 als Consultant mit dem Schwerpunkt Testautomatisierung im Bereich Public Sector tätig. Während des Informatik-Studium sammelte er erste Erfahrungen mit Softwaretesting und brachte später in agilen Teams als Vertrauensperson viel Qualität ein.
Jakob Bablitschky (ALTEN GmbH) ist seit 2011 als Full-Stack Entwickler in verschiedenen Projekten unterwegs. Mittlerweile als Senior Consultant tätig, unterstützt er Teams mit
Wissen aus verschiedensten Bereichen. Seit 2021 legt er seinen Fokus größtenteils auf Cloudtechnologien.
Alexander Helm (ALTEN GmbH) ist Diplom-Informatiker, Business Analyst und seit 20 Jahren in der Softwareentwicklung tätig. Dank früher Erfahrung mit dem Wert eines guten und kooperativen
Testens liegt ihm bis heute der Test und die Qualitätssicherung am Herzen.
