Bei SQL für QA geht es darum, herauszufinden, was mit den Daten tatsächlich geschehen ist, nicht um tiefgehende Abfrageoptimierung oder Datenbankadministration. Wenn UI und API widersprüchliche Ergebnisse liefern, bietet die Datenbank oft den direktesten Nachweis.
Schon grundlegendes SQL verbessert Tests erheblich. Es prüft, ob Datensätze angelegt, Statuswerte gespeichert, Duplikate erzeugt, Beziehungen korrekt hergestellt, Berichte abgeglichen oder Daten nach einer Aktion entfernt wurden.
Warum QA SQL braucht
Im Alltag dient SQL meist drei Zielen:
- →Den tatsächlichen Datenzustand nach einem Szenario prüfen
- →Fehler schneller untersuchen
- →Erkennen, ob das Problem in UI, API, Logik oder Daten liegt
Viele vermeintliche Schaltflächenfehler sind in Wirklichkeit Probleme des Datenzustands.
- →Ein Datensatz erscheint in der UI, aber zugehörige Zeilen fehlen
- →Die API meldet Erfolg, aber eine Änderung wurde nicht gespeichert
- →Ein Bericht verwendet falsche Daten
- →Wiederholte Versuche erzeugen Duplikate
- →Ein Filter wirkt defekt, weil die gespeicherten Daten bereits von den Produkterwartungen abweichen
Ohne SQL können solche Untersuchungen langsam sein und auf unzureichenden Informationen beruhen.
Was zuerst gelernt werden sollte
QA muss anfangs nicht die gesamte Sprache beherrschen. Zunächst genügt Sicherheit bei einigen Grundlagen.
- →SELECT ruft Daten ab
- →WHERE filtert Zeilen
- →ORDER BY legt die Sortierung fest
- →LIMIT vermeidet den Abruf unnötiger Zeilen
- →COUNT zählt
- →JOIN verknüpft Daten aus mehreren Tabellen
- →GROUP BY macht Aggregate und Duplikate sichtbar
- →IS NULL und IS NOT NULL prüfen auf NULL-Werte
Damit lässt sich ein großer Teil alltäglicher Testaufgaben lösen.
Neben der Syntax auch den Zweck jeder Konstruktion verstehen. Mit Bestell-, Benutzer- und Zahlungstabellen kann SQL das gesamte Szenario prüfen, statt nur Zeilen anzuzeigen.
Was SQL QA ermöglicht
Die größte Stärke von SQL ist Präzision.
Die UI zeigt ausgewählte Informationen; eine API liefert die Antwort eines Aufrufs. Direkte Datenprüfung kann beantworten:
- →Wurde der Datensatz überhaupt angelegt?
- →Wie viele solcher Datensätze existieren tatsächlich?
- →Gibt es Duplikate?
- →Welchem Benutzer gehört die Entität?
- →Wurde der richtige Status gespeichert?
- →Gibt es verwaiste Datensätze?
- →Stimmt der Betrag mit der Oberfläche überein?
- →Hat die Operation den Datensatz wirklich geändert oder nur scheinbar?
Das ist besonders hilfreich bei Integrationen, Warteschlangen, Wiederholungen, Hintergrundaufgaben, Massenänderungen und komplexen Entitätsbeziehungen.
JOIN für QA
JOIN ist besonders wertvoll, weil es Beziehungen zwischen Entitäten zeigt, statt Tabellen nur einzeln zu betrachten.
- →Jede Bestellung hat einen Eigentümer
- →Eine Bestellung enthält die erforderlichen Bestellpositionen
- →Eine Zahlung gehört zur richtigen Bestellung
- →Ein Benutzer hat die richtige Rolle
- →Keine Datensätze verweisen auf nicht vorhandene Objekte
Oft existiert ein Datensatz, ist aber falsch verknüpft oder ein Teil seiner Beziehungskette ist unterbrochen. JOIN macht solche Fehler leichter sichtbar.
Häufige SQL-Fehler in QA
- →NULL mit einem leeren Wert verwechseln
- →Durch JOIN erzeugte doppelte Zeilen übersehen
- →Nur die erste bequem erreichbare Zeile prüfen
- →Unnötige Schreiboperationen ausführen
Das übliche sichere Vorgehen lautet: zuerst lesen und nur in einer geeigneten Umgebung gezielt ändern. SELECT reicht für die meisten Untersuchungen aus.
Praktisches Beispiel
Angenommen, ein Benutzer meldet zwei identische Bestellungen.
Die UI zeigt nur einen Ausschnitt, und ein API-Endpunkt liefert einen Teil. SQL kann wesentlich mehr klären:
- →Ob tatsächlich zwei Bestellzeilen existieren
- →Ob ihre fachlichen Schlüssel übereinstimmen
- →Ob sie gleichzeitig angelegt wurden
- →Ob beide identische Bestellpositionen haben
- →Ob eine Wiederholung das Duplikat erzeugt hat
- →Ob zwei Zahlungen oder nur eine existieren
- →Ob das Duplikat echt ist oder die UI denselben Datensatz zweimal anzeigt
Hier wird SQL zu einem praktischen QA-Werkzeug statt zu einer optionalen technischen Ergänzung.
Praktische Gewohnheiten für QA
- →Mit einem einfachen SELECT beginnen
- →Zuerst eine Entität prüfen, dann ihre Beziehungen
- →Immer klären, welcher Schlüssel die Daten identifiziert
- →Keine Schlüsse aus einer einzelnen Zeile ziehen, wenn ein größeres Muster relevant ist
- →Schreibabfragen sorgfältig behandeln
- →Bei Unsicherheit SQL-Nachweise mit dem Verhalten von API und UI vergleichen
SQL ist besonders wirkungsvoll als Verbindung zwischen Systemschichten.
Wichtige Erkenntnisse für QA
- →QA verwendet SQL, um die tatsächlichen Daten zu prüfen, nicht um eine Datenbank zu programmieren.
- →Grundlegende SELECT-, WHERE-, JOIN-, COUNT- und GROUP BY-Abfragen ermöglichen fundierte Fehleranalysen.
- →Viele Produktfehler sind Probleme des Datenzustands.
- →Nachweise aus UI, API und Datenbank zu verbinden, ist eine wertvolle Testkompetenz.
- →SQL macht die Diagnose präziser, schneller und methodischer.
Weiterführende Informationen
- →In dieser Wissensbasis: Datenbanktests
- →In dieser Wissensbasis: JSON und XML
- →Externe Ressource: PostgreSQL-Tutorial zu Joins
Mit einem gemeinsamen Datensatz üben: acht geprüfte Aufgaben
Das verlinkte QA-Hub-Aufgabenblatt und sql-for-qa-fixture.sql verwenden, statt einen zweiten Datensatz anzulegen. Es enthält vier fiktive Kunden und fünf Bestellungen mit ganzzahligen Centbeträgen. Die folgende Anleitung verwendet SQLite 3; die Ressource beschreibt auch portables SQL, behauptet hier aber keine Ausführung unter PostgreSQL. Beide Dateien herunterladen, ein Terminal in diesem Verzeichnis öffnen und eine Sitzung geöffnet lassen.
sqlite3 :memory:
-- At the SQLite prompt:
.read sql-for-qa-fixture.sql
SELECT COUNT(*) FROM qa_customers;
-- Expected: 4
SELECT COUNT(*) FROM qa_orders;
-- Expected: 5Die Fixture erstellt temporäre Tabellen in der aktuellen Sitzung. Eine neue :memory:-Sitzung beginnt leer; ein erneutes CREATE in derselben Sitzung ohne Zurücksetzen scheitert, weil die Tabellen bereits existieren. Zum Zurücksetzen die verwerfbare Sitzung schließen und eine neue starten. Produktionsverbindung oder Zugangsdaten sind nicht erforderlich.
Die Zeilen vor dem Öffnen des Lösungsblatts vorhersagen
Aufgabe in der Ressource Erwartetes Ergebnis
1 Bezahlte Bestellungen (101, 1, 1200), (103, 2, 700), (105, 3, 0)
2 Bestellungen je Kunde, einschließlich null Bestellungen (1, Ada, 2), (2, Boris, 2), (3, Chen, 1), (4, Dina, 0)
3 Bezahlter Umsatz je Kunde (1, 1200), (2, 700), (3, 0), (4, 0)
4 Kunden ohne Bestellungen (4, Dina)
5 Doppelte E-Mail-Adressen ungleich NULL (ada@example.invalid, 2)
6 Ungültiger bezahlter Betrag gemäß Aufgabenregel (105, 0)
7 Mindestens zwei Bestellungen (1, 2), (2, 2)
8 Fehlende E-Mail-Adresse (4, Dina)Aufgabennummern und Ergebnisse entsprechen dem herunterladbaren Blatt. Die doppelte E-Mail-Adresse und die bezahlte Bestellung mit Nullbetrag sind absichtlich vorbereitete Beispiele. Ob sie in einem echten Produkt Fehler darstellen, hängt von dessen Anforderungen ab. Regeln zu Eindeutigkeit, positiven Werten oder Normalisierung nicht allein aus einer Abfrage ableiten.
Die LEFT-JOIN-Falle: korrekte Summe bei fehlendem Kunden
Nach dem Laden der gemeinsamen Fixture diese beiden Abfragen vergleichen. Die Berichtsregel verlangt alle vier Kunden, einschließlich der Kunden ohne bezahlte Bestellungen. Die erste Abfrage setzt den Filter für bezahlte Bestellungen in WHERE:
SELECT c.customer_id, COALESCE(SUM(o.amount_cents), 0) AS paid_cents
FROM qa_customers c
LEFT JOIN qa_orders o ON o.customer_id = c.customer_id
WHERE o.status = 'paid'
GROUP BY c.customer_id ORDER BY c.customer_id;Sie liefert (1,1200), (2,700), (3,0): Dina verschwindet. Ihre nicht zugeordnete Join-Zeile enthält NULL in den Bestellfeldern und bleibt daher durch die WHERE-Bedingung nicht erhalten. Die Summe beträgt weiterhin 1900 Cent; deshalb übersieht eine Prüfung nur der Gesamtsumme den Fehler.
Den Filter in die Join-Bedingung verschieben, damit Kunden ohne passende Bestellung erhalten bleiben:
SELECT c.customer_id, COALESCE(SUM(o.amount_cents), 0) AS paid_cents
FROM qa_customers c
LEFT JOIN qa_orders o
ON o.customer_id = c.customer_id AND o.status = 'paid'
GROUP BY c.customer_id ORDER BY c.customer_id;Erwartet: (1,1200), (2,700), (3,0), (4,0). Sowohl die genauen Kunden-IDs als auch die Beträge prüfen. Für die Anzahl der Bestellungen ist COUNT(o.order_id) nötig; COUNT(*) zählt auch eine nicht zugeordnete Outer-Join-Zeile. NULL mit IS NULL statt mit = NULL prüfen. Das Lösungsblatt enthält diese Fälle mit ausführbaren Abfragen.
Eine Abweichung in nützliche Nachweise umwandeln
Fixture- oder Datenversion, SQL-Dialekt, Abfrage, Produktregel, erwartete und tatsächliche Zeilen erfassen. Vor dem Vergleich geordneter Ergebnisse ausdrücklich sortieren. Bei ungeordneten Ergebnissen Mengen oder Multimengen vergleichen, je nachdem, ob Duplikate relevant sind. Eine erfolgreich ausgeführte Abfrage beweist kein korrektes fachliches Ergebnis.
Weiterlernen
Prüfungen auf Datenbankverhalten erweitern
Datenabweichungen mit Nachweisen melden
Gemeinsame SQL-Fixture herunterladen