Testdaten bzw. Systemzustände bilden die Basis aller dynamischen Tests. Ziel von dynamischen Tests ist es schliesslich, zu prüfen, ob Aktionen einen Ausgangszustand in einen Zielzustand versetzen. In der Praxis kämpfen Tester jedoch häufig damit, sich die notwendigen Testdaten bzw. Systemzustände zu erzeugen. Grosse, versteckte, Kosten lauern hier. Dies gilt für manuelle wie automatische Tests gleichermassen. Der Artikel zeigt Beispiele für den kreativen Einsatz der Erzeugung von Systemzuständen mittels einfacher Programme.
In zwei weiteren Artikeln zeigen wir weitere Beispiele auf und gehen auf die Theorie der Testdaten ein.
Projekthintergrund
In dem Projekt wurde das Wagenmanagement eines Logistikunternehmens komplett neu entwickelt. Wagen haben, vereinfacht gesagt, einen Status (sauber, verschmutzt, defekt, etc), einen Standort, sowie eine Buchungsbelegung die zeitabhängig ist. Diese Eigenschaften der Wagen konnten sowohl manuell über eine Web-GUI, wie auch elektronisch über XML-Messages gesetzt werden. In der Praxis prüfen Mitarbeiter des Unternehmens die Wagen und geben auf einem Handgerät Informationen ein („in Bern angekommen“ oder „linke Achse, hinten defekt“), welche per XML-Message an das System übermittelt werden.
Testdurchführung
Ein mögliches Testszenario konnte so aussehen, dass für die Schweizer Rübenkampagne drei frisch gereinigte Wagen nach Langnau geordert wurden. Mögliche Rückmeldungen vom System sind entweder OK (Wagen gebucht) oder NOK (keine sauberen Wagen verfügbar).
Um das zu testen (egal ob manuell oder automatisch) muss man also die Testdatenbasis so präparieren, dass entsprechende Ausgangslagen geschaffen werden. Ausserdem kann man den Test nicht beliebig wiederholen, ohne die erfolgten Buchungen zu löschen. Ein typisches Problem in der Testautomatisierung also: Die Tests selbst zerstören sich die Testdaten.
Umgesetzt haben wir dieses Szenario mittels der XML-Messages, welche normalerweise von den Handgeräten gesendet werden. Für diesen Beispiel-Testfall konnte der Test mittels eines Generators eine XML-Message pro Wagen erzeugen und an das System senden. Danach waren z.B. alle Wagen bis auf drei verschmutzt und alle bis auf drei andere Wagen gebucht für den Juni. Die Testdurchführung konnte dann sein
- Testdaten initalisieren
- 3 Wagen buchen: OK
- 3 Wagen buchen: NOK (alle gebucht oder verschmutzt)
- 3 Wagen säubern: OK
- 3 Wagen buchen: OK (jetzt waren ja wieder drei verfügbar)
- 3 Wagen buchen: NOK (alle gebucht)
Entscheidend für solche Ansätze ist es, dass die Bereitstellung der Testdaten unmittelbar erfolgt. In unserem Fall haben wir eine Zeitdauer im Bereich um 1 Sekunde gehabt, so dass dies (fast) beliebig oft erfolgen konnte.
Stammdaten vs. Bewegungsdaten
Ein weiteres Beispiel aus diesem Projekt zeigt anschaulich auf, wie sich Stammdaten und Bewegungsdaten unterscheiden. Stammdaten in dem Projekt waren z.B. die Wagen selbst, Lagerhallen, Städte, Werkstätte, etc. Diese haben sich nicht durch das System verändern lassen und konnten als gegeben angenommen werden. Gleichzeitig gab es Bewegungsdaten, wie z.B. den Standort der Wagen („in Bern“, „in Transit“, „in Werkstatt Basel“, etc.). Da viele Tests einen bestimmten Standort vorausgesetzt haben, gab es ein DB-Skript, welches diese Bewegungsdaten komplett löschen konnte. Damit waren alle Wagen heil und sauber in Basel und die Tests konnten mit bekannter Ausgangslage durchgeführt werden. Das DB Skript lief im Millisekunden Bereich durch und konnte beliebig oft wiederholt werden.
Fazit
Da Testautomation abhängig vom Zustand des zu testenden Systems ist (also normalerweise dessen Daten) ist die Beherrschung der Testdaten essentiell für den Aufbau einer erfolgreichen Testautomation. Der Artikel hat anhand von zwei Praxisbeispielen aufgezeigt, wie Testdaten erfolgreich erzeugt und eingesetzt werden können. Dazu wurde auch aufgezeigt, wie Testdaten mittels einfacher Skripte für den automatischen oder manuellen Test aufbereitet werden können.