Tutorial zum Testen von Datenbanken (Daten).

Was ist Datenbanktest?

Datenbanktests ist eine Art Softwaretest, der das Schema, die Tabellen, Trigger usw. der zu testenden Datenbank überprüft. Außerdem prüft es die Datenintegrität und -konsistenz. Es kann die Erstellung von com beinhaltenplex Abfragen zum Laden/Stresstesten der Datenbank und Überprüfen ihrer Reaktionsfähigkeit.

Datenbanktests

Warum sind Datenbanktests wichtig?

Datenbanktests sind wichtig in Softwaretest weil dadurch sichergestellt wird, dass die empfangenen und in der Datenbank gespeicherten Datenwerte und Informationen gültig sind oder nicht. Datenbanktests helfen, Datenverluste zu vermeiden, abgebrochene Transaktionsdaten zu speichern und einen unbefugten Zugriff auf die Informationen zu verhindern. Datenbanken sind für jede Softwareanwendung wichtig, daher müssen Tester zum Testen von Datenbanken über gute SQL-Kenntnisse verfügen.

Der GUI wird von den Mitgliedern des Test- und Entwicklungsteams in der Regel die größte Bedeutung beigemessen, da die grafische Benutzeroberfläche zufällig der sichtbarste Teil der Anwendung ist. Wichtig ist jedoch auch die Validierung der Informationen, die das Herzstück der Anwendung bilden, auch bekannt als DATENBANK.

Betrachten wir eine Bankanwendung, bei der ein Benutzer Transaktionen durchführt. Nun folgt aus der Sicht des Datenbanktests oder DB-Testswing, Dinge sind wichtig:

  1. Die Anwendung speichert die Transaktionsinformationen in der Anwendungsdatenbank und zeigt sie dem Benutzer korrekt an.
  2. Dabei gehen keine Informationen verloren.
  3. Die Anwendung speichert keine Informationen zu teilweise durchgeführten oder abgebrochenen Vorgängen.
  4. Es ist keiner unbefugten Person gestattet, auf die Informationen des Benutzers zuzugreifen.

Um alle oben genannten Ziele sicherzustellen, müssen wir Datenvalidierung oder Datentests verwenden.

Unterschiede zwischen Benutzeroberflächentests und Datentests

Benutzeroberflächentests vs. Datentests

Testen der Benutzeroberfläche Datenbank- oder Datentests
Diese Art von Tests wird auch als grafische Benutzeroberflächentests oder Front-End-Tests bezeichnet. Diese Art von Tests wird auch als Backend-Testing oder Datentests bezeichnet.
Diese Art des Testens befasst sich hauptsächlich mit allen testbaren Elementen, die dem Benutzer zur Ansicht und Interaktion offen stehen, wie Formulare, Präsentationen, Diagramme, Menüs und Berichte usw. (erstellt mit VB, VB.net, VC++, Delphi – Front-) Endwerkzeuge) Diese Art des Testens befasst sich hauptsächlich mit allen testbaren Elementen, die dem Benutzer im Allgemeinen für die Zuschauer verborgen bleiben. Dazu gehören interne Prozesse und Speicher wie Assembly, DBMS wie Oracle, SQL Server, MYSQL usw.

Diese Art von Tests umfasst die Validierung der

  • Text boxes
  • Dropdown-Listen auswählen
  • Kalender und Schaltflächen
  • Seitennavigation
  • Anzeige von Bildern
  • Look and Feel der gesamten Anwendung

Diese Art von Tests umfasst die Validierung von:

  • das Schema
  • Datenbanktabellen
  • Spalten
  • Schlüssel und Indizes
  • gespeicherte Prozeduren auslösen
  • Datenbankservervalidierungen
  • Validierung der Datenduplizierung
Der Tester muss über umfassende Kenntnisse der Geschäftsanforderungen sowie der Verwendung der Entwicklungstools und der Verwendung von Automatisierungsframeworks und -tools verfügen. Um Backend-Tests durchführen zu können, muss der Tester über umfassende Kenntnisse im Datenbankserver- und Structured Query Language-Konzept verfügen.

Arten von Datenbanktests

Arten von Datenbanktests

Es gibt drei Arten von Datenbanktests

  1. Strukturprüfung
  2. Funktionsprüfung
  3. Nichtfunktionales Testen

In diesem Datenbanktest-Tutorial werden wir jeden Typ und seine Untertypen einzeln untersuchen.

Strukturelle Datenbanktests

Strukturelle Datenbanktests ist eine Datenbanktesttechnik, die alle Elemente im Datenrepository validiert, die hauptsächlich zur Datenspeicherung verwendet werden und nicht direkt von Endbenutzern manipuliert werden dürfen. Die Validierung von Datenbankservern ist auch ein wichtiger Aspekt bei strukturellen Datenbanktests. Um diesen Test erfolgreich abzuschließen, müssen Sie SQL-Abfragen beherrschen.

Was ist Schematest?

Schematests Beim Datenbanktest werden verschiedene mit der Datenbank verknüpfte Schemaformate validiert und überprüft, ob die Zuordnungsformate von Tabellen/Ansichten/Spalten mit den Zuordnungsformaten der Benutzeroberfläche kompatibel sind. Der Hauptzweck des Schematests besteht darin, sicherzustellen, dass die Schemazuordnung zwischen Front-End und Back-End ähnlich ist. Daher wird es auch als Mapping-Test bezeichnet.

Lassen Sie uns die wichtigsten Prüfpunkte für Schematests besprechen.

  1. Validierung der verschiedenen Schemaformate, die den Datenbanken zugeordnet sind. Oftmals ist das Zuordnungsformat der Tabelle möglicherweise nicht mit dem Zuordnungsformat kompatibel, das auf der Benutzeroberflächenebene der Anwendung vorhanden ist.
  2. Bei nicht zugeordneten Tabellen/Ansichten/Spalten besteht Überprüfungsbedarf.
  3. Es muss auch überprüft werden, ob heterogeneoUS-Datenbanken in einer Umgebung stimmen mit der gesamten Anwendungszuordnung überein.

Schauen wir uns auch einige der interessanten Datenbanktesttools zur Validierung von Datenbankschemata an.

  • DBUnit, das in Ant integriert ist, eignet sich sehr gut für Mapping-Tests.
  • Mit SQL Server können Tester das Schema der Datenbank überprüfen und abfragen, indem sie einfache Abfragen und nicht Code schreiben.

Wenn die Entwickler beispielsweise eine Tabellenstruktur ändern oder löschen möchten, möchte der Tester sicherstellen, dass alle gespeicherten Prozeduren und Ansichten, die diese Tabelle verwenden, mit der jeweiligen Änderung kompatibel sind. Ein anderes Beispiel könnte sein, dass die Tester, wenn sie nach Schemaänderungen zwischen zwei Datenbanken suchen möchten, dies mithilfe einfacher Abfragen tun können.

Datenbanktabelle, Spaltentest

Schauen wir uns verschiedene Prüfungen für Datenbank- und Spaltentests an.

  1. Ob die Zuordnung der Datenbankfelder und -spalten im Backend mit den Zuordnungen im Frontend kompatibel ist?
  2. Validierung der Länge und Namenskonvention der Datenbankfelder und -spalten gemäß den Anforderungen.
  3. Validierung des Vorhandenseins aller nicht verwendeten/nicht zugeordneten Datenbanktabellen/Spalten.
  4. Validierung der Kompatibilität der
  • Datentyp
  • Feldlängen

der Back-End-Datenbankspalten mit denen im Front-End der Anwendung.

  1. Ob die Datenbankfelder es dem Benutzer ermöglichen, gewünschte Benutzereingaben gemäß den Geschäftsanforderungsspezifikationsdokumenten bereitzustellen.

Testen von Schlüsseln und Indizes

Wichtige Prüfungen für Schlüssel und Indizes –

  1. Prüfen Sie, ob die erforderlichen
  • Primärschlüssel
  • Unbekannter Schlüssel

Für die erforderlichen Tabellen wurden Einschränkungen erstellt.

  1. Prüfen Sie, ob die Referenzen für Fremdschlüssel gültig sind.
  2. Überprüfen Sie, ob der Datentyp des Primärschlüssels und der entsprechenden Fremdschlüssel in den beiden Tabellen gleich ist.
  3. Überprüfen Sie, ob für alle Schlüssel und Indizes die erforderlichen Namenskonventionen eingehalten wurden.
  4. Überprüfen Sie die Größe und Länge der erforderlichen Felder und Indizes.
  5. Ob das erforderliche
  • Clustered-Indizes
  • Nicht gruppierte Indizes

wurden gemäß den Geschäftsanforderungen für die erforderlichen Tabellen erstellt.

Testen gespeicherter Prozeduren

Wichtige Tests zur Überprüfung gespeicherter Prozeduren sind:

  1. Ob das Entwicklungsteam die erforderlichen A) Codierungsstandardkonventionen und B) Ausnahme- und Fehlerbehandlung übernommen hat. Für alle gespeicherten Prozeduren für alle Module der zu testenden Anwendung.
  2. Hat das Entwicklungsteam alle Bedingungen/Schleifen abgedeckt, indem es die erforderlichen Eingabedaten auf die zu testende Anwendung angewendet hat?
  3. Hat das Entwicklungsteam die TRIM-Operation ordnungsgemäß angewendet, wenn Daten aus den erforderlichen Tabellen in der Datenbank abgerufen werden?
  4. Ob die manuelle Ausführung der Stored Procedure dem Endbenutzer das gewünschte Ergebnis liefert?
  5. Stellt die manuelle Ausführung der gespeicherten Prozedur sicher, dass die Tabellenfelder entsprechend den Anforderungen der zu testenden Anwendung aktualisiert werden?
  6. Ob die Ausführung der Stored Procedures das implizite Aufrufen der erforderlichen Trigger ermöglicht?
  7. Überprüfung des Vorhandenseins ungenutzter gespeicherter Prozeduren.
  8. Validierung für die Bedingung „Null zulassen“, die auf Datenbankebene durchgeführt werden kann.
  9. Validierung der Tatsache, dass alle gespeicherten Prozeduren und Funktionen erfolgreich ausgeführt wurden, wenn die zu testende Datenbank leer ist.
  10. Validierung der Gesamtintegration der gespeicherten Prozedurmodule gemäß den Anforderungen der zu testenden Anwendung.

Einige der nützlichen Datenbanktesttools zum Testen gespeicherter Prozeduren sind LINQ, das SP-Testtool usw.

Triggertests

  1. Wurden während der Codierungsphase der Trigger die erforderlichen Codierungskonventionen befolgt?
  2. Prüfen Sie, ob die für die jeweiligen DML-Transaktionen ausgeführten Trigger die erforderlichen Bedingungen erfüllt haben.
  3. Ob der Trigger die Daten nach ihrer Ausführung korrekt aktualisiert?
  4. Validierung der erforderlichen Update-/Einfüge-/Lösch-Trigger-Funktionalität im Bereich der zu testenden Anwendung.

Datenbankservervalidierungen

Datenbankservervalidierungen

  1. Überprüfen Sie die Datenbankserverkonfigurationen gemäß den Geschäftsanforderungen.
  2. Überprüfen Sie die Berechtigung des erforderlichen Benutzers, nur die Aktionsebenen auszuführen, die für die Anwendung erforderlich sind.
  3. Überprüfen Sie, ob der Datenbankserver in der Lage ist, die Anforderungen der maximal zulässigen Anzahl von Benutzertransaktionen gemäß den Geschäftsanforderungsspezifikationen zu erfüllen.

Funktionale Datenbanktests

Funktionale Datenbanktests ist eine Art Datenbanktest, der dazu dient, die funktionalen Anforderungen einer Datenbank aus der Sicht des Endbenutzers zu validieren. Das Hauptziel funktionaler Datenbanktests besteht darin, zu testen, ob die von den Endbenutzern durchgeführten Transaktionen und Vorgänge im Zusammenhang mit der Datenbank wie erwartet funktionieren oder nicht.

Following sind die Grundbedingungen, die bei Datenbankvalidierungen beachtet werden müssen.

  • Ob das Feld während allo obligatorisch istwing NULL-Werte in diesem Feld?
  • Ob die Länge jedes Feldes ausreichend groß ist?
  • Ob alle ähnlichen Felder tabellenübergreifend dieselben Namen haben?
  • Gibt es in der Datenbank berechnete Felder?

Bei diesem besonderen Prozess handelt es sich um die Validierung der Feldzuordnungen aus der Sicht des Endbenutzers. In diesem speziellen Szenario würde der Tester einen Vorgang auf Datenbankebene durchführen und dann zum relevanten Benutzeroberflächenelement navigieren, um zu beobachten und zu validieren, ob die richtigen Feldvalidierungen durchgeführt wurden oder nicht.

Die umgekehrte Bedingung, dass der Tester zuerst den Vorgang an der Benutzeroberfläche ausführt und dann vom Back-End aus validiert, sollte ebenfalls erfüllt werden.

Überprüfung der Datenintegrität und -konsistenz

Following Kontrollen sind wichtig

  1. Ob die Daten logisch gut organisiert sind?
  2. Sind die in den Tabellen gespeicherten Daten korrekt und entsprechen den Geschäftsanforderungen?
  3. Sind in der getesteten Anwendung unnötige Daten vorhanden?
  4. Wurden die Daten gemäß den Anforderungen in Bezug auf Daten gespeichert, die über die Benutzeroberfläche aktualisiert wurden?
  5. Werden die TRIM-Operationen an den Daten durchgeführt, bevor Daten in die zu testende Datenbank eingefügt werden?
  6. Ob die Transaktionen gemäß den Geschäftsanforderungsspezifikationen durchgeführt wurden und ob die Ergebnisse korrekt sind oder nicht?
  7. Ob die Daten ordnungsgemäß festgeschrieben wurden, wenn die Transaktion erfolgreich ausgeführt wurde?
  8. Ob die Daten erfolgreich zurückgesetzt wurden, wenn die Transaktion vom Endbenutzer nicht erfolgreich ausgeführt wurde?
  9. Ob die Daten zurückgesetzt wurden, wenn die Transaktion nicht erfolgreich ausgeführt wurde und mehrere heterogeneneoUS-Datenbanken waren an der betreffenden Transaktion beteiligt?
  10. Ob alle Transaktionen unter Verwendung der erforderlichen Entwurfsverfahren gemäß den Geschäftsanforderungen des Systems ausgeführt wurden?

Anmelde- und Benutzersicherheit

Bei der Validierung der Anmelde- und Benutzersicherheitsanmeldeinformationen muss Folgendes berücksichtigt werdenwing Dinge.

  1. Ob die Anwendung den Benutzer daran hindert, mit der Anwendung fortzufahren, wenn a
  • Ungültiger Benutzername, aber gültiges Passwort
  • gültiger Benutzername, aber ungültiges Passwort.
  • Ungültiger Benutzername und ungültiges Passwort.
  1. Ob der Benutzer nur die spezifischen Vorgänge ausführen darf, die in den Geschäftsanforderungen festgelegt sind?
  2. Ob die Daten vor unbefugtem Zugriff geschützt sind?
  3. Gibt es unterschiedliche Benutzerrollen mit unterschiedlichen Berechtigungen?
  4. Verfügen alle Benutzer über die erforderlichen Zugriffsebenen auf die angegebene Datenbank, wie in den Geschäftsspezifikationen gefordert?
  5. Stellen Sie sicher, dass sensible Daten wie Passwörter und Kreditkartennummern verschlüsselt und nicht als Klartext in der Datenbank gespeichert werden. Es empfiehlt sich, sicherzustellen, dass alle Konten über sichere Passwörter verfügenplex und nicht leicht zu erraten.

Nicht funktionales Testen

Nicht funktionales Testen im Zusammenhang mit Datenbanktests können entsprechend den Geschäftsanforderungen in verschiedene Kategorien eingeteilt werden. Dies können Lasttests, Stresstests, Sicherheitstests, Usability-Tests und Kompatibilitätstests, und so weiter. Die Belastungstests sowie die Stresstests, die unter der Skala der Leistungstests zusammengefasst werden können, dienen zwei spezifischen Zwecken, wenn es um die Rolle nichtfunktionaler Tests geht.

Risikoquantifizierung– Die Quantifizierung des Risikos hilft den Beteiligten, die verschiedenen Anforderungen an die Systemreaktionszeit unter den erforderlichen Lastniveaus zu ermitteln. Dies ist die ursprüngliche Absicht von jedem Qualitätskontrolle Aufgabe. Wir müssen beachten, dass Belastungstests das Risiko nicht direkt mindern, sondern durch die Prozesse der Risikoidentifizierung und Risikoquantifizierung Korrekturmöglichkeiten und einen Impuls für Abhilfemaßnahmen bieten, die das Risiko mindern.

Mindestanforderungen an die Systemausrüstung– Die minimale Systemkonfiguration, die es dem System ermöglicht, die formal festgelegten Leistungserwartungen der Beteiligten zu erfüllen. Also das ExtraneoDurch den Einsatz von Hardware und Software können die damit verbundenen Betriebskosten minimiert werden. Diese spezielle Anforderung kann als allgemeine Anforderung zur Geschäftsoptimierung kategorisiert werden.

Load Testing

Der Zweck jedes Belastungstests sollte klar verstanden und dokumentiert werden. Die folgendenwing Arten von Konfigurationen sind ein Muss für Lastprüfung.

  1. Die am häufigsten verwendeten Benutzertransaktionen können die Leistung aller anderen Transaktionen beeinträchtigen, wenn sie nicht effizient sind.
  2. Mindestens eine nicht bearbeitende Benutzertransaktion sollte in der endgültigen Testsuite enthalten sein, damit die Leistung solcher Transaktionen von anderen Transaktionen unterschieden werden kannplex Transaktionen.
  3. Die wichtigeren Transaktionen, die die Kernziele des Systems ermöglichen, sollten einbezogen werden, da ein Ausfall unter der Last dieser Transaktionen per Definition die größten Auswirkungen hat.
  4. Dazu sollte mindestens eine bearbeitbare Transaktion enthalten sein Leistung Solche Transaktionen können von anderen Transaktionen unterschieden werden.
  5. Optimale Reaktionszeit bei einer großen Anzahl virtueller Benutzer für alle zukünftigen Anforderungen.
  6. Effektive Zeiten zum Abrufen verschiedener Datensätze.

Wichtige Lasttest-Tools sind LoadRunner Professional, Win Runner und JMeter.

Was ist ein Datenbank-Stresstest?

Datenbank-Stresstest ist eine Testmethode, mit der ein Datenbanksystem unter hoher Auslastung einem Stresstest unterzogen wird, sodass es irgendwann ausfällt. Dies hilft bei der Identifizierung des Ausfallpunkts des Datenbanksystems. Es erfordert eine angemessene Planung und entsprechende Anstrengungen, um eine übermäßige Nutzung der Ressourcen zu vermeiden. Daten Stress-Tests wird auch als quälende Prüfung oder Ermüdungsprüfung bezeichnet.

Wichtige Stresstest-Tools sind LoadRunner Professional und JMeter.

Die am häufigsten auftretenden Probleme beim Datenbanktest

A significant amount of overhead could be involved to determine the state of the database transactions

Lösung: Die gesamte Prozessplanung und -planung sollte so organisiert sein, dass keine zeit- und kostenbedingten Probleme auftreten.

New test data have to be designed after cleaning up of the old test data.

Lösung: Ein vorheriger Plan und eine Methodik für die Testdatengenerierung sollten vorliegen.

An SQL generator is required to transform SQL validators in order to ensure the SQL queries are apt for handling the required database test cases.

Lösung: Die Pflege der SQL-Abfragen und deren kontinuierliche Aktualisierung ist ein wesentlicher Teil des gesamten Testprozesses, der Teil des Gesamtprozesses sein sollte Teststrategie.

The above mentioned prerequisite ensure that the set-up of the database testing procedure could be costly as well as time consuming.

Lösung: Es sollte ein ausgewogenes Verhältnis zwischen Qualität und Gesamtdauer des Projektzeitplans bestehen.

Mythen oder Missverständnisse im Zusammenhang mit Datenbanktests

Mythen

Database Testing requires plenty of expertise and it is a very tedious job

Wirklichkeit: Effektive und effiziente Datenbanktests im Softwaretest sorgen für eine langfristige Funktionsstabilität der gesamten Anwendung und erfordern daher harte Arbeit.

Database testing adds extra work bottleneck

Wirklichkeit: Im Gegenteil, Datenbanktests steigern den Wert der Gesamtarbeit, indem sie versteckte Probleme aufdecken und so proaktiv zur Verbesserung der Gesamtanwendung beitragen.

Database testing slows down the overall development process

Wirklichkeit: Ein erheblicher Umfang an Datenbanktests trägt zur allgemeinen Verbesserung der Qualität der Datenbankanwendung bei.

Database testing could be excessively costly

Wirklichkeit: Jeder Aufwand für Datenbanktests ist eine langfristige Investition, die zu einer langfristigen Stabilität und Robustheit der Anwendung führt. Somit sind Ausgaben für Datenbanktests bzw SQL Tests sind notwendig.

Praxisbeispiele

  • Alle Daten, einschließlich der Metadaten sowie der Funktionsdaten, müssen entsprechend ihrer Zuordnung durch die Anforderungsspezifikationsdokumente validiert werden.
  • Überprüfung der Testdaten das vom/in Absprache mit dem Entwicklungsteam erstellt wurde, muss validiert werden.
  • Validierung der Ausgabedaten mithilfe sowohl manueller als auch automatisierter Verfahren.
  • Einsatz verschiedener Techniken wie der Ursache-Wirkungs-Grafiktechnik, der Äquivalenzpartitionierungstechnik und der Randwertanalysetechnik zur Generierung der erforderlichen Testdatenbedingungen.
  • Die Validierungsregeln der referenziellen Integrität für die erforderlichen Datenbanktabellen müssen ebenfalls validiert werden.
  • Die Auswahl von Standardtabellenwerten für die Validierung der Datenbankkonsistenz ist ein sehr wichtiges Konzept. Ob die Protokollereignisse für alle erforderlichen Anmeldeereignisse erfolgreich zur Datenbank hinzugefügt wurden
  • Werden geplante Jobs rechtzeitig ausgeführt?
  • Erstellen Sie rechtzeitig ein Backup der Datenbank.

Auch Check- Fragen und Antworten zum Datenbanktest-Interview