Testdaten: KI-Willkür für mehr Rechtssicherheit

Das Testen von (Web-)Applikationen darf gemäß DSGVO nicht mit Echtdaten erfolgen. Auch Anonymisierungsverfahren sind nur solange sicher, bis ihre Unsicherheit gezeigt wird. Dies ist oft nur eine Frage der Zeit. Moderne NLP-Systeme könnten eine neue Alternative sein, um Testdaten on demand zu erzeugen. Wie kann das aussehen? Wir haben Ideen dazu und möchten gerne Ihr Feedback einholen.

Testdatenbedarf: Testautomatisierung ausreizen

Der Bedarf an Testdaten ergibt sich insbesondere aus der Testautomatisierung mit Tools wie mateo: Wenn Regressionstests automatisch durchführbar und damit kostengünstig sind, können sie häufiger ausgeführt werden. Einige End-to-End-Tests lassen sich aber nicht beliebig oft wiederholen. Ein:e Neukund:in ist nur dann ein:e Neukund:in, wenn das System ihn:sie noch nicht kennt. Die Anzahl der Testdurchläufe ist also durch die Größe des Testdatenpools begrenzt.

Hier wollen wir nun vorstellen und diskutieren, welchen Beitrag moderne NLP-Verfahren bei der Testdatengenerierung leisten können. Besonders intuitiv wird dies am Beispiel von mateo und dem dazugehörigen mateo Recorder deutlich, welche die Automatisierung der Bedienung von Web-Oberflächen ermöglichen. Nach dem Motto „Aufnehmen statt selbst schreiben“ ist ein manueller Testablauf ausreichend, um mithilfe des Recorders die Grundsteine der Automatisierung zu legen. Sind Elemente und Aktionen identifiziert und dokumentiert, lassen sich die zu prüfenden Testabläufe ableiten und nach Belieben variieren.

Dabei nimmt der Recorder die Perspektive der Nutzer:innen beim Blick auf die Webseite ein. Er sieht alle Eingabefelder und Beschriftungen, ggf. auch schrittweise bei interaktiven Webseiten und Single-Page-Apps. Die Herausforderung der Testdatengenerierung liegt nun darin, die möglichen Eingaben der Nutzer:innen in dem jeweiligen Kontext realistisch abzubilden. Dies ist eine Kernkompetenz moderner NLP-Verfahren.

Testdatengenerierung: Spezifisch sowie explorativ

Insbesondere bei der Neuentwicklung von Applikationen sind synthetische Daten die erste Wahl, um gezielt Testabläufe zu automatisieren, früh Sicherheit herzustellen und ein Testsystem angemessen unter Last zu setzen. Verfügbarkeit, Anpassbarkeit und der damit verbundene (manuelle) Aufwand für Entwickler:innen und Tester:innen sind hier ein Problem – kommt nur ein Feld auf einer Maske hinzu, stellt sich die Frage der Testdatengenerierung jeweils neu.

Bei der viadee befassen wir uns mit innovativen Strategien, um hochwertige Testdaten für die ggf. sehr individuellen Bedürfnisse bereitzustellen und in Testabläufe zu integrieren.

• Ein Teil der Testdaten muss spezifisch und unter Kenntnis des Quellcodes gewählt sein, um eine gewisse Pfadabdeckung zu erreichen – oft durch Tester:innen oder Entwickler:innen.
• Weitere Testdatensätze müssen realistisch, aber gern auch überraschend sein, um nicht den Happy Path des:der Entwicklers:Entwicklerin weiter auszutreten und nur bekannte Ablaufpfade abzudecken. Diese explorative Form des Testens imitiert die Pfadabdeckung der Realität und konzentriert sich nicht nur auf bereits bekannten Pfade.

Für den zweiten Typ von Testdatensätzen kommt eine Generierung ohne Kenntnis des Quellcodes und des größeren fachlichen Kontextes in Betracht.

NLP-Verfahren als unerschöpfliche Datenquelle?

Für die Generierung von Testdaten gibt es klassische Ansätze, die jeweils mit ihren spezifischen Nachteilen einhergehen:

• Stress-Test- und Pen-Testing-Werkzeuge produzieren letztlich auch Testdaten für (Web-)Anwendungen, dies aber mit sehr spezifischen Zielen. Das Ergebnis ist kein realistisches Nutzer:innen-Verhalten, sondern realistisches Hacker:innen-Verhalten. Wenn man also über Testdaten-Use-Cases wie Schulungszwecke oder die Abbildung von Daten bspw. in Reports spricht, sind die Daten unbrauchbar – niemand möchte Berichte abnehmen, in denen Namen der Kund:innen unleserlichem Quellcode entsprechen.
• Das gilt in gleicher Weise für Werkzeuge, die Testdaten komplett zufällig generieren. Diese Werkzeuge gehen nicht auf den konkreten Kontext ein und werden oft an Formular-Validierungen scheitern oder detaillierte Konfigurationen erfordern.
• Vorbereitete, generische Testdaten können ebenfalls helfen, haben aber zwei offensichtliche Nachteile: die Menge der vorbereiteten Werte ist begrenzt und es kann nicht improvisiert werden. Fehlt ein Wert für einen Sonderfall, bricht der Testfall ab.
• Die beiden letzten Kategorien sind zudem durch die sehr aktive Rolle von Tester:in und Entwickler:in geprägt: Diese können ihre Detailkenntnisse des zu testenden Systems bei der Generierung von Testdaten nur schwer ablegen. Testdaten sind dann oft in Richtung des Happy Paths verzerrt, der üblicherweise durchlaufen wird.

Große Deep-Learning-Netze, gelernt auf Basis von riesigen Pools an (Web-)Texten, haben in den letzten Jahren beeindruckende Ergebnisse gezeigt und stellen damit eine vielversprechende Alternative für die Testdatengenerierung dar. Sie bieten einen neuen Lösungsansatz, indem sie das Testdatenproblem als eine Prognose-Fragestellung auf einem Text interpretieren: „Mit dieser Webseite und dieser Nutzungshistorie, was wird ein:e Nutzer:in hier eingeben?“

Dabei betrachten sie also den jeweiligen Kontext, wie zum Beispiel Formularnamen, Inputfeldnamen oder Webseitentitel. Die Ergebnisse sind dadurch oft realistisch, aber teils auch in sehr nützlicher Weise kreativ.

Diese und die nachfolgenden Beispiele sind jeweils „echt“, d. h. nur mit den beschriebenen Eingangsdaten in natürlicher Sprache durch das von OpenAI entwickelte GPT-2 generiert. Basierend auf den Daten von 8 Millionen Webseiten (~40 GB Webtext), trifft GPT-2 die Entscheidung, welches Wort oder welcher Textausschnitt für das aktuelle Szenario am wahrscheinlichsten folgt.

Testdaten-Story-Telling

Die resultierenden Testdaten haben durch die Initialisierung der großen, verwendeten Deep-Learning-Netze eine Zufallskomponente. Das erzeugt viel Bandbreite und Ergebnisse werden für den:die Betrachter:in somit anscheinend willkürlich erzeugt. Dennoch wird gleichzeitig der Kontext-Bezug ermöglicht. Damit ist gemeint, dass die Daten bei der Befüllung von Feldern, die hintereinander betrachtet werden, auch inhaltliche Bezüge haben werden, soweit man dies statistisch erwarten kann. Dies wird durch die folgenden zwei Beispiele verdeutlicht.

• Wird eine Stadt inklusive Postleitzahl abgefragt, ist das Sprachmodell in der Lage, diese Informationen zusammenhängend zu verarbeiten. Es folgert für einen zusammenhängenden Datensatz, dass eine mögliche richtige Postleitzahl für „Münster“ beispielsweise „48147“ lautet.
• Dies ist ein exemplarischer, inkrementeller Generierungsvorgang für Name, Straße, PLZ und Land bei einem Input des Vornamens „Barack“:
  • Vorname: Barack
  • Name: Obama
  • Straße: Pennsylvania Avenue 1600
  • PLZ: 20500
  • Land: U.S.A

Beim zweiten Beispiel ergibt sich also bei Vorgabe des Vornamens „Barack“ letztlich „zufällig“ die Anschrift des Weißen Hauses in Washington DC. Bei der Generierung der Straße ist der ebenfalls generierte Nachname dem Modell schon bekannt – es erzählt die Geschichte weiter.

Das ist mit klassischen Verfahren, die nicht auf KI basieren, nicht automatisch zu erreichen. Die Verwendung von NLP-Verfahren erlaubt die dynamische Anpassung an jede Applikationslandschaft, auf die wir „mit dem Blick von Nutzer:innen“ zugreifen können. Die Generierung erfolgt dabei immer schemalos, angestoßen beispielsweise durch die geforderten Inputs innerhalb einer Webapplikation.

So können Datensätze entstehen, die sich auch für Schulungszwecke oder End-to-End-Tests eignen.

Statistische Willkür und Steuerbarkeit

Im Austausch mit unseren Kund:innen für Testautomatisierungswerkzeuge und Dienstleistungen kam zusätzlich der Bedarf nach Steuerungsmöglichkeiten auf. Das heißt die Ergebnisse sollten beeinflusst werden können, so dass sie besser auf den jeweiligen Anwendungskontext ausgerichtet sind. Daraus sind weitere Ansätze hervorgegangen.

• Transfer Learning: Wenn es Feedback zu (vielen) automatisch generierten Datensätzen gibt, können wir gezielt darauf hin lernen, nützliche Datensätze zu erzeugen.
• Few Shot Learning: Wenn es bereits einen kleinen Pool an geeigneten Testdaten-Beispielen gibt, können NLP-Systeme diese als Kontext verwenden, um weitere Fälle zu ergänzen.

Das Few Shot Learning kann kombiniert werden mit der bisher betrachteten Konfiguration durch Kontextinformationen der jeweiligen Webseite bzw. des Formulars. Dadurch können möglichst spezifische Daten erzeugt werden.

Auf diese Weise ist beeinflussbar und damit wählbar, ob man die potenziellen Missverständnisse eher aufgreifen oder vermeiden möchte.

Bedingt durch die Natur des NLP-Verfahrens werden, im Sinne statistischer Willkür, immer auch zufällige Testdaten erzeugt, die den Kontext nicht beachten oder sogar missverstehen. Ambivalente Formulierungen und der Zufall führen so zur Generierung von kreativen, merkwürdigen oder auch schlicht falschen Testdaten. Diese können als Fehlerfälle ebenfalls zur optimalen Testfallabdeckung innerhalb des Prozesses beitragen oder eben Missverständnisse und Tippfehler aufzeigen, die menschlichen Nutzer:innen auch passieren könnten.

Hier wird ebenfalls sichtbar, dass die auf dem freien Internet gelernten Modelle und die daraus generierten Testdaten helfen können, Annahmen in Frage zu stellen und vielleicht auch Inklusion zu fördern:

• Vielleicht wird unsere zu testende Webseite Nutzer:innen haben, deren Namen Zeichen beinhalten, die wir noch nicht aussprechen können?
• Vielleicht werden wir auf Menschen treffen, die kein Bankkonto besitzen, aber eine Bitcoin-Adresse?

Ausblick

Die Möglichkeiten, die moderne NLP-Modelle bieten, sind bei weitem nicht erschöpft und auch für den hier betrachteten Use Case der Testdatengenerierung gibt es weitere Ideen.

• Denkbar sind Ansätze auf Datenbankebene, die Datenbank-Tabellen um Einträge ergänzen: Analog zum Few Shot Learning können Datenbanken auf Basis von wenigen Beispielen mit beliebig vielen neuen Testdaten gefüllt werden, die sinnvolle Verknüpfungen und Kontextinformationen aufweisen, um in sich stimmige Datensätze zu erstellen.
• Sprachmodelle können auch dazu verwendet werden, um Abläufe oder Annahmen in der Interaktion mit Nutzer:innen zu überprüfen oder Erwartungen zu Abläufen zu generieren (Assertions): „Nach einem Klick auf den Button In den Warenkorb erwarte ich…“
• Mit GPT-3 kursieren bereits Ansätze, die auf Basis von natürlicher Sprache Code-Modelle oder gar ganze Applikationen liefern, warum nicht auch JSON-Dokumente, um einen REST-Endpoint zu simulieren?

Interessiert? Wir haben Prototypen für mehrere Use-Cases erstellt. Gern möchten wir Ihre Ansprüche und Bedürfnisse rund um die Testdatengenerierung kennen lernen. Sprechen wir darüber!

Zu diesem Blogartikel haben maßgeblich beigetragen: Johannes Wittrock mit seiner Bachelor-Thesis an der FH Münster und Micha Krause im Rahmen eines Praktikums sowie Laura Troost mit ihrer Master-Thesis an der WWU.