Mit Klick auf den Play-Button laden Sie ein Video von unserem externen Anbieter YouTube. Datenschutzerklärung

Ab die POST! Einführung in WebAPI-Tests mit QF-Test

Mit QF-Test 10 wird das Testen von Web-Schnittstellen grundlegend überarbeitet, mit Fokus auf WebAPIs wie REST, SOAP und andere Webdienste. In diesem Spezialwebinar stellen wir Ihnen die neuen Funktionen vor.

Material:


Zusammenfassung

Mit der kommenden Version QF-Test 10 wird das Testen von Webanwendungen und Web-APIs grundlegend überarbeitet. Ein besonderer Fokus liegt dabei auf Web-APIs wie REST, SOAP und anderen webbasierten Diensten.

Das Testen solcher APIs unterscheidet sich deutlich vom klassischen GUI-Testen. Zwar bietet QF-Test auch weiterhin visuelle Testknoten, jedoch werden zusätzlich Skriptknoten benötigt, um realistische Abläufe zu simulieren. Die neuen Funktionen ermöglichen es, auch komplexe Testabläufe in wiederverwendbaren Prozeduren zu kapseln.

Im Anschluss übergibt Thomas Max an seinen Kollegen Plamen Vesselinov, der die neuen Möglichkeiten in einer Live-Demo vorstellt.

Einführung in das Testen von Web-APIs

Plamen Vesselinov erläutert zunächst die grundlegenden Unterschiede zwischen GUI-Tests und API-Tests: Während QF-Test bisher hauptsächlich Benutzeroberflächen automatisiert getestet hat – also Klicks, Eingaben und sichtbare Reaktionen – kommunizieren Web-APIs direkt über das Netzwerk. Daten werden über HTTP-Anfragen ausgetauscht, meist im JSON-Format, seltener in XML oder anderen Strukturen.

Ein Beispiel: Eine Anwendung fragt über eine API nach den Daten eines Benutzers anhand einer ID. Der Server antwortet mit den entsprechenden Informationen. Über eine weitere Anfrage (etwa per PUT-Request) lassen sich Daten auf dem Server ändern.

Demo: Arbeiten mit dem neuen Web-Request-Knoten

In der Demonstration zeigt Plamen den neuen Web-Request-Knoten von QF-Test 10. Dieser Knoten wurde speziell für API-Tests entwickelt und erlaubt es, HTTP-Requests direkt innerhalb von QF-Test zu konfigurieren und auszuführen.

Beispielhaft wird ein REST-Service – ein sogenannter Pet Store – getestet.

  1. Über einen POST-Request wird ein neues Haustier („Wolf“) angelegt.
  2. Über einen PUT-Request wird dessen Name geändert.
  3. Mit einem GET-Request wird das geänderte Objekt wieder abgerufen.

Dabei zeigt QF-Test im Protokoll genau, welche Anfragen gesendet und welche Antworten empfangen wurden – inklusive Header, Body, Statuscode und JSON-Inhalt. Ein Statuscode von 200 signalisiert Erfolg.

QF-Test 10 bietet zudem Syntax-Highlighting für JSON- und XML-Inhalte sowie konfigurierbare Header-Felder (z. B. Content-Type und Accept).

Pre- und Post-Request-Handler

Für komplexere Szenarien lassen sich Pre-Request-Handler und Post-Request-Handler definieren. Diese ermöglichen es, Anfragen vor dem Senden zu verändern oder Antworten nachträglich zu prüfen bzw. zu verarbeiten.

Beispielsweise können so:

  • Authentifizierungsdaten gesetzt,
  • Header angepasst oder
  • Rückgabewerte überprüft werden.

Die Ausführung folgt dabei einer festen Struktur: Zuerst laufen globale Handler, anschließend die lokalen innerhalb des jeweiligen Testfalls.

Testfälle, Variablen und Assertions

Plamen demonstriert eine vollständige Testsuite, die mehrere Haustiere mit unterschiedlichen Daten anlegt und validiert. Die Testdaten werden über Datentreiber (Data Driver) eingelesen, sodass ein Testfall mehrfach mit unterschiedlichen Eingaben ausgeführt werden kann.

Die Assertion-API (bzw. rc.check) ermöglicht es, Werte zu überprüfen, ohne den Testlauf bei einem Fehlschlag sofort abzubrechen. Alle Prüfergebnisse werden übersichtlich im Protokoll und im HTML-Report dokumentiert.

QF-Test 10 erlaubt zudem das Kopieren von Protokollabschnitten über neue „Copy“-Buttons, was besonders bei großen JSON-Bodies praktisch ist.

Scripting und Technische Details

Im Hintergrund nutzt QF-Test für Web-Requests die Java-Bibliothek java.net.http aus dem JDK. Dadurch stehen viele vertraute Methoden zur Verfügung, die bei Bedarf über Skripte (z. B. in Groovy) erweitert werden können.

Skripte können:

  • Loops ausführen,
  • Variablen dynamisch setzen,
  • Inhalte aus Responses extrahieren oder
  • eigene Prüfungen durchführen.

Alle zugehörigen Klassen (Request, Response, rc.web, rc.check) sind in der QF-Test-Dokumentation ausführlich beschrieben.

Authentifizierung

QF-Test 10 unterstützt mehrere Authentifizierungsverfahren direkt im Web-Request-Knoten:

  • Basic Authentication
  • Bearer Tokens
  • API Keys

Diese können sowohl über Header als auch über URL-Parameter übermittelt werden. Sensible Daten (z. B. Tokens) lassen sich in den Protokollen ausblenden oder verschlüsselt speichern.

SOAP-Beispiel

Neben REST-APIs können auch SOAP-Services getestet werden. In der Demo wird ein einfacher Rechner-Service („Calculator“) aufgerufen, der zwei Zahlen addiert. Die SOAP-Anfrage enthält den entsprechenden XML-Body sowie den Header SOAPAction. Bei erfolgreicher Ausführung liefert der Server den erwarteten Response mit Status 200.

Proxy-Einstellungen und Zertifikate

QF-Test bietet umfangreiche Optionen für:

  • Proxy-Konfigurationen (HTTP/S),
  • Cookie-Handling und
  • Zertifikatsverwaltung (inklusive Client-Zertifikate).

Standardmäßig akzeptiert QF-Test alle Zertifikate, dies kann aber angepasst werden. Es gibt außerdem eine integrierte Prozedur zum Testen mit Client-Zertifikaten.

Für die Analyse von Netzwerkverkehr empfiehlt Plamen den Einsatz eines MITM-Proxys, der live zeigt, welche Requests tatsächlich über die Leitung gehen.

Zukunftsausblick

Das QF-Test-Team arbeitet daran, das Web-API-Testing weiter auszubauen. Geplant sind unter anderem:

  • Unterstützung von WebSockets,
  • zusätzliche Authentifizierungsverfahren,
  • erweiterte UI-Prüfoptionen für API-Responses,
  • sowie weitere vorkonfigurierte Prozeduren im Paket webapi.

Abschluss

Zum Abschluss bedankt sich Thomas Max bei allen Teilnehmenden. Das QF-Test-Team freut sich über Feedback, Fragen und Verbesserungsvorschläge, die gerne per E-Mail eingereicht werden können.

Wir verwenden Cookies zur anonymisierten Auswertung Ihres Besuchs auf unserer Webseite durch "Matomo". Dafür benötigen wir Ihr Einverständnis, welches für zwölf Monate gilt.

Cookie-Konfiguration

Funktionale Cookies

Wir verwenden funktionale Cookies, um die Basisfunktionalität der Webseite zu gewährleisten.

Performance- und Statistik-Cookies

Wir verwenden Matomo zur Analyse und Optimierung unserer Webseite. Cookies erlauben eine anonyme Erfassung der Informationen und helfen uns, Ihnen einen benutzerfreundlichen Besuch unserer Webseite zu bieten.

Cookie-Details
Bezeichnung Anbieter Gültigkeitsdauer Typ Verwendung
_pk_id Matomo 13 Monate HTTP Enthält eine eindeutige jedoch pseudonymisierte Matomo-interne Besucher-ID zur Erkennung wiederkehrender Besucher.
_pk_ref Matomo 6 Monate HTTP Wird verwendet, um zu tracken, von welcher Website der anonymisierte Benutzer auf die Website gekommen ist.
_pk_ses Matomo 1 Tag HTTP Das Session Cookie von Matomo wird verwendet, um die Seitenanforderungen des Besuchers während der Sitzung zu verfolgen.
_pk_testcookie Matomo Session HTTP Zur Prüfung, ob der Browser des Besuchers Cookies unterstützt.
_pk_cvar Matomo 30 Minuten HTTP Kurzzeit-Cookie für temporäre Besuchsdatenspeicherung.
_pk_hsr Matomo 30 Minuten HTTP Kurzzeit-Cookie für temporäre Besuchsdatenspeicherung.