Client-Server-Architektur beschreibt ein Modell, bei dem ein Systemteil Daten oder eine Aktion anfordert und ein anderer sie bereitstellt. Der Client startet die Anfrage; der Server verarbeitet sie und liefert ein Ergebnis.
Das klingt einfach, gehört aber zu den grundlegenden QA-Modellen. Sobald Sie ein Produkt so betrachten, werden viele Bugs von „seltsamem UI-Verhalten“ zu identifizierbaren Fehlerstellen: Client, Netzwerk, Server, Datenbank, externe Integration, Cache, Warteschlange oder Autorisierung.
So funktioniert es
In typischen Web- oder Mobilprodukten ist der Client ein Browser, eine mobile App oder ein anderer Dienst. Der Benutzer klickt, der Client sammelt Daten und sendet eine Anfrage. Der Server empfängt sie, prüft Rechte, validiert Eingaben, führt Geschäftslogik aus und greift bei Bedarf auf Datenbanken oder externe Systeme zu.
- →Ein Client kann Browser, mobile App, anderer Dienst oder externer Partner sein.
- →Der Server ist nicht immer ein einzelner Prozess oder Monolith.
- →Gateways, Load Balancer, Caches, Warteschlangen, Datenbanken und externe Integrationen liegen häufig auf dem Weg zwischen Client und Server.
Ein einziger Klick kann deshalb eine ganze Aktionskette statt einer einzelnen Operation auslösen.
Ein einfaches Beispiel
Ein Benutzer klickt „Bestellung bezahlen“. Der Client sendet Bestell-ID, Betrag und Benutzerdaten. Der Server prüft Existenz, Zahlungsberechtigung und ob der aktuelle Status eine Zahlung zulässt. Dann ruft er den Zahlungsanbieter auf, speichert das Ergebnis und antwortet dem Client.
Der Benutzer sieht nur Schaltfläche und abschließende Meldung. QA muss die gesamte Kette sehen; sonst lässt sich die Defektursache leicht falsch zuordnen.
Was QA prüfen muss
- →Ob überhaupt eine Anfrage gesendet wurde.
- →Welche Anfrage genau gesendet wurde.
- →Was der Server zurückgegeben hat.
- →Wie der Client die Antwort interpretiert hat.
- →Ob sich Daten überall dort geändert haben, wo sie sich ändern sollten.
- →Ob ein externer Dienst oder eine instabile Umgebung beteiligt ist.
Zeigt das UI einen falschen Betrag, kommen mehrere Ursachen infrage: falscher Serverwert, falsche Datenbankdaten, unerwartete Antwort eines externen Dienstes oder falsche Darstellung einer korrekten Antwort. Das sichtbare Symptom ist gleich, die Fehlerstelle verschieden.
Die am häufigsten geprüften Schichten
- →Clientschicht: Anfrage gesendet, Parameter richtig zusammengesetzt und Ergebnis korrekt dargestellt.
- →Serverschicht: Validierung, Zugriffskontrolle und Geschäftslogik funktionieren korrekt.
- →Datenschicht: Daten werden erwartungsgemäß angelegt, aktualisiert oder gelöscht.
- →Integrationsschicht: Umgang mit Ausfällen, Timeouts und unerwarteten Antworten externer Dienste.
Praktischer Nutzen
Erstens bei der Fehleruntersuchung: Wer nur den Bildschirm sieht, schreibt „funktioniert nicht“. Wer die Architektur versteht, schreibt: Die Anfrage enthielt einen falschen Parameter; der Server lieferte 403 trotz berechtigter Rolle; die Datenbank wurde nicht aktualisiert. Das ist eine wesentlich höhere Berichtsqualität.
Zweitens beim Testentwurf: Das Verständnis beteiligter Schichten ermöglicht stärkere Prüfungen für UI-Happy-Path, Netzwerkfehler, wiederholte Anfragen, Teilfehler, inkonsistente Daten und Integrationsprobleme.
Drittens in der Teamkommunikation: Das Modell erlaubt konkrete Aussagen über Client, Server, Daten oder externen Anbieter. Das spart Zeit und vereinfacht die Triage.
Wichtig für QA
- →Eine Benutzeraktion umfasst oft mehrere technische Schritte.
- →Derselbe sichtbare UI-Fehler kann in verschiedenen Systemschichten entstehen.
- →Untersuchen Sie zur Eingrenzung neben dem Bildschirm auch Anfrage, Antwort, Daten und Abhängigkeiten.
- →Das Verständnis der Client-Server-Architektur präzisiert Fehlerberichte und beschleunigt Untersuchungen.
Weiterführende Informationen
- →In dieser Wissensdatenbank: Was ist eine API? — Einführung in die zur Kommunikation verwendete Schnittstelle.
- →In dieser Wissensdatenbank: HTTP und HTTPS — zum besseren Verständnis der Transportschicht für Anfragen und Antworten.
- →In dieser Wissensdatenbank: Methoden, Statuscodes und Header — für sicherere Interpretation technischer API-Signale.
Eine Aktion vom Browser bis zur Speicherung verfolgen
Fiktives Szenario: Ein Lernender speichert einen Profil-Anzeigenamen. Anschließendes Lesen soll den neuen Namen für dasselbe autorisierte Konto zeigen. Eine Erfolgsmeldung beweist nur, dass der Client eine Meldung angezeigt hat, nicht den gespeicherten Zustand.
Schicht Beobachtung Was sie belegen kann
Browser Aktion, Eingabe, Anfragenutzlast und Zeitverlauf Was der Client tatsächlich gesendet hat
Netzwerk/API Methode, URL, Status, Nachrichtenkörper, Korrelations-ID Die beobachtete API-Antwort
Dienstprotokolle Gleiche Korrelations-ID und Validierungsergebnis Welcher Serverpfad die Anfrage verarbeitet hat, sofern Protokolle verfügbar sind
Speicher Autorisierter Testlesezugriff auf den Zieldatensatz Gespeicherter Wert zum beobachteten Zeitpunkt
Nachfolgender API-Lesezugriff GET-Antwort für dasselbe Konto Ob der Lesepfad den gespeicherten Wert liefertVerwenden Sie autorisiertes Testlesen oder eine Fixture statt Datenbankzugriff vorauszusetzen. Asynchrone Systeme versprechen möglicherweise keine sofortige Konsistenz: Vereinbaren Sie zuerst Abschlusssignal und Zeitfenster. Erhält der Browser nach einem Schreibrequest einen Timeout, prüfen Sie vor dem Retry das Ergebnis. Der Server könnte bereits gespeichert haben.
Vergleichen Sie benachbarte Beobachtungen zur Eingrenzung. Falsche Anfragedaten deuten auf Clientvorbereitung; eine korrekte Anfrage mit dokumentiertem Validierungsfehler auf Vertrags- oder Eingabeinterpretation; Erfolg bei fehlenden Daten verlangt Prüfung des Schreibpfads oder asynchronen Ablaufs. Das sind Untersuchungsrichtungen, keine bewiesenen Ursachen. Bewahren Sie Zeitstempel und Korrelations-IDs und entfernen Sie Geheimnisse aus Belegen.