Tutorial zum Datenbanktest

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 Banking-Anwendung, in der ein Benutzer Transaktionen durchführt. Aus Sicht des Datenbanktests oder DB-Tests sind folgende Dinge wichtig:

1. Die Anwendung speichert die Transaktionsinformationen in der Anwendungsdatenbank und zeigt sie dem Benutzer korrekt an.
2. Dabei gehen keine Informationen verloren.
3. Es werden von der Anwendung keine Informationen zu teilweise ausgeführten oder abgebrochenen Vorgängen gespeichert.
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

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.
Bei dieser Art des Testens geht es hauptsächlich um alle testbaren Elemente, 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-End-Tools)	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-ähnlich Oracle, SQL Server, MySQL usw.
Diese Art von Tests umfasst die Validierung der Textfelder 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 fundierte Kenntnisse der Konzepte von Datenbankservern und Structured Query Language verfügen.

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.

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. Darüber hinaus muss überprüft werden, ob heterogene Datenbanken in einer Umgebung mit der gesamten Anwendungszuordnung konsistent sind.

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.

5. 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.

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

• Clustered-Indizes
• Nein Clustered-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 den TRIM-Vorgang immer ordnungsgemäß angewendet, wenn Daten aus den erforderlichen Tabellen in der Datenbank abgerufen wurden?
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

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 von Datenbanktest, der verwendet wird, um die funktionalen Anforderungen einer Datenbank aus der Sicht des Endbenutzers zu validieren. Das Hauptziel des funktionalen Datenbanktests besteht darin, zu prüfen, ob die von den Endbenutzern durchgeführten Transaktionen und Vorgänge, die mit der Datenbank in Zusammenhang stehen, wie erwartet funktionieren oder nicht.

Nachfolgend sind die grundlegenden Bedingungen aufgeführt, die bei Datenbankvalidierungen beachtet werden müssen.

• Ob das Feld obligatorisch ist und gleichzeitig NULL-Werte in diesem Feld zulässig sind?
• 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 speziellen Prozess handelt es sich um die Validierung der Feldzuordnungen aus Sicht des Endbenutzers. In diesem speziellen Szenario führt der Tester einen Vorgang auf Datenbankebene aus und navigiert dann zum entsprechenden Benutzeroberflächenelement, um zu beobachten und zu validieren, ob die richtigen Feldvalidierungen durchgeführt wurden oder nicht.

Der umgekehrte Fall, bei dem der Tester zuerst den Vorgang an der Benutzeroberfläche ausführt und dieser anschließend vom Backend aus validiert wird, muss ebenfalls eingehalten werden.

Überprüfung der Datenintegrität und -konsistenz

Folgende 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. Wurden TRIM-Operationen an den Daten durchgeführt, bevor die Daten in die zu testende Datenbank eingefügt wurden?
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 heterogene Datenbanken an der betreffenden Transaktion beteiligt waren?
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 Benutzersicherheitsdaten müssen die folgenden Aspekte berücksichtigt werden.

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.

2. Darf der Benutzer nur die spezifischen Vorgänge ausführen, die in den Geschäftsanforderungen festgelegt sind?
3. Ob die Daten vor unbefugtem Zugriff geschützt sind?
4. Gibt es unterschiedliche Benutzerrollen mit unterschiedlichen Berechtigungen?
5. Verfügen alle Benutzer über die erforderlichen Zugriffsebenen auf die angegebene Datenbank, wie in den Geschäftsspezifikationen gefordert?
6. Überprüfen Sie, ob vertrauliche Daten wie Passwörter und Kreditkartennummern verschlüsselt und nicht als Klartext in der Datenbank gespeichert sind. Es empfiehlt sich, sicherzustellen, dass alle Konten komplexe Passwörter haben, die nicht leicht zu erraten sind.

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 Stakeholder zu erfüllen. So können externe Hardware, Software und die damit verbundenen Betriebskosten minimiert werden. Diese besondere Anforderung kann als allgemeine Geschäftsoptimierungsanforderung kategorisiert werden.

Load Testing

Der Zweck eines jeden Belastungstests sollte klar verstanden und dokumentiert werden. Die folgenden Konfigurationstypen 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. In die endgültige Testsuite sollte mindestens eine Benutzertransaktion ohne Bearbeitung aufgenommen werden, damit die Ausführung solcher Transaktionen von anderen, komplexeren Transaktionen unterschieden werden kann.
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.

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

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.

Best Practices

• 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