Nachdem im ersten Teil die Vor- und Nachteile, Risiken, Voraussetzungen und Testautomation mit künstlichen Testdaten, Echtheit und Diversifikation beschrieben wurden (Teil 1 von 3), zeigt der zweite Teil praktische Beispiele und wie man wo künstliche Testdaten ideal einsetzen kann. Dieser Teil soll ein Gefühl dafür entwickeln, wie sich künstliche Testdaten auf die Tests auswirken.
Künstliche Testdaten sind ideal für...
Dank der vordefinierten Anzahl Parameter, deren Inhalte bekannt sind, eignen sich künstliche Testdaten ideal für…
…das Anlegen von verschiedenen Datentypen
Ich nehme als Beispiel eine Software für Banken, weil deren Datenmenge gross, die Daten von Tag zu Tag stark variieren und sie komplex verknüpft sind. Das künstliche Laden ermöglicht es beispielsweise nicht nur Kontobewegungen mit verschiedenen Status eines E-Banking-Nutzers (User Accounts) zu laden, und sorgt damit für zuverlässige Resultate, sondern man kann auch die eigentlichen Nutzer mit verschiedenen Ausprägungen anlegen. Mit denen werden die Tests dann ausgeführt. Weiterhin kann ein komplettes Wertschriftenverzeichnis, mit denen das Trading getestet wird, erstellt werden. So auch eine Postkontonummern-Datenbank, eine Blacklist von IBAN-Nummer an die keine Zahlungen erlaubt sind, und zum Beispiel auch weitergehende Währungsinformationen. Die Liste ist lang.
Auch «banale» Daten gehören zu den Testdaten. Wie Nachrichten vom Kunden an die Bank, oder Nachrichten von der Bank an alle oder einzelne Nutzer im Online-Banking-eigenen Messaging-Modul. Dazugehörige verschiedene Status oder Lese-Berechtigungen erweitern die Palette.
Mögliche Ausprägungen der E-Banking-Nutzer: Mit einem Lade-Durchgang werden mehrere E-Banking-Nutzer generiert. Diese haben Zugriff jeweils auf unterschiedliche Konten mit verschiedenen Berechtigungsstufen. So kann Nutzer 1 die Bewegungen des Konto 3 nur lesen, aber keine Zahlungen erfassen, während der Nutzer 2 Zahlungen erfassen und signieren darf. Ähnlich verhält es sich mit den Portfolios. Nutzer 3 darf für den Wertschriftenhandel für Portfolio 1 das Konto 3 als Zahlungskonto benutzen, obwohl er Zahlungen und Bewegungen des Konto 3 nur lesen darf. Während Nutzer 1 für den Wertschriftenhandel für Portfolio 1 das Konto 1, 2 oder 3 benutzen darf. Die folgende Grafik veranschaulicht die komplexen Verhältnisse.
Wenn wir dieses Exempel weiterspinnen, haben die geladenen Konten und Portfolios auch unterschiedliche Bewegungen, die sich beispielsweise in Betrag, Menge, Empfängerkonto, Referenznummer und Mitteilung differenzieren. Dazu kann man noch den Status künstlich setzen. Die Rechnungen sind unter anderem ‘Offen’, ‘Zu Signieren’ oder ‘Geschlossen’. Wertschriftenbuchungen sind zum Beispiel ‘Übermittelt’, ‘Abgebucht’, ‘Storniert’ und so weiter.
Man legt mit künstlichen Testdaten ein komplexes vordefiniertes Datengerüst fest, wo umfassende Zusammenhänge geladen werden (siehe Grafik oben). Wohlgemerkt, die oben genannten Beispiele kratzen da nur an der Oberfläche.
...Grenzwertanalyse
Die Startseite muss je nach Einstellung bis zu 50, 100 oder 1'000 Emails anzeigen. Dies soll getestet werden. Das Laden von künstlichen Testdaten geht ungleich viel schneller von statten, als 1'001 (1 grösser als Beispielgrenzwert) Emails manuell zu senden. Sogar deutlich schneller als ein Testautomat wie Selenium, der die Emails am Frontend selbständig erzeugt, schreibt und versendet.
Oder die Spezifikation verlangt, dass pro Email maximal 100 Emailempfänger aus dem Adressbuch als Empfänger eingesetzt werden können. Auch dafür kann über das Testdatenladeprogramm (Tools werden im dritten Teil besprochen) ein entsprechend grosses Adressbuch hochgeladen werden. Auf diese Weise wird vor jeder Testausführung das Adressbuch aufgefrischt, und damit sichergestellt, dass die Ausgangssituation und die erwarteten Resultate immer die gleichen sind.
...Performancetests
Performancetest durch Masse: Ein durchschnittliches Emailkonto mit 5'000 gesendeten Emails, weitere 1'000 in der Inbox, und weitere 3'000 Emails verteilt über 100 Ordner und Unterordner. Diese Menge an künstlichen Testdaten reichen für die täglichen und üblichen Tests.
Lasst uns hier die Performance testen. Wer meldet sich freiwillig die Testdaten manuell aufzubereiten? Wusste ich es doch!
Sind die oben genannten Testdaten beispielsweise in einem Excel (visuell) aufbereitet, braucht es nur ein paar Klicks für eine Steigerung der Datenmenge auf 5’000‘000 Gesendete und Empfangene, plus weitere 3‘000‘000 Emails verteilt über 1000 Ordner und Unterordner. In der Summe also 8'000'000 Emails. Markiere die entsprechenden Zeilen und Reihen im Excel, einmal «runterziehen» mit der Maus, et voilà. Nicht einmal ein Testautomat vermag dies in vernünftiger Zeit zu bewerkstelligen. Nehmen wir an Selenium benötigt am Frontend, im besten Fall pro Email nur 0.1 Sekunden (!!). Dann würde der Automat für diese Aufgabe immer noch geschlagene 9 Tage benötigen. Während ein Testdatenladeprogramm, das «direkt» in die Datenbank schreibt, dafür wohl nur einige Minuten «verschwenden» wird. Im schlechtesten Fall ein paar wenige Stunden.
…Suche & Suchresultate
Eine Suche nach Kriterium X und Y wird mit künstlichen Testdaten immer die gleichen Resultate liefern, nicht mehr, nicht weniger und auch nicht irgendein anderes Ergebnis. Es sei denn ein Bug ist vorhanden. Der Nutzer hat 100 Emails in seiner Inbox, davon sind 17 von Absender X, davon 5 im Zeitbereich Y. Das Resultat aus Suchkombination X und Y muss also immer genau diese 5 Emails anzeigen. Nicht mehr, nicht weniger, keine anderen Emails.
Je mehr Suchkriterien kombinatorisch überprüft werden müssen, desto aufwendiger wird dies ohne fixierte künstliche Testdaten. Zum einen sinkt (gefühlt exponentiell) die Wahrscheinlichkeit, dass echte Testdaten die Kombinationsmöglichkeiten nicht erfüllen. Zum anderen ist die Suche in der Datenbank, um einen Nutzer/Datensatz zu finden auf den die Kriterien passen, zeitintensiv und garantiert bei kopierten Daten aus der Produktion keinen Erfolg.
Dann lieber mit kleinem Aufwand einen weiteren künstlichen Datensatz anlegen, hochladen und sofort testen. Gehen wir wieder davon aus, dass die künstlichen Testdaten im Excel aufbereitet sind. Für einen Test, der eine spezifische Suche nach speziellen (neuen) Werten überprüft, fehlt das entsprechende Email im Excel. Also kopiere ich eine Reihe, schreibe die benötigten Werte in die entsprechenden Zellen und starte das Testdatenladeprogramm. Ich schätze mal, dass der Aufwand für dieses «einfache» Beispiel im Idealfall 5-10 Minuten dauert. Danach stehen für diesen Test die fixierten Daten bereit und Regressionen werden aufgedeckt.
…verschiedene Zugriffsrechte
Die Nutzer der Software können verschiedene Zugriffsrechte haben (siehe auch Grafik weiter oben). Künstlich geladene Testdaten, ermöglichen das schnelle Testen dieser Zugriffsrechte, ohne dass vorher die Nutzer und ihre Rechte zusätzlich angelegt oder modifiziert werden müssen (manuell oder automatisiert). Sie sind nach jedem Testdatenladezyklus automatisch vorhanden und fix vorgegeben. Der Tester weiss, Nutzer A hat Rechte A, Nutzer B hat Rechte B, und so weiter.
Die Risiken eines Testfehlers werden minimiert, weil weniger Testschritte in einem einzelnen Test ausgeführt werden müssen. Ausserdem wird das Risiko der Alterung von Daten, die schon vor längerer Zeit aus der Produktionsumgebung kopiert wurden, nicht mehr eintreten. Wie oft stand ich vor dem Problem, dass meine Test-User-Accounts am nächsten Tag plötzlich gelöscht waren, oder so stark verändert, dass sie für viele Standardtests nicht mehr nutzbar waren.
Tests für das Erstellen, Modifizieren oder Löschen von Nutzerrechten werden dadurch natürlich nicht ersetzt. Diese müssen zusätzlich in separaten Tests ausgeführt werden.
…Standard User & Accounts
Vorabgefüllte Standardnutzerkontos, bestückt mit realitätsnahen diversifizierten Daten für die wichtigsten Tests, können Bugs durch Regressionen in den wichtigsten Bereichen und Funktionen schnell aufdecken. Geht man von einer Continuous Integration in einem agilen Umfeld aus, sollte täglich in einem grossen Umfang automatisiert getestet werden. Wenn jetzt mit sehr viele Testnutzer mit verschiedenen Zugriffsarten und -kombinationen getestet werden muss, ist das Testing bedeutend effizienter zu bewältigen durch das Laden von künstlichen Testdaten als durch das manuelle erzeugen dieser Konstellationen.
Auch hier werden die Tests rund um die Nutzererstellung selber nicht ersetzt. Diese müssen getrennt überprüft werden. Das Gute an den künstlichen Testdaten ist, man kann viele Testschritte sparen und nur die eigentliche Funktion testen. Denn die benötigten Eingangskriterien sind vorhanden.
Zusätzlich bringen solche Standardkonten und -daten auch für Demos und Sales-Präsentationen einen grossen Nutzen.
…automatisierte Service Layer Tests
Um Formulare mit multiplen Eingabefeldern abdeckend (positive und negative Werte, Grenzwerte, Kombinationen mit 2 - n Werten, invalide Kombinationen) zu testen, bedarf es einer Unmenge an Tests. Das kann bei komplexen Such-Formularen schnell in die Millionen gehen.
Nehmen wir mal an, dass mit der Pairwise-Technik die Anzahl Tests für eine Such-Funktionalität auf insgesamt 300 reduziert werden kann. Hier ist es empfehlenswert nur eine kleine Anzahl der wichtigsten Tests auf dem User Interface auszuführen und den grossen Rest über äusserst schnelle Tests auf dem Service Layer. Hier kommt der Einsatz künstlicher Testdaten positiv zum Tragen. Man kann, dank den fixierten und bekannten künstlichen Daten, den Inhalt der Antwort überprüfen. Ich hatte 10 Selenium-Tests am Frontend, die 3 Minuten benötigten. Die restlichen 290 Tests über die Services benötigten nur 30 Sekunden. In der Summe 3:30 Minuten für eine ausreichende Testabdeckung einer komplexen Such-Funktion.
Fazit
Ich hoffe ich konnte mit den wenigen Beispielen Ihre Lust auf künstliche Testdaten anregen und Sie haben schon angefangen darüber nachzudenken, wie und wo sie solche einsetzen werden. Die Anwendungsgebiete sind extrem weitläufig.
Im nächsten und letzten Teil werde ich die weitergehenden ebenso wichtigen Themen rund um künstliche Testdaten erläutern: Tools, Reverse Engineering, Aufwand und Ertrag, Risiken, Unterhalt und Workflow.
