Business Application Research Center

Experten für Business Intelligence, Analytics, Big Data, CRM und ECM

BARC-Newsletter

Testen von BI- und DWH-Systemen [Teil 2]: Testdaten-Management

RssRss

08.03.2019

Testen von BI- und DWH-Systemen [Teil 2]: Testdaten-Management

Ungenügende Testdaten verhindern ein effektives Testen. Daher werden Fehler zu spät erkannt, manchmal erst in den produktiven Systemen. Vielfach können Fachanwender die korrekte Arbeitsweise eines Dashboards oder die Richtigkeit der Daten in einem Data Warehouse nur beurteilen, wenn diese möglichst realitätsnah sind. Aufgrund ihrer jahrelangen Erfahrung habe sie ein implizites Wissen entwickelt, um so intuitiv beurteilen zu können, ob die ausgewiesenen Beträge, Summen oder Mengen realistisch sind. Das heißt, sie erkennen dies aufgrund der Ihnen vertrauten Größenordnungen. In letzter Konsequenz bedeutet dies, dass produktive Daten für effektives Testen verwendet werden sollten. So zumindest die Forderung der Fachbereiche.

Die Verwendung von produktiven Daten ist jedoch aufgrund rechtlicher Anforderungen nicht uneingeschränkt möglich. Insbesondere die verschiedenen Datenschutzgesetze verlangen eine Zugriffsbeschränkung. Der Gesetzgeber unterscheidet nicht zwischen Produktions- und Testsystemen oder zwischen operativen und analytischen Systemen. Somit benötigen auch Testsysteme ein Berechtigungssystem, ergänzt mit Verfahren zum Maskieren der Daten (engl. Data Masking).
 

Anforderungen an Testdaten

Testdaten müssen verschiedene Anforderungen erfüllen, um für die unterschiedlichsten Testfälle geeignet zu sein:

  • Möglichst vollständige Ausprägungen von Wertebereichen
    Das bedeutet, dass die Daten folgende Anforderungen von Tests unterstützen:
    • Normalfälle
    • Extrema (Ausreißer im gültigen Bereich wie Peaks)
    • Sonderfälle, beispielsweise Sommer- oder Winterzeitwechsel in Zeitreihen
    • Grenzwerte, um die korrekte Gruppenzuordnung testen zu können
    • Fehlerhafte Daten für Negativtest
    • Sich ändernde Daten um Mutationen (Change-Verhalten) oder das korrekte Abbilden von Historisierung (z.B. Slowly changing dimensions oder bitemporale Strukturen) zu prüfen
  • Aktualität
    Drei Jahre alte Testdaten bilden auch nur die Situation des Unternehmens vor drei Jahren ab. Aktuelle Informationen, wie organisatorische Anpassungen nach Reorganisationen oder neu eingeführte Produkte, fehlen.
  • Unterstützung aller Teststufen und -arten
    Für das Testen von funktionaler Korrektheit und Vollständigkeit genügen meistens kleinere Mengen an Testdaten. Bei einem Lasttest (Performance) ist hingegen ein Vollbestand notwendig. Weitere unterschiedliche Anforderungen lassen sich aus den geplanten Positiv- oder Negativtests ableiten. Positivtests prüfen die korrekte Arbeitsweise eines Systems, meistens im Bereich Funktionalität oder Sicherheit. Negativtests prüfen das Verhalten des Systems außerhalb der gültigen Regeln, wozu auch die Robustheit eines Systems gehört. Beispielsweise wird geprüft, ob ein Ladeprozess in der Lage ist, fehlerhafte Daten zu erkennen und zurückzuweisen, oder ob diese trotzdem geladen werden oder ein Ladeprozess abstürzt. Die unterschiedlichen Anforderungen an Testverfahren lassen sich einfach aus der Norm ISO 25010 ableiten, die bereits in Teil 1 beschrieben wurde.
  • Möglichst realitätsnahe Daten
    Die Überprüfung des Ergebnisses ist für jeden Tester bedeutend einfacher, wenn er mit vertrauten Daten arbeiten kann. Das bedeutet, dass realistische Stammdaten, wie Produktlisten, Preisstrukturen, Mengen, etc. verwendet werden sollten, was jedoch nicht gleichbedeutend mit operativen Produktionsdaten ist. Das Maskieren von Stammdaten ist somit nicht erforderlich.
  • Anonymisierung, wenn produktive, sensitive Daten eingesetzt werden (Masking)
    Operative Produktionsdaten sollten nie unverändert bereitgestellt werden. Bei der Verwendung von personenbezogenen Daten ist das Anonymisieren oder das Beschränken des Zugriffs gemäß den verschiedenen Datenschutzgesetzen eine gesetzliche Vorgabe. Auch bei nicht personenbezogenen Daten sind mögliche Anforderungen an die Maskierung zu prüfen. Beispielsweise muss verhindert werden, dass bereits aus  dem Testsystem das Unternehmensergebnis vorzeitig abgeleitet wird und eine Gewinnwarnung veröffentlicht oder Insiderhandel betrieben wird. Auf die verschiedenen Masking-Verfahren wird später in diesem Artikel noch genauer eingegangen.
  • Einfache und automatische Reproduzierbarkeit
    Dies ist notwendig, um die Testumgebung periodisch mit neuen Testdaten zu befüllen, sei es teilweise oder bei einem vollständigen Aufbau. Das Reproduzieren bedeutet nicht, dass die Testdaten zu 100 % identisch mit der letzten Generierung sind, sie müssen nur die obigen Anforderungen erfüllen.
  • Unterschiedliche Attribut- und Dataset-Formate
    So heterogen wie die System- und Datenlandschaft ist, so unterschiedlich sind auch die Testdaten. Das heißt, das Generieren von CSV-Files genügt nicht. Manchmal sind BLOB’s oder DB-spezifische Attribut-Formate oder Streaming-Daten notwendig.
  • DBMS und ETL-orientiert
    Abhängig von den Tests werden Daten als Basis in einer Datenbank oder für einen Ladeprozess bereitgestellt.
  • Systemübergreifende Vollständigkeit
    Üblicherweise bestehen Testumgebungen aus mehreren Applikationen und Datenbanken, die in den Testfällen in Kombination benötigt werden. So enthält eine Applikation die Auftragsdaten, die Produktedaten sind in einem Stammdatensystem und Kundendaten im CRM gespeichert. Tests können nur erfolgreich durchgeführt werden, wenn die zusammengehörenden Informationen in allen Systemen abgebildet sind.
     

Neben den oben beschriebenen Anforderungen gibt es noch weitere firmen- oder systemspezifische Anforderungen. Weitere Anforderungen werden aus einer erweiterten Datenbetrachtung abgeleitet, denn gerne wird vergessen, dass eine Systemumgebung nicht nur aus Daten mit Businessbezug, etwa transaktionale oder dimensionale Daten, besteht, sondern noch weitere Daten enthält, wie beispielsweise:

  • Konfigurationsdaten (plattformspezifisch und unabhängig)
  • Plattformspezifische Daten sind beispielsweise Servernamen, unabhängige sind generelle Systemeinstellungen, wie Tuning-Maßnahmen.
  • Logdaten
  • Metadaten
  • Stammdaten

Durch die oben beschriebenen Anforderungen an Daten mit Businessbezug und zusätzlich die erweiterte Datenbetrachtung wird schnell eine Komplexität erreicht, die für den Aufbau und die Bewirtschaftung ein eigenes Subprojekt oder ein eigenes Testdaten-Management mit unterschiedlichen Rollen benötigt. 
 

Synthetische oder produktive Daten?

In einem nächsten Schritt muss die Frage der Testdatenherkunft geklärt werden: Sollen produktive Daten verwendet werden? Oder müssen Testdaten erstellt werden - sogenannte synthetische Testdaten?

Das Verwenden von produktiven Daten ist tatsächlich weit verbreitet und auch zulässig, sofern gewisse Regeln berücksichtigt werden, wie das Maskieren von Daten aus bereits erwähnten Datenschutzgründen. Die Rahmenbedingungen für die Verwendung von produktiven Daten müssen vorgängig mit dem Data Owner und dem Datenschutzverantwortlichen geklärt werden.

Werden produktive Daten verwendet, hat dies den Vorteil, dass auf einfache Weise eine genügend große Anzahl von Datensätzen bereitgestellt werden kann, die außerdem noch die verschiedenen Ausprägungen abdecken, inklusive Probleme der Datenqualität. Allerdings werden nicht immer alle Datensätze benötigt. Eine Teilmenge (engl. Subset) ist häufig sinnvoller, insbesondere dann, wenn die Infrastruktur der Testumgebung kleiner dimensioniert ist als das Produktivsystem. Ansonsten sind unnötige Performance-Probleme wahrscheinlich. Auf das Thema Subsetting und mögliche Tools wird im dritten Teil dieser Artikelserie noch eingegangen.

Einfacher ist das Arbeiten mit synthetischen Daten, das heißt mit künstlich erzeugten Testdaten. Synthetische Daten eignen sich hervorragend für Negativtests, um die Robustheit und Fehlertoleranz eines Systems zu prüfen. Da synthetische Daten keinen Bezug zu realen Daten haben, sind auch keine rechtlichen Rahmenbedingungen einzuhalten. Jedoch ist die Erstellung einiges komplizierter, sollen doch sämtliche Wertebereiche und Kombinationen abgebildet werden. Zudem wird eine größere Anzahl von Datensätzen benötigt. Beide Anforderungen, Varianz und Volumen, werden nur mit einem Testdatengenerator erreicht. Das Generieren erfolgt üblicherweise aufgrund von Metadaten oder festen Wertelisten für Attributinhalte. Auf Grundlage der maximalen Anzahl an Ausprägungen je Attribut werden kartesische Produkte gebildet, die anschliessend auf die Anzahl gewünschter Records reduziert werden. Die Toolgruppe der Testdatengeneratoren wird im dritten Teil dieser Artikelserie erklärt.

In der Praxis wird häufig ein hybrider Ansatz für die Erstellung von Testdaten gewählt. Für Normalfälle werden  produktive, maskierte Daten verwendet und durch synthetische Testdaten für Negativtests ergänzt. Somit können sowohl Normalfälle als auch das Verhalten im Fehlerfall getestet werden.
 

Data Masking

Data Masking ist ein Oberbegriff für verschiedene Verfahren des Pseudoanonymisierens oder Anonymisierens, um Echtdaten so zu verändern, dass keine Rückschlüsse mehr auf die Originalwerte möglich sind. Die maskierten Daten sind jedoch trotzdem für die Durchführung von Tests geeignet. Data Masking ist nicht gleichbedeutend mit einem Berechtigungssystem, bei dem der der Zugriff bewusst eingeschränkt oder gar verhindert wird.

Bei den Verfahren des Pseudonymisierens werden Daten über eine Hilfstabelle oder einen speziellen Key oder Algorithmus umgeschlüsselt. Wer Zugriff auf diese Hilfstabelle oder den Key hat, oder den angewandten Algorithmus kennt, ist also in der Lage das Maskieren rückgängig zu machen.

Bei den Verfahren des Anonymisierens werden sensitive Daten mit verschiedenen technischen Verfahren dagegen so verschlüsselt, dass dies nicht mehr rückgängig gemacht werden kann, beispielsweise durch Hash-Algorithmen.

Data Masking muss verschiedene Prinzipien erfüllen:

  1. Masking darf nicht durch unbefugte Personen rückgängig gemacht werden können
  2. Gewährleisten der referentiellen Integrität
  3. Masking nur auf sensitiven Daten
  4. Repräsentatives Resultat nach Masking
  5. Wiederholbarkeit
  6. Einhaltung der Compliance-Vorgaben und der Datenschutzrichtlinien

Maskierungsverfahren werden nur auf einzelne Attribute, auf Attributgruppen oder auf Wertebereiche angewandt. Das Attributpaar Postleitzahlen und Ort ist ein Beispiel für Attributgruppen. Bei Wertebereichen sollten beispielsweise die Anzahl an Kunden oder das Umsatzvolumen in einem Marktgebiet weiterhin der Realität entsprechen.

Am Markt gibt es unterschiedliche Tools für Data Masking, die manchmal dreißig oder mehr Verfahren unterstützen. Je nach Hersteller werden diese Verfahren leider unterschiedlich benannt. Ein paar der üblichen Verfahren sind nachfolgend kurz erklärt:

  • Scrumble
    Scrumble schreddert Werte, indem zufällig neue Zeichen generiert werden. Bei der Anwendung von Scrumble sollte zumindest der Wertebereich definiert werden, beispielsweise ob und welche Sonderzeichen zulässig sind. Scrumble wird üblicherweise nur auf einzelne Attribute angewandt. Trotzdem führt Scrumble immer wieder zu Irritationen, beispielsweise wenn Namen nicht mehr aussprechbar sind, da nur noch eine zufällige Ansammlung von Konsonanten vorhanden ist. Daher ist Scrumble nur in Ausnahmefällen einzusetzen.
    Abbildung 1. Scrumble über Vor- und Nachname
     
  • Shuffle / Shuffling
    Shuffle bedeutet mischen. Hier werden bestehende Werte durch einen Zufallsgenerator, meistens Hash, neu verteilt. Somit entstehen aus den bestehenden Werten, neue zufällige Kombination. Shuffle ist beim Maskieren von Personendaten ein beliebtes Verfahren für Name, Vorname und Adressattribute, wobei die Gruppe Postleitzahl und Ort unbedingt zusammengehalten werden muss.
    Abbildung 2. Shuffle über Adressen, wobei die Gruppe PLZ, Ort und Land zusammengehalten wird
     
  • Substitution
    Bei Substitution werden Werte innerhalb desselben Gültigkeitsbereich ersetzt. Das Verfahren wird beispielsweise auf Kreditkarten- oder Telefonnummern angewandt.
  • Reduction/Nulling
    Nulling löscht den Inhalt eines Attributes ganz, Reduction nur einen Teil davon. bei Reduction wird in einer Telefonnummer noch die Länder- oder Regionen-Vorwahl stehen gelassen und nur der hintere Teil gelöscht. Ergebnis: +49-176-  
  • Masking out Data/Replace Data
    Bei diesem Verfahren wird ein Teil eines Wertes ersetzt. Dieses Verfahren ist bei Onlinestores zum teilweisen Anzeigen der in den Kunden- und Zahlungsdaten hinterlegten Kreditkartennummer beliebt. Beispiel: 5500 XXXX XXXX 5703
    Abbildung 3. Masking out von Telefonnummern
     
  • Averaging
    Averaging wird auf numerische Werte innerhalb einer Wertegruppe angewandt, wie Anzahl, Beträge oder Summen. Die Anzahl der bestellten Produkte oder Umsätze werden durch Zufallswerte ersetzt. Das Total einer Gruppe, beispielsweise eines Marktgebietes, soll dabei gleich groß bleiben. Beim Averaging sind zusätzliche Regeln sinnvoll, sodass es nicht zu seltsamen Größenverteilungen kommt, wie etwa dass ein Kunde 1 Mio. Umsatz gemacht hat und alle anderen nur noch Kleinstbeträge. Die Werte sollten außerdem in einer sinnvollen Relation stehen. Das bedeutet beispielsweise, dass die Bestellsumme realistisch in Bezug zur Anzahl bestellter Artikel und Listenpreise ist. Auch sollten Rabatte in einem realistischen Rahmen stehen. Averaging zeigt, dass das Maskieren von numerischen Werten deutlich komplexer ist.
    Abbildung 4. Averaging von Bestellungen. Produkte je Kunde, Produktpreise und das Gesamttotal bleiben gleich.

     

Neben den oben beschriebenen Verfahren, gibt es noch verschiedene weitere Möglichkeiten des Data Masking. Einige davon sind nur Abwandlungen der oben beschriebenen Verfahren. Gerade zu Averaging gibt es eine Vielzahl an Subvarianten mit den unterschiedlichsten Bezeichnungen.
 

Summary

Das Bereitstellen und Aktualisieren der Testdaten in einer Testumgebung ist eine zeitintensive Aufgabe, verbunden mit einem hohen Abstimmungsaufwand. Einerseits gibt es die Erwartung, dass laufende Tests zu Ende geführt und Fehler analysiert werden können. Auf der anderen Seite steht die Erwartung, dass die Testdaten eine genügende Qualität haben und nicht zu unerwünschten Störungen des Testbetriebs führen. Diese beiden Erwartungen stehen häufig in Widerspruch. Eine klare Kommunikation über den Betrieb der Testumgebungen und die Aktualisierung der Testdaten ist somit notwendig.

Nach Abschluss eines Testbetriebs muss entschieden werden, was mit den Testdaten geschieht. Können diese einfach gelöscht werden? Oder gibt es eine Nachweispflicht zu den Testergebnissen aus regulatorischen Gründen? Möglicherweise müssen Testfälle und die dazugehörenden Testdaten archiviert werden.

Ein effektives Testdaten-Management ist eine komplexe Aufgabe, die nur mittels Automatisierung effizient gelöst werden kann. Die Möglichkeiten der Automatisierung und der dazu geeigneten Tools wird im dritten Teil dieser Artikelserie beschrieben.

 

BARC bietet zur Unterstützung verschiedene Angebote an:

  • Zweitägige Classroom-Seminare an verschiedenen Standorten
  • Individuelle Inhouse-Seminare nach Ihren inhaltlichen und terminlichen Vorstellungen
  • Individuelle Workshops 
  • Generelle Unterstützung als abgestimmtes Beratungsangebot, wie Assessments oder spezifische Vertiefung ausgewählter Themen (zum Beispiel agiles Testen, Aufbau von Regressionstests, Bestimmen der notwendigen Testabdeckung, Automatisierung mittels geeigneter Tools, etc.)