Zum Inhalt springen

Newseintrag

Das Dilemma mit den Produktivdaten

OSTC  Testdatenmanagement 

Der Begriff Testdatenmanagement geistert immer mehr im Testumfeld herum. Bereits als wesentlicher Teil der Testplanung erkannt, wirft die Beschaffung aussagekräftiger Testdaten wichtige Fragen auf: Kann, soll und darf man Echtdaten verwenden oder soll man Testdaten eher künstlich generieren? Woher weiß man, ob die Testdaten die Realität ausreichend widerspiegeln? Im Folgenden ein kurzer Vergleich verschiedener Vorgehensweisen zu Testdatenbeschaffung.

Synthetische Daten

Grundsätzlich erlaubt die Verwendung von synthetischen Testdaten eine große Vielfalt an Konfigurationen und Datenauswahl. In den Werkzeugen für die Generierung können Muster und die Verteilung der Werte eingestellt werden. Dabei können gezielte Entwurfsverfahren wie Grenzwertanalysen angewendet werden. Auch Negativtests mit Daten, die im Feld nicht vorkommen dürften, sind möglich.

Der Haken daran: die künstlich erzeugte Verteilung ist nur so echt wie das dahinterliegende Modell. Es wird zweierlei Wissen über die realen Daten vorausgesetzt.

  • Erstens: welche Eigenschaften und Aspekte sind für das Testziel relevant?
    • Oder von der anderen Seite betrachtet: welche Eigenschaften halte ich für unwesentlich. Kommt es zum Beispiel nur auf die Länge von Namen an? Ist es wirklich egal, ob bestimmte Anfangsbuchstaben häufiger vorkommen als andere?
  • Zweitens: die realitätsnahe statistische Verteilung der relevanten Eigenschaften. Wie verteilen sich etwa die Längen von Namen oder die Häufigkeit von Anfangsbuchstaben? Hier werden oft willkürliche Annahmen getroffen, die nicht unbedingt mit der realen Situation im Feld übereinstimmen.

Ohne die genaue Kenntnis, was draußen mit den Daten geschieht, bleiben viele Probleme in tatsächlich verwendeten Kundenkonfigurationen unentdeckt.

Echtdaten

Warum also nicht gleich die echten Daten auch für Tests hernehmen? Die Daten sind schon da, oft sogar in großem Volumen auch für Lasttests, und zu einem großen Teil konsistent. Zum Beispiel ist in Installationstests von womöglich exotischen Konfigurationen die Treffsicherheit für Tests mit realen Daten ungleich höher als mit generierten Daten für angenommene Szenarien.

Ein weiteres Anwendungsgebiet ist die Konsistenz der realen Datenbestände selbst zu testen. In einem konkreten Projektumfeld waren rund 30% der im Feld verwendeten Daten inkonsistent zueinander. Bei generierten Tests wurden solche Inkonsistenzen vorher überhaupt nicht abgebildet. Erst durch die Tests mit den Realdaten wurden diese historisch bedingten Ungereimtheiten entdeckt.

In Legacy-Systemen sind die realen Datenbestände oft die einzige Dokumentation der Testdaten. Daher werden besonders bei Portierungen und Systemablösen von Altsystemen Tests mit Echtdaten aus früheren Beständen durchgeführt.

Ein nicht zu unterschätzendes Problem haben Echtdaten jedoch immer, sobald es um personenbezogene Daten geht: der Aufwand für den notwendigen Datenschutz kann sehr groß sein.

Datenschutz

Spätestens ab 2018 ist die EU-Datenschutzgrundverordnung von 2016 verpflichtend anzuwenden. Es ist für jedes Unternehmen klar, dass personenbezogene Daten nicht so einfach herumliegen dürfen. Auch nicht für Testzwecke [1]. Die Anforderungen an die Sicherheitsvorkehrungen gegen unberechtigten Zugriff und Weitergabe von personenbezogenen Daten sind im Testumfeld genauso hoch wie für die Produktion bzw. die Anwendung im Feld.

Ein gängiges Verfahren zum Datenschutz ist die vollständige Anonymisierung der Personenbezüge durch Unkenntlichmachen von Namen, Kreditkartennummern, Verpixeln von Bildern usw.

Kommt es jedoch auf die Auswertung bestimmter personenbezogener Kriterien wie z.B. der Verteilung von Kunden auf Orte an, werden Tests nicht aussagekräftig sein, wenn die Postleitzahlen und der Bezug zum Ort verfremdet wurden. Auch besteht ein Restrisiko, dass doch irgendwie ein Rückschluss auf den Personenbezug möglich ist. Dieses Risiko steigt mit eigenen Anpassungen oder einer unvollständigen Anwendung der an sich bewährten Anonymisierungsverfahren.

Daher wird auch aus Datenschutzgründen häufig vollsynthetisierten Testdaten der Vorzug gegenüber anonymisierten Echtdaten gegeben.

Platinum Copy

Eine Herangehensweise ist ein einmaliger Abzug repräsentativer Echtdaten. Dieser Abzug wird als Grundlage für die nachfolgenden Tests verwendet, oft über mehrere Releases hinweg. Diese „Gold Copy“ aus Realdaten muss ggf. noch anonymisiert werden und kann auch ausgebaut und erweitert werden.

Ein anderer Ansatz ist, diesen Abzug nur für Analysezwecke zu verwenden und nicht als Testdaten selbst. Ziel dieser Analyse ist, gute Modelle für eine realitätsnahe Testdatengenerierung zu gewinnen. Dann braucht nur dieser Abzug - in Erweiterung der „Gold Copy“ hier „Platinum Copy“ genannt - bei der Analyse entsprechend gegen unerlaubten Zugriff geschützt zu werden. Die Platinum Copy selbst wird nie in Tests verwendet, sondern verbleibt in einem datengeschützten Umfeld ohne direkte Berührung zur ausführenden Software. Damit ist auch keine Anonymisierung notwendig.

Die aus der Platinum Copy abgeleiteten Modelle werden zum Generieren von Testdatensätzen verwendet, die nun in gezielten Eigenschaften die Verteilungsfunktionen der Realität exakt wiedergeben und zu aussagekräftigen Tests führen. Aus dem Modell sind auch Extrapolationen für größere Massendaten für Last- und Stresstests möglich, die nicht nur die Menge, sondern auch eine typische Verteilung der bedeutsamen Eigenschaften aufweisen.

Klassische Testentwurfsverfahren nicht vernachlässigen

Nach wie vor werden viele Fehler in Tests gefunden, die aus der Analyse der Anforderungen und Szenarien abgeleitet werden (spezifikationsbasierte Blackboxverfahren). Wenn es um eine gute Codeüberdeckung geht, sind strukturbasierte Whitebox-Tests eine wichtige Ergänzung. Aus diesen Verfahren leiten sich Testdaten und Kombinationen von Daten ab, die eine definierte Abdeckung eines Kriteriums zu Ziel haben. Etwa, dass jede definierte Entscheidungsregel eines Geschäftsprozesses zumindest mit einem Testfall getestet wurde. Nicht zu vergessen auch erfahrungsbasierte Ansätze z.B. aus bekannten Fehlerverteilungen und explorative Tests.

So wichtig diese Testverfahren als Basis sind, bilden sie dennoch nicht automatisch die konkreten Häufungen von Datenwerten, Kombinationen und Konfigurationen aus der Realität ab. Es empfiehlt sich daher, zusätzlich auch die realen Verteilungen der Datenwerte in Betracht zu ziehen. So können häufigere Szenarien gezielt tiefer getestet werden als solche, die nur selten auftreten.

Zusammenfassung

Eine wesentliche Frage im Testdatenmanagement ist die Quelle der Daten. Echtdaten spiegeln die Realität am besten wider und sind oft vorhanden, unterliegen aber dem Datenschutz. Dieser erstreckt sich nicht nur auf die Aufbewahrung der Daten, sondern auf den gesamten Umgang mit ihnen. Anonymisierung hilft, kann aber wesentliche Merkmale der Daten verfälschen.

Generierte Daten können gezielte Testüberdeckungen herstellen, erfüllen aber oftmals nicht ausreichend die Statistiken, um realitätsnahe Aussagen zu erhalten.

Die Analyse von Echtdaten in einer datengeschützten Umgebung erlaubt es, aus dieser "Platinum Copy" der Daten, ein realitätsnahes Modell abzuleiten. Damit können die Parameter von Generierungstools so eingestellt werden, dass auch mit für den Datenschutz unbedenklichen, generierten Daten ausreichend realitätsnahe Tests gefahren werden können.

 

[1] 
https://www.wko.at/branchen/information-consulting/werbung-marktkommunikation/EU-Datenschutz-Grundverordnung-(GVO).html,
https://www.dsb.gv.at/recht-auf-datenschutz-in-der-eu,
https://www.digitales.oesterreich.gv.at/datenschutz-grundverordnung

Kontakt für Anfragen

Johannes Bergsmann Profilbild

Johannes Bergsmann

johannes.bergsmann@software-quality-lab.com

 +43 676 840072 420

Fachlicher Kontakt

Markus Unterauer Profilbild

Markus Unterauer

markus.unterauer@software-quality-lab.com

 +43 676 840072-438