Databases Reference
In-Depth Information
14.3
Grundregeln beim Testen mit Datenbanken
Oftmals sind Datenbanken zentrale Grundlage von komplexer
Software, sodass eine Fehlfunktion der Datenbank immensen
geschäftlichen Schaden anrichten kann. Ein Beispiel sind Ver-
sandhäuser, die ihre Kataloge und alle Geschäftsbeziehungen in
ihren Datenbanken pflegen. Damit ist jede Änderung an dieser
möglichst ausfallsicher, redundant auf mindestens zwei Ser-
vern laufenden Datenbank, als extrem kritisch einzuordnen.
Daraus folgt die erste zentrale Regel, dass Tests niemals am lau-
fenden System, also dem Produktivsystem, ausgeführt werden
dürfen. Selbst das Einspielen von Testdaten für Dummy-Nutzer
oder Kunden kann zu teilweise gravierenden Problemen füh-
ren, wenn die zugehörigen Zugangsdaten in falsche Hände fal-
len. Weiterhin könnten Testdaten reale Auswertungen verfäl-
schen.
Für Entwickler folgt unmittelbar, dass es für die Entwicklungs-
umgebung eine eigene Datenbank geben sollte, wobei bei sehr
großen Systemen oftmals nicht alle Tabellen benötigt werden.
In diesem Fall ist die Äquivalenzklassenmethode oftmals ein
guter Ansatz, um zusammen mit der Grenzwertanalyse sinn-
volle Testdaten zu erhalten. Man versucht dabei für jeden typi-
schen Fall nur einen Datensatz in der Datenbank zu haben, um
den Testaufwand zu reduzieren.
Im nächsten Schritt ist bei der Integration mehrerer Software-
Komponenten eine Testdatenbank sinnvoll, auf die bereits das
integrierte System zugreifen kann. Dabei stellt sich die zentrale
Frage, wie man immer eine eindeutige Ausgangslage für die
Tests herstellt. Hier ist es oftmals der Fall, dass nicht die gesam-
te Datenbank immer wieder neu aufgesetzt werden muss, da
durch gewisse Konventionen die Reproduzierbarkeit einer
Ausgangssituation garantiert werden kann. Dies ist z.B. da-
durch erreichbar, dass vereinbart wird, dass gewisse Daten
nicht verändert werden dürfen und so zum gemeinsamen Tes-
ten zur Verfügung stehen. Weiterhin kann vereinbart werden,
dass jeder Tester nur Daten mit bestimmten Eigenschaften, z.B.
mit einer Mitarbeiternummer zwischen 3000 und 4000 beliebig
bearbeiten darf. Generell ist es beim Testen, wie generell bei der
Nutzung von Datenbanken immer sinnvoll, zwischenzeitlich
Backups zu erzeugen, die dann als „Reset-Möglichkeit“ wieder
neu eingespielt werden können.
Testsystem muss
existieren
Unabhängigkeit
von Tests garan-
tieren
322
