Datenbanktests - Typen

Basierend auf der Funktion und Struktur einer Datenbank können DB-Tests in drei Kategorien eingeteilt werden:

  • Structural Database Testing - Es befasst sich mit Tabellen- und Spaltentests, Schematests, Tests mit gespeicherten Prozeduren und Ansichten, Überprüfen von Triggern usw.

  • Functional Testing- Es beinhaltet die Überprüfung der Funktionalität der Datenbank aus Anwendersicht. Die gebräuchlichste Art von Funktionstests sind White-Box- und Black-Box-Tests.

  • Nonfunctional Testing - Es umfasst Lasttests, Risikotests in der Datenbank, Stresstests, Mindestsystemanforderungen und befasst sich mit der Leistung der Datenbank.

Testen von Strukturdatenbanken

Beim Testen struktureller Datenbanken werden die Datenbankkomponenten überprüft, die Endbenutzern nicht zugänglich sind. Es umfasst alle Komponenten des Repositorys, die zum Speichern der Daten verwendet werden und von den Endbenutzern nicht geändert werden. Datenbankadministratoren mit guten Kenntnissen über gespeicherte SQL-Prozeduren und andere Konzepte führen diese Tests normalerweise durch.

Diskutiert werden die gängigen Komponenten, die im Hinblick auf Strukturprüfungen getestet wurden -

Schema- / Zuordnungstests

Dabei werden die Objekte der Front-End-Anwendung mit einer Datenbankobjektzuordnung überprüft.

In Schematests -

  • Manchmal kommt es vor, dass die Endbenutzeranwendungsobjekte nicht korrekt zugeordnet oder mit Datenbankobjekten kompatibel sind. Daher ist eine Überprüfung der Validierung der verschiedenen Schemaformate erforderlich, die den Datenbanken zugeordnet sind.

  • Es ist erforderlich, die nicht zugeordneten Objekte in der Datenbank zu finden, z. B. Tabellen, Ansichten, Spalten usw.

Es gibt verschiedene Tools auf dem Markt, mit denen Objektzuordnungen in Schemas durchgeführt werden können.

Example - In Microsoft SQL Server kann ein Tester einfache Abfragen schreiben, um Schemas in der Datenbank zu überprüfen und zu validieren.

Wenn der Tester Änderungen an einer Tabellenstruktur vornehmen möchte, sollte er sicherstellen, dass alle stored Prozeduren mit dieser Tabelle sind mit dieser Änderung kompatibel.

Testen gespeicherter Prozeduren und Ansichten

Bei diesem Test stellt ein Tester sicher, dass die manuelle Ausführung gespeicherter Prozeduren und Ansichten das erforderliche Ergebnis generiert.

Der Tester sorgt dafür -

  • Wenn es ermöglicht, dass die erforderlichen Trigger wie erwartet ausgeführt werden.

  • Wenn das Entwicklungsteam alle Schleifen und Bedingungen abgedeckt hat, indem es Eingaben an Anwendungen in den Verfahren weiterleitet.

  • Wenn nicht verwendete gespeicherte Prozeduren in der Datenbank vorhanden sind.

  • TRIM-Operationen werden ordnungsgemäß angewendet, wenn die Daten aus den erforderlichen Tabellen in der Datenbank abgerufen werden.

  • Validierung der Gesamtintegration der gespeicherten Prozedurmodule gemäß den Anforderungen der zu testenden Anwendung.

  • Ausnahme- und Fehlerbehandlungsmechanismen werden befolgt.

Die gebräuchlichsten Tools zum Testen gespeicherter Prozeduren sind: LINQ, SP Test tool, usw.

Trigger-Test

Beim Trigger-Test muss ein Tester Folgendes sicherstellen:

  • Gibt an, ob die Codierungskonventionen während der Codierungsphase der Trigger eingehalten werden.

  • Die ausgeführten Trigger erfüllen die erforderlichen Bedingungen.

  • Gibt an, ob der Trigger die Daten nach ihrer Ausführung korrekt aktualisiert.

  • Die Validierung von Aktualisieren / Einfügen / Löschen löst die Funktionalität der zu testenden Anwendung aus.

Tabellen- und Säulentests

Die Schlüsselbereiche, die in diesen Tests abgedeckt werden, sind -

  • Überprüfen der Datentypen in der Datenbank auf Feldwerte in der Front-End-Anwendung.

  • Überprüfen der Länge des Datenfelds in der Datenbank auf die Länge der Datentypen in der Anwendung.

  • Überprüfen, ob in der Datenbank nicht zugeordnete Tabellen oder Spalten von Anwendungsfeldobjekten vorhanden sind.

  • Namenskonventionen von Datenbanktabellen und -spalten werden überprüft, ob sie den Geschäftsanforderungen entsprechen oder nicht.

  • Die Überprüfung der Schlüssel und Indizes in der Datenbank, dh Primär- und Fremdschlüssel in Tabellen, wird gemäß den Anforderungen definiert.

  • Überprüfen Sie in zwei Tabellen, ob die Primärschlüssel und die entsprechenden Fremdschlüssel identisch sind.

  • Überprüfen Sie, ob die eindeutigen und NICHT NULL-Eigenschaften der Schlüssel erhalten bleiben.

  • Länge und Datentyp der Schlüssel und Indizes werden gemäß den Anforderungen beibehalten.

Datenbankserverprüfung

Bei der Datenbankserverprüfung wird Folgendes überprüft:

  • Wenn der Datenbankserver die erwartete Anzahl von Transaktionen gemäß den Geschäftsanforderungen verarbeiten kann.

  • Wenn die Konfigurationsdetails von Datenbankservern den Geschäftsanforderungen entsprechen.

  • Wenn die Benutzerberechtigung gemäß Anforderung beibehalten wird.

Funktionsprüfung

Funktionstests werden unter Berücksichtigung des Endbenutzers durchgeführt. ob die von den Endbenutzern ausgeführten erforderlichen Transaktionen und Vorgänge den Geschäftsspezifikationen entsprechen.

Black-Box-Test

Beim Black-Box-Test wird die Integration der Datenbank überprüft, um die Funktionalität zu überprüfen. Die Testfälle sind einfach und werden verwendet, um eingehende und ausgehende Daten von der Funktion zu überprüfen.

Verschiedene Techniken wie die Ursache-Wirkungs-Grafiktechnik, die Äquivalenzpartitionierung und die Randwertanalyse werden verwendet, um die Funktionalität der Datenbank zu testen.

Es ist advantages sind wie folgt -

  • Es ist ziemlich einfach und wird in den frühen Stadien der Entwicklung durchgeführt.
  • Die Kosten für die Entwicklung von Testfällen sind im Vergleich zu White-Box-Tests geringer.

Seine Nachteile sind wie folgt:

  • Einige Fehler können nicht erkannt werden
  • Es ist nicht bekannt, wie viel Programm getestet werden muss.

White-Box-Test

White Box Testing befasst sich mit der internen Struktur der Datenbank und die Spezifikationsdetails sind den Benutzern verborgen. Es umfasst das Testen von Datenbank-Triggern und logischen Ansichten, die das Datenbank-Refactoring unterstützen.

Es führt Modultests von Datenbankfunktionen, Triggern, Ansichten, SQL-Abfragen usw. durch. Diese Art des Testens überprüft Datenbanktabellen, Datenmodelle, Datenbankschemata usw. Es überprüft Regeln der referenziellen Integrität. Es werden Standardtabellenwerte ausgewählt, um die Datenbankkonsistenz zu überprüfen.

Die gebräuchlichsten Techniken zur Durchführung von White-Box-Tests sind Bedingungsabdeckung, Entscheidungsabdeckung, Anweisungsabdeckung usw.

Bei White-Box-Tests können Codierungsfehler erkannt werden, sodass interne Fehler in der Datenbank beseitigt werden können. Die Einschränkung beim White-Box-Testen besteht darin, dass SQL-Anweisungen nicht behandelt werden.

Nicht funktionierende Tests

Nichtfunktionale Tests umfassen die Durchführung von Lasttests, Stresstests, die Überprüfung der Mindestsystemanforderungen zur Erfüllung der Geschäftsspezifikationen, die Risikofindung und die Leistungsoptimierung der Datenbank.

Lasttest

Das Hauptziel von Lasttests besteht darin, zu überprüfen, ob die meisten ausgeführten Transaktionen Auswirkungen auf die Leistung der Datenbank haben.

Beim Lasttest prüft der Tester -

  • Die Antwortzeit für die Ausführung der Transaktionen für mehrere Remotebenutzer.
  • Zeit, die die Datenbank benötigt, um bestimmte Datensätze abzurufen.

Examples of load testing in different testing types - -

  • Ausführen der am häufigsten verwendeten Transaktion wiederholt, um die Leistung des Datenbanksystems zu überprüfen.
  • Herunterladen einer Reihe großer Dateien aus dem Internet.
  • Ausführen mehrerer Anwendungen auf einem Computer oder Server gleichzeitig.

Belastbarkeitstest

Stresstests werden durchgeführt, um den Systembruchpunkt zu identifizieren. Bei diesem Test wird die Anwendung so geladen, dass das System an einem Punkt ausfällt. Dieser Punkt wird als bezeichnetbreakpoint des Datenbanksystems.

Das Ermitteln des Status von Datenbanktransaktionen ist mit einem erheblichen Aufwand verbunden. Eine ordnungsgemäße Planung ist erforderlich, um zeit- und kostenbezogene Probleme zu vermeiden.

Die am häufigsten verwendeten Stresstest-Tools sind LoadRunner und WinRunner.

Nehmen wir eine examplevon Stresstests. Eine CRM-Anwendung kann eine maximale Benutzerlast von 50000 gleichzeitigen Benutzern aufnehmen. Angenommen, Sie erhöhen die Last auf 51000 und führen einige Transaktionen durch, z. B. das Aktualisieren von Datensätzen oder das Hinzufügen eines Eintrags. Sobald Sie die Transaktion ausführen, kann die Anwendung mit dem Datenbanksystem synchronisiert werden. Der nächste Test besteht also darin, mit einer Benutzerlast von 52000 durchzuführen. Manchmal wird auch Stresstest genanntFatigue Testing.