Eine vollständige Antwort auf diese Frage wäre sehr lang. Ich werde versuchen, die wichtigsten Punkte zu erwähnen.
Um Bedenken zu trennen, sehen Sie sich möglicherweise Tests an, um:
A - Überprüfen Sie das Datenbankdesign.
B - Überprüfen Sie, ob die Programme ordnungsgemäß mit der Datenbank interagieren.
Die Validierung des Datenbankdesigns sollte von den Personen durchgeführt werden, die die Datenbank entworfen haben. Die Entwickler (während des Unit-Tests) sollten sich mehr mit Teil (B) befassen. Der Hauptunterschied, den ich zwischen den beiden Arten von Tests sehe, sind die verwendeten Werkzeuge. Für (A) würden Sie eine vom Projektcode unabhängige Umgebung verwenden, während Sie für (B) natürlich den Projektcode verwenden würden. Im folgenden Text werde ich beide mischen.
So beantworten Sie Ihre speziellen Fragen:
Wertregeln für Spaltendomänen
Jeder Spalte ist ein Datentyp zugeordnet. Jede Spalte muss anhand von Geschäftsregeln validiert werden, um zu beweisen, dass sie den richtigen Datentyp darstellt. Probleme können auftreten, wenn der Spaltendatentyp nicht mit den Geschäftsanforderungen kompatibel ist oder wenn der Code einen anderen Datentyp verwendet als in der Datenbank definiert.
Beispielsweise:
Wenn die Spalte als kleines int definiert ist, sollten Sie keinen Text darin speichern können. Dies ist ein wichtiger Test, insbesondere wenn die Spalten optional sind, da er unbemerkt bleiben kann, bis tatsächlich jemand Daten eingibt.
Könnten Sie einen negativen Wert in einer Spalte speichern, in der das Unternehmen dies erfordert?
Standardwerte für Spalten
Einige Spalten sind mit einer Standardwertspezifikation in der DDL (Data Def. Language) verknüpft. Wenn die Einfügung beim Einfügen keinen Wert liefert, nimmt die Datenbank den Standardwert an. Dies kann getestet werden, indem der Wert nicht übergeben und der in der Datenbank gespeicherte Ergebniswert beobachtet wird. Dieser Test kann auch die Überprüfung auf nullfähige Spalten umfassen. Dies erfordert selten einen Test, da er über DDL überprüft werden kann, es sei denn, für die Spalte wird ein eindeutiger Index erstellt.
Wertexistenzregeln
Soweit ich weiß, überprüfen Sie, ob die eingefügten oder aktualisierten Daten wie erwartet in der Datenbank angezeigt werden.
Zeilenwertregeln
Mir ist nicht klar, was dieser genau bedeutet.
Größenregeln
Jede Spalte hat eine Größe in der Datenbank, die davon abhängt, wie sie in DDL definiert ist. Sie möchten sicherstellen, dass alle Werte, die den Anforderungen entsprechen (entweder in der GUI eingegeben oder als Ausgabe einer Berechnung resultiert), korrekt in der Spalte gespeichert werden. Bei einem Datentyp "Small Integer" können Sie beispielsweise keinen Wert von 5 Milliarden speichern. Außerdem kann ein als VARCHAR2 (30) definierter Name nicht 40 Zeichen enthalten. Daher müssen die Geschäftsregeln hier sehr klar sein, insbesondere wenn die Spalte zum Aggregieren von Daten verwendet wird. Sie möchten testen, was in solchen Situationen passiert.
Richtlinien, wie / wo ich anfangen soll
Eine Möglichkeit, dies zu tun, besteht darin, einen Testplan zu erstellen. Sie möchten sicherstellen, dass Sie die richtige Version der Spezifikationen (z. B. Anforderungsdokumente und Anwendungsfälle) und der Software verwenden. Sie müssen diese Tests auch mit Tests koordinieren, die von Unit Testing (falls vorhanden) durchgeführt wurden. Möglicherweise finden Sie doppelte Tests, die Sie nicht erneut durchführen müssen. Sie möchten vor dem Testen eine Kopie der Datenbank erstellen, damit Sie einen bestimmten Test wiederholen können, falls dies jemals erforderlich sein sollte. Der DBA kann Ihnen dabei helfen. Sie müssen sich auch bei Ihrem Team erkundigen, wie diese Tests dokumentiert werden, und den Testumfang mit ihnen überprüfen. Sie können Ihre Datenbank in logische Teile aufteilen und mit dem Testen jedes logischen Teils separat beginnen. Der Testprozess kann beginnen, indem die DDL der Datenbank untersucht und überprüft wird, ob die Spalten gemäß den Anforderungen des Unternehmens korrekt definiert sind. Sie sollten die Software der Anwendung und kein anderes Tool verwenden, um die meisten Tests durchzuführen. Stellen Sie zum Beispiel Folgendes in Frage:
Soll die Spalte vom definierten Typ sein (es macht keinen Sinn, einen Namen als Int zu erstellen).
Ist die Größe mit den Geschäftsanforderungen kompatibel?
Befinden sich alle Spalten in den Geschäftsanforderungen in der Datenbank?
Sind Nullspalten wirklich optional?
etc.
Als nächstes können Sie Testfälle entwerfen, um die oben genannten zu testen. Sie können die GUI verwenden, um die meisten Tests durchzuführen.
Es gibt andere wichtige Datenbanktests, die Sie nicht erwähnt haben. Diese befassen sich mit:
1 - Testen, ob die Primärschlüssel aus geschäftlicher Sicht wirklich einzigartig sind.
2 - Testen, ob eindeutige Indizes (außer der PK) aus geschäftlicher Sicht wirklich einzigartig sind.
3 - Das Testen von Fremdschlüsseleinschränkungen funktioniert.
4 - Testen, was passiert, wenn eine Zeile gelöscht wird, und welche Auswirkungen dies auf verwandte Zeilen hat.
5 - Andere Tests bezüglich spezieller Datenbankkonstrukte wie CHEKC, Trigger, falls vorhanden.
6 - Richtige Tabellennormalisierung und normalisierte Spalten enthalten korrekte Werte.
Das Obige ist keine vollständige Liste, aber es sollte Ihnen den Einstieg erleichtern.