SOAP ist nicht verschwunden. Bankensysteme, Zahlungs-Gateways, Regierungsdienste und ältere Unternehmensplattformen stellen immer noch SOAP-Endpunkte bereit, und jemand muss sie testen. Wenn Sie Ihre Karriere mit REST und JSON verbracht haben, kann sich ein SOAP-Dienst fremd anfühlen. Das Protokoll ist strenger, die Nutzdaten sind XML und der Vertrag befindet sich in einer separaten WSDL-Datei.
Die gute Nachricht ist, dass das Testen einer SOAP-API online nicht schwer ist, sobald man versteht, was sie tatsächlich von einem verlangt. Dieser Leitfaden erklärt, wie sich SOAP-Tests von REST-Tests unterscheiden, führt durch eine echte Anfrage und behandelt die Online-Tools, die SOAP problemlos handhaben.
Warum sich SOAP-Tests unterscheiden
REST ist ein Stil. SOAP ist ein Protokoll mit Regeln. Diese Unterscheidung prägt alles, wie Sie es testen.
Eine SOAP-Nachricht ist immer ein XML-Dokument, das in einem Umschlag (Envelope) verpackt ist. Der Umschlag enthält einen Header für Metadaten wie Authentifizierung oder Routing und einen Body, der die eigentliche Operation und ihre Parameter enthält. Man kann nicht einfach ein beliebiges JSON-Objekt senden. Die Struktur ist zwingend erforderlich, und ein fehlerhafter Umschlag wird abgelehnt, bevor Ihre Logik überhaupt ausgeführt wird. SOAP wird auch fast immer über HTTP POST übertragen, selbst für Operationen, die nur Daten lesen, und es erwartet einen spezifischen Content-Type, normalerweise text/xml oder application/soap+xml.
Der größte praktische Unterschied ist die WSDL. Eine WSDL-Datei (Web Services Description Language) ist ein maschinenlesbarer Vertrag, der jede vom Dienst angebotene Operation, die genaue Form jeder Anfrage und Antwort sowie die Endpunktadresse auflistet. REST liefert selten etwas so Strenges. Wenn Sie SOAP testen, ist die WSDL Ihre Karte. Ein guter Online-SOAP-Tester liest die WSDL und generiert Anfragetemplates für Sie, sodass Sie die Umschläge nicht von Hand aus dem Gedächtnis eingeben müssen. Wenn Sie ein umfassenderes Bild des Vertrags wünschen, erklären unsere Hinweise zum API-Vertragstesting, warum ein strenger Vertrag ein Vorteil ist.
Wie eine SOAP-Anfrage tatsächlich aussieht
Hier ist eine realistische SOAP-Anfrage an einen Währungsumrechnungsdienst. Beachten Sie den Umschlag, die Namespace-Deklarationen und die im Body verschachtelte Operation.
POST /CurrencyService.asmx HTTP/1.1
Host: rates.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "https://rates.example.com/ConvertAmount"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Header>
<cur:AuthToken>e9f2a1c7-4b8d-4c2a-9f31-7d6e5a4b3c21</cur:AuthToken>
</soap:Header>
<soap:Body>
<cur:ConvertAmount>
<cur:FromCurrency>USD</cur:FromCurrency>
<cur:ToCurrency>EUR</cur:ToCurrency>
<cur:Amount>250.00</cur:Amount>
</cur:ConvertAmount>
</soap:Body>
</soap:Envelope>
Die Antwort kommt auf die gleiche Weise verpackt zurück:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Body>
<cur:ConvertAmountResponse>
<cur:ConvertAmountResult>231.45</cur:ConvertAmountResult>
</cur:ConvertAmountResponse>
</soap:Body>
</soap:Envelope>
Zwei Details bringen Leute ins Stolpern. Der HTTP-Header SOAPAction wird von vielen Diensten benötigt und muss mit der Operation übereinstimmen, sonst erhalten Sie einen Fehler (Fault). Und wenn etwas fehlschlägt, gibt SOAP keinen HTTP 400 mit einer sauberen Nachricht zurück. Es gibt HTTP 200 mit einem <soap:Fault>-Element im Body zurück. Ihr Test muss den Body parsen, um zu wissen, ob der Aufruf wirklich erfolgreich war. Das Überprüfen des Statuscodes allein reicht nicht aus, weshalb strukturierte API-Assertions hier wichtiger sind als bei REST.
Online-Tools zum Testen von SOAP-APIs
Apidog
Apidog verarbeitet SOAP zusammen mit REST, GraphQL und WebSocket an einem Ort. Sie importieren eine WSDL, und es generiert die Anfragestruktur, sodass Sie keine Umschläge von Hand erstellen müssen. Sie können Assertions zu XML-Elementen hinzufügen, Anfragen zu einem Szenario verketten und das Ganze als automatisierte Suite ausführen. Da es auch APIs entwirft und mockt, können Sie eine SOAP-Antwort mocken, bevor der eigentliche Dienst bereit ist. Laden Sie Apidog herunter, um SOAP-Dienste im kostenlosen Tarif zu testen.
SoapUI
SoapUI ist das ursprüngliche SOAP-Testtool und immer noch das umfassendste. Richten Sie es auf eine WSDL aus, und es erstellt ein Projekt mit jeder Operation. Die Open-Source-Edition ist kostenlos und leistungsstark für funktionale und datengesteuerte SOAP-Tests. Es ist eine schwerere Java-Desktop-Anwendung, und die ausgefeiltesten Berichtsfunktionen befinden sich im kostenpflichtigen ReadyAPI-Tier. Für einen genaueren Blick, siehe was SoapUI ist und wie es funktioniert.
Postman
Postman kann SOAP-Anfragen senden. Sie setzen den Body auf rohes XML, fügen die Header Content-Type und SOAPAction manuell hinzu und fügen Ihren Umschlag ein. Es funktioniert, aber Postman parst keine WSDL, daher erstellen Sie die Umschläge selbst. Es ist in Ordnung für eine einmalige Überprüfung und weniger komfortabel für eine große SOAP-Oberfläche.
Browserbasierte SOAP-Tester
Mehrere leichte Web-Tools ermöglichen es Ihnen, eine WSDL-URL einzufügen und Anfragen von einem Browser-Tab aus zu senden. Sie sind praktisch für eine schnelle Überprüfung, ohne dass etwas installiert werden muss. Die Grenzen zeigen sich schnell: geringe Assertionsunterstützung, wenig oder keine Automatisierung und keine Möglichkeit, eine echte Testsuite zu organisieren. Verwenden Sie sie, um zu bestätigen, dass ein Endpunkt aktiv ist, und nicht, um eine Regressionstest-Suite zu erstellen.
Ein schneller SOAP-Test-Workflow
- WSDL abrufen. Die meisten SOAP-Dienste stellen sie bereit, indem sie
?wsdlan die Endpunkt-URL anhängen. Öffnen Sie sie und vergewissern Sie sich, dass sie geladen wird. - WSDL in Ihr Tool importieren. Apidog und SoapUI generieren daraus Anfragetemplates. Dies ist die größte Zeitersparnis.
- Operationsparameter ausfüllen. Verwenden Sie echte Werte. Testen Sie eine Währungsumrechnung mit einem tatsächlichen Betrag und gültigen Währungscodes.
- Header setzen. Bestätigen Sie
Content-Typeund, falls erforderlich,SOAPAction. Ein fehlenderSOAPActionist die häufigste Ursache für einen unerklärlichen Fehler. - Senden und den Body prüfen. Hören Sie nicht beim HTTP-Status auf. Öffnen Sie den Response-Body und suchen Sie nach
<soap:Fault>. - Assertions hinzufügen. Stellen Sie sicher, dass ein bestimmtes Element existiert und den erwarteten Wert enthält. Verketten Sie dann einen Folgeaufruf, wenn Ihr Workflow dies erfordert.
Für die Organisation dieser in einem wartbaren Set gilt unser Leitfaden zum Erstellen von Testsuiten für die API-Automatisierung direkt für die SOAP-Arbeit.
SOAP-Fehler (Faults) und wie man sie überprüft
Ein SOAP-Fehler (Fault) ist die Fehlerstruktur des Protokolls. Er enthält einen faultcode, einen faultstring und manchmal ein detail-Element. Da er mit einem HTTP 200 ankommt, wird ein Test, der nur den Status prüft, einen fehlgeschlagenen Aufruf als erfolgreich bewerten. Das ist ein stiller, gefährlicher Fehlalarm (False Positive).
Schreiben Sie Ihre SOAP-Assertions so, dass sie in den Body schauen. Stellen Sie sicher, dass auf einem Erfolgspfad kein <soap:Fault>-Element vorhanden ist. Auf einem absichtlichen Fehlerpfad stellen Sie das Gegenteil fest, dass der Fehler auftritt und der faultcode dem entspricht, was Sie erwarten. Das Testen der Fehlerfälle ist genauso wichtig wie der "Happy Path", da SOAP-Dienste Geschäftsregeln, wie eine abgelehnte Transaktion, oft als Fehler (Faults) und nicht als Daten kodieren. Die W3C SOAP-Fehlerdokumentation beschreibt die Struktur, falls Sie die formalen Details benötigen.
WS-Security fügt eine weitere Ebene hinzu. Viele Unternehmens-SOAP-Dienste erwarten einen signierten oder Token-tragenden Sicherheits-Header. Wenn Ihre Anfragen mit einem Authentifizierungsfehler fehlschlagen, wird die WSDL oder die Dienst-Dokumentation angeben, welches Sicherheitsprofil verwendet wird. Tools wie SoapUI und Apidog ermöglichen es Ihnen, diese Header zu konfigurieren, anstatt das XML von Hand zu erstellen.
Eine WSDL lesen, ohne sich zu verirren
Eine WSDL-Datei sieht einschüchternd aus, wenn Sie sie zum ersten Mal öffnen. Es ist langes, tief verschachteltes XML, und das meiste davon ist Maschinerie (Machine Plumbing). Sie müssen nicht alles lesen. Vier Teile enthalten die Informationen, die Sie tatsächlich benötigen.
Der types-Abschnitt definiert die Datenstrukturen, normalerweise als XML-Schema, hier erfahren Sie also die genaue Form und die Einschränkungen jedes Parameters. Die message-Elemente beschreiben die Eingabe und Ausgabe für jede Operation. Der portType listet die Operationen selbst auf, also die Aufrufe, die Sie tätigen können. Die Abschnitte service und binding geben die konkrete Endpunktadresse und die Transportdetails an. Wenn Sie eine WSDL in ein Tool importieren, liest es alle vier und wandelt sie in bearbeitungsfertige Anfragen um, weshalb der Import immer besser ist als das manuelle Eintippen.
Ein wissenswertes Detail: Eine WSDL kann sich über mehrere Dateien mithilfe von import-Anweisungen aufteilen, wobei oft Schemas von separaten Speicherorten geladen werden. Wenn Ihr Tool einen fehlenden Typ meldet, konnte eine referenzierte Datei wahrscheinlich nicht aufgelöst werden. Stellen Sie sicher, dass jede importierte URL von dem Ort aus erreichbar ist, an dem Ihr Tool läuft. Diese Art von Vertragsabhängigkeit ist genau der Grund, warum Teams die WSDL als versioniertes Artefakt behandeln und nicht als etwas, das nur auf einem Server existiert.
Datengesteuerte SOAP-Tests
SOAP-Dienste enthalten oft strenge Geschäftsregeln, und eine einzelne "Happy-Path"-Anfrage beweist selten viel. Ein Währungsdienst sollte mit gültigen Paaren, einer nicht unterstützten Währung, einem Nullbetrag und einem negativen Betrag getestet werden. Ein Zahlungsdienst sollte mit einer genehmigten Karte, einer abgelehnten Karte und einer abgelaufenen Karte getestet werden. Jedes davon von Hand einzugeben ist langsam und fehleranfällig.
Datengesteuertes Testen löst dieses Problem. Sie schreiben die Anfrage einmal mit Platzhaltern und füttern sie dann mit einer Tabelle von Eingabezeilen und erwarteten Ergebnissen. Das Tool führt die Anfrage für jede Zeile aus und prüft jedes Ergebnis. SoapUI unterstützt dieses Muster seit Jahren, und Apidog unterstützt es durch seinen Szenario-Runner. Der Lohn ist eine echte Abdeckung der Grenzfälle, die SOAP-Dienste dazu neigen, als Fehler zu kodieren. Für das umfassendere Muster erklärt unser Leitfaden zum datengesteuerten API-Testen mit CSV und JSON, wie die Eingabedaten zu strukturieren sind, und er gilt für SOAP genauso wie für REST.
Häufig gestellte Fragen
Was ist der Unterschied zwischen SOAP- und REST-Tests?
SOAP-Tests erfolgen gegen ein strenges XML-Protokoll mit einem WSDL-Vertrag, obligatorischen Umschlägen und Fehlern, die in einem HTTP 200 Body zurückgegeben werden. REST-Tests befassen sich normalerweise mit JSON, lockereren Konventionen und aussagekräftigen HTTP-Statuscodes. Ein SOAP-Test muss den Response-Body parsen, um den Erfolg zu bestätigen; ein REST-Test kann oft dem Statuscode vertrauen.
Benötige ich die WSDL, um eine SOAP-API zu testen?
Sie können eine SOAP-Anfrage auch ohne senden, wenn Sie die genaue Umschlagstruktur bereits kennen. Die WSDL erleichtert das Testen jedoch erheblich, da Tools daraus korrekte Anfragetemplates generieren. Die meisten Dienste stellen die WSDL bereit, indem sie ?wsdl an die Endpunkt-URL anhängen. Beginnen Sie immer dort.
Warum gibt meine SOAP-Anfrage einen Fehler (Fault) zurück, obwohl der Status 200 ist?
SOAP meldet Fehler als <soap:Fault>-Element innerhalb des Bodys, nicht als HTTP-Fehlercode, daher ist ein 200er-Status mit einem Fehler normal. Die üblichen Ursachen sind ein fehlender oder falscher SOAPAction-Header, ein fehlerhafter Umschlag, ein Namespace-Mismatch oder eine fehlgeschlagene Sicherheitsprüfung. Lesen Sie den faultstring für den spezifischen Grund.
Kann ich SOAP-APIs online kostenlos testen?
Ja. Apidog unterstützt SOAP in seinem kostenlosen Tarif und importiert WSDL-Dateien, und die Open-Source-Edition von SoapUI ist für SOAP konzipiert. Leichte Browser-Tester existieren auch für schnelle Überprüfungen, obwohl ihnen echte Assertions- und Automatisierungsunterstützung fehlt.
Wie automatisiere ich SOAP-API-Tests?
Importieren Sie die WSDL, erstellen Sie ein Szenario, das die Operationen der Reihe nach verknüpft, fügen Sie Assertions für Antwortelemente und für die Abwesenheit von Fehlern hinzu und führen Sie es dann über den Runner eines Tools oder in Ihrer CI-Pipeline aus. SoapUI und Apidog unterstützen beide geplante und Pipeline-gesteuerte SOAP-Suiten, sodass ein SOAP-Regressionstest in den gleichen Automatisierungsfluss passt wie REST.