Datenqualität in relationalen Datenbank-Regressionstests

Ich habe an einer Open-Source-Webanwendung für das Museumssammlungsmanagement gearbeitet, mit der die erworbenen, gespendeten, geliehenen oder anderweitig erworbenen Artefakte eines Museums nachverfolgt werden sollen.

Dies beinhaltete das Entwerfen und Erstellen einer ziemlich großen Datenbank (im Verhältnis zu meinen früheren Erfahrungen), in der alle Arten von unterschiedlichen Informationen (Artefaktinformationen, sich ändernde Standortinformationen, persönliche Kontaktinformationen, Bilder usw.) gespeichert sind, die flexibel und leicht erweiterbar sein müssen .

Ich beende gerade meinen Universitätsabschluss und bin kein Profi, wenn es um Datenbankdesign geht. Daher möchte ich wirklich eine gründliche Testsuite erstellen, um sicherzustellen, dass das, was ich vor Ort habe, "funktioniert".

Ich habe mich über Datenbanktests informiert und bin auf einige Artikel gestoßen, in denen Regressionstests in Bezug auf Datenbanken erwähnt werden, aber ich verstehe nicht vollständig, was dies alles beinhaltet. Durch das Lesen dieses Artikels bei Dr.Dobbs verstehe ich, dass eine Art von Test, die ich durchführen muss, darin besteht, zu überprüfen, ob die Logik in der Datenbank korrekt ist. Daher würde ich Tests erstellen, die bestimmte Daten in die Datenbank einfügen, und anschließend eine Abfrage durchführen, um sicherzustellen, dass ich die richtigen Daten aus der Datenbank zurückerhalte (um sicherzustellen, dass alle geeigneten Trigger oder Ansichten funktionieren).

Die Verwirrung kommt mit der Erwähnung des Testens auf "Datenqualität". Im obigen Artikel erwähnt der Autor, dass Sie Folgendes mit Tests validieren möchten:

• Wertregeln für Spaltendomänen
• Standardwerte für Spalten
• Wertexistenzregeln
• Zeilenwertregeln
• Größenregeln

Welche Arten von Tests würde dies beinhalten und wie würden sie implementiert? Außerdem schreibe ich zum ersten Mal eine Testsuite für eine Datenbank. Gibt es gute Richtlinien, wie / wo ich anfangen soll, oder Prozesse, die ich befolgen kann, um meine Testentwicklung zu steuern?

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.

Ich denke, Sie nähern sich dem falsch.

Jede mir bekannte Datenbank überprüft Daten, bevor sie in Tabellen eingefügt werden. Sie überprüft sie anhand der Definition jeder Spalte. Sie können keine 80-Zeichen-Zeichenfolge in eine SMALLINT (3) -Spalte eingeben. Die Datenbank schlägt bei diesem Versuch fehl und teilt Ihnen mit, dass Sie einen Fehler gemacht haben. Sie müssen dies nicht selbst testen, indem Sie die Daten einfügen und dann abrufen.

Was Sie haben möchten, sind Validierungs- / Filterregeln für Daten, bevor diese an die Datenbank gesendet werden.

• Stellen Sie sicher, dass die Daten den akzeptierten Typen und Bereichen für jede Spalte entsprechen, und filtern Sie unerwünschte Inhalte
• Stellen Sie sicher, dass Sie es ordnungsgemäß umgehen, um Fehler zu vermeiden (und mögliche SQL-Injektionen, wenn Sie eine öffentliche Schnittstelle haben).

Diese Validierungs- / Filterregeln sollten für die Daten in Ihrer tatsächlichen Anwendung ausgeführt werden. Sie können dann Tests einrichten, um sicherzustellen, dass sie korrekt sind, indem Sie sie mit korrekten und falschen Daten versorgen, um sicherzustellen, dass sie die Validierung entsprechend bestehen oder nicht bestehen.

Was das Datenbankdesign angeht, kann man es nicht wirklich mit Tests überprüfen - da viele Designs auch dann funktionieren, wenn sie nicht ideal sind (und sich die Definition des Ideals zwischen verschiedenen Personen ändert). Das richtige Datenbankdesign erfordert Erfahrung und Wissen, nicht automatisierte Tests.