On the Flakiness of LLM-Generated Tests for Industrial and Open-Source Database Management Systems
Diese Studie untersucht die Unzuverlässigkeit (Flakiness) von von LLMs generierten Tests für vier Datenbankmanagementsysteme und zeigt auf, dass solche Tests eine leicht höhere Unzuverlässigkeitsrate als bestehende aufweisen, was primär auf die Abhängigkeit von nicht garantierten Ausführungsreihenfolgen zurückzuführen ist, sowie dass LLMs häufig bestehende Unzuverlässigkeitsmuster aus ihren Prompts propagieren, insbesondere in Closed-Source-Umgebungen.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie stellen einem sehr talentierten, belesenen Roboter-Assistenten eine Aufgabe zu: Er soll Ihnen helfen, Sicherheitsprüfungen für eine komplexe Maschine zu schreiben, wie zum Beispiel eine Datenbank, die alle wichtigen Informationen Ihres Unternehmens speichert. Sie geben dem Roboter ein paar Beispiele dafür, wie Sie diese Prüfungen schreiben, und er beginnt, hunderte neue davon zu produzieren.
Dieses Papier ist wie ein Zeugnis darüber, wie zuverlässig diese robotergeschriebenen Prüfungen tatsächlich sind. Die Forscher wollten wissen: Arbeiten diese robotergeschriebenen Tests konsistent oder agieren sie „flaky“ (unzuverlässig)?
Was ist ein „flaky“ Test?
Denken Sie an einen „flaky“ Test wie an einen Münzwurf, bei dem man erwartet, dass jedes Mal Kopf kommt.
- Ein normaler Test: Sie führen ihn aus, und er sagt „Bestanden“. Sie führen ihn erneut aus, und er sagt „Bestanden“. Er ist zuverlässig.
- Ein flaky Test: Sie führen ihn aus, und er sagt „Bestanden“. Sie führen ihn erneut aus, und er sagt „Fehlgeschlagen“. Sie führen ihn ein drittes Mal aus, und er sagt wieder „Bestanden“.
Dies ist ein Albtraum für Ingenieure. Wenn ein Test zufällig fehlschlägt, können sie nicht unterscheiden, ob die Maschine tatsächlich defekt ist oder ob der Test einfach nur einen schlechten Tag hatte. Es verschwendet Zeit und führt dazu, dass das Vertrauen in die Sicherheitsprüfungen schwindet.
Das Experiment: Der Roboter gegen die reale Welt
Die Forscher richteten ein Experiment mit vier verschiedenen „Maschinen“ (Datenbanken) ein:
- SAP HANA: Eine massive, komplexe, quelloffene industrielle Datenbank (wie ein geheimer, hochtechnologischer Tresor).
- MySQL, SQLite und DuckDB: Beliebte Open-Source-Datenbanken (wie bekannte, öffentliche Baupläne).
Sie verwendeten zwei verschiedene „Robotergehirne“ (Large Language Models, oder LLMs): GPT-4o und Mistral. Sie baten diese Roboter, bestehende Tests zu betrachten und neue zu schreiben, um mehr Szenarien abzudecken (ein Prozess namens „Test Amplification“).
Die wichtigsten Erkenntnisse
1. Der Roboter ist etwas „zappeliger“ als die Menschen.
Die Forscher fanden heraus, dass die von den Robotern geschriebenen Tests etwas wahrscheinlicher „flaky“ waren als die Tests von menschlichen Ingenieuren. Während die von Menschen geschriebenen Tests weitgehend solide waren, hatten die Tests des Roboters eine höhere Chance, zufällig fehlschlagen.
2. Die Verwirrung über die Reihenfolge (Der Hauptschuldige).
Der größte Grund für die Flakiness der Roboter-Tests? Verwirrung über die Reihenfolge.
Stellen Sie sich vor, Sie bitten einen Roboter, die drei besten Schüler einer Klasse aufzulisten. Wenn Sie ihm nicht sagen, wie er sie sortieren soll (nach Note, Name, Größe), liefert er Ihnen bei jedem Durchlauf vielleicht eine andere Liste.
- Der menschliche Fehler: Der Roboter schrieb Tests, die davon ausgingen, dass die Datenbank Ergebnisse immer in einer bestimmten Reihenfolge zurückgibt (wie eine Liste, die alphabetisch sortiert ist).
- Die Realität: Datenbanken geben Ergebnisse oft in einer zufälligen Reihenfolge zurück, sofern man ihnen nicht explizit sagt, dass sie sortieren sollen.
- Das Ergebnis: Der Test bestand einmal (weil die zufällige Reihenfolge zufällig mit der Vermutung des Roboters übereinstimmte) und schlug beim nächsten Mal fehl (weil sich die Reihenfolge änderte). Dies geschah in 63 % der flaky Roboter-Tests.
3. Der „Nachahmer-Effekt“ (Flakiness Transfer).
Dies ist der interessanteste Teil. Die Forscher beschlossen, einen Trick anzuwenden. Sie nahmen einen bereits existierenden, „flaky“ Test (ein schlechtes Beispiel) und fütterten den Roboter damit als Beispiel dafür, wie man einen Test schreibt.
- Das Ergebnis: Der Roboter kopierte nicht nur den Code; er kopierte die schlechte Angewohnheit. Er begann, neue Tests zu schreiben, die auf exakt dieselbe Weise „flaky“ waren.
- Der Unterschied: Der Roboter tat dies viel häufiger bei SAP HANA (der geheimen industriellen Datenbank) als bei den Open-Source-Datenbanken. Warum? Weil der Roboter den Code von SAP HANA noch nie in seinem Training gesehen hatte. Er verließ sich stark auf die Beispiele, die Sie ihm gaben, selbst wenn diese fehlerhaft waren. Bei Open-Source-Datenbanken hatte der Roboter bereits ähnliche Codes gesehen und war daher etwas unabhängiger.
4. Der Kampf mit der Kompilierung.
Für die komplexe, geschlossene SAP HANA hatte der Roboter etwa die Hälfte der Zeit Schwierigkeiten, Code zu schreiben, der überhaupt kompilierte (als Programm funktionierte). Es ist, als würde der Roboter versuchen, Anweisungen für einen Automotor zu schreiben, den er noch nie gesehen hat, indem er nur die wenigen Diagramme nutzt, die man ihm gegeben hat. Er wurde verwirrt und machte Syntaxfehler.
Das Fazit
Das Paper kommt zu dem Schluss, dass KI zwar großartig darin ist, Code zu schreiben, der natürlich und menschenähnlich wirkt, aber eine blinde Stelle hat: Sie versteht nicht immer die verborgenen Regeln des Systems, das sie testet.
- Die „Reihenfolge-Falle“: Sie vergisst oft, dass Datenbanken Ergebnisse nicht garantieren, sofern man es nicht anders angibt.
- Die „Schlechtes-Beispiel-Falle“: Wenn Sie einer KI einen „flaky“ Test zeigen, wird sie höchstwahrscheinlich diese Unzuverlässigkeit kopieren, besonders wenn sie das System nicht gut kennt.
Der Rat: Bevor Sie eine KI Ihre Sicherheitsprüfungen schreiben lassen, müssen Sie sicherstellen, dass Ihre bestehenden Prüfungen absolut solide sind. Wenn Sie der KI schlechte Beispiele geben, wird sie schlechte Angewohnheiten lernen. Zudem müssen Sie der KI sehr spezifische Anweisungen darüber geben, wie das System funktioniert, da sie die verborgenen Regeln nicht aus eigener Kraft erraten kann.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.