SoapUI Tutorial 2026: Webservices testen mit Groovy & Jenkins

Du sollst Webservices testen und dein Team will keine kostenpflichtige Lizenz? Dann ist SoapUI Open Source der Klassiker, an dem du nicht vorbei kommst. Das Tool ist seit 2005 am Markt, deckt SOAP, REST, JMS und JDBC ab und läuft auf Windows, Linux und macOS.

In diesem Tutorial zeige ich dir, wie du SoapUI 5.9.1 (Release September 2025) installierst, deinen ersten WSDL-Import durchführst, Tests datengetrieben gestaltest, Mock-Services für asynchrone Schnittstellen aufsetzt und das Ganze über das Maven-Plugin in eine Jenkins-Pipeline bringst. Alle Code-Snippets sind aus echten Projekten, copy-paste-ready.

Wenn du mit REST-APIs arbeitest, lohnt sich vorher der Blick auf den REST/SOAP/GraphQL-Strategie-Artikel für die Konzept-Übersicht. Wer Postman bevorzugt, findet im Postman-Tutorial das Pendant. Hier geht es um SoapUI als Praxis-Tool.

Was ist SoapUI?

SoapUI ist ein Java-basiertes Werkzeug für funktionale Tests von Webservices. Du importierst die WSDL-Beschreibung deines Services, SoapUI generiert daraus Test-Requests und du baust darauf Testfälle auf. Das Tool kann SOAP-Webservices, REST-APIs, JMS-Queues, JDBC-Datenbanken und AMF-Verbindungen ansprechen.

Die Open-Source-Version heißt schlicht SoapUI, die kommerzielle Variante hieß früher SoapUI Pro und läuft heute als Teil der ReadyAPI-Suite von SmartBear. Beide teilen den gleichen Kern, ReadyAPI bringt zusätzlich Lasttest, Security-Test und Service-Virtualization mit.

Brauchst du eine fundierte Übersicht über REST-, SOAP- und GraphQL-Strategien? Die Konzept-Diskussion gehört in den API-Testing-Pillar-Artikel. Suchst du einen Tool-Vergleich zwischen Postman, Bruno und SoapUI? Den findest du im API-Testing-Tools-Vergleich.

SoapUI installieren und ersten WSDL-Import durchführen

SoapUI Open Source läuft auf Java 8 oder höher. Die aktuelle Version 5.9.1 vom 10. September 2025 (Quelle: Release Notes) bringt Updates für Apache HttpClient und JavaFX mit. Vorgänger waren 5.9.0 (Juli 2025) und 5.8.0 (Dezember 2024).

Auf macOS und Linux installierst du SoapUI am schnellsten über den offiziellen Installer. Auf Windows gibt es zusätzlich den Chocolatey-Paketmanager. Für Container-Setups lohnt sich der Headless-Modus über die testrunner.sh aus dem Distribution-Archiv.

# macOS via Homebrew
brew install --cask soapui

# Linux: Installer-Skript herunterladen
wget https://dl.eviware.com/soapuios/5.9.1/SoapUI-5.9.1-linux-bin.tar.gz
tar xzf SoapUI-5.9.1-linux-bin.tar.gz
cd SoapUI-5.9.1/bin
./soapui.sh

# Headless: WSDL importieren und Testfall ausführen
./testrunner.sh \
  -e https://example.com/services \
  -s "ExampleTestSuite" \
  -r -j -f /tmp/soapui-reports \
  /path/to/example-soapui-project.xml

Nach dem Start klickst du auf File → New SOAP Project, gibst die WSDL-URL deines Services an (Beispiel: https://example.com/api?wsdl) und SoapUI generiert dir die Test-Skelette für jeden Service-Operation. Bei REST-APIs nutzt du New REST Project mit einer Sample-URL und definierst die Endpoints selbst.

Projektstruktur: TestSuite, TestCase, TestStep

SoapUI-Projekte folgen einer dreistufigen Hierarchie. Das Verständnis dieser Struktur entscheidet, ob deine Tests wartbar bleiben oder zum Spaghetti-Code werden.

Eine Regel aus der Praxis: ein TestCase sollte maximal 15 TestSteps haben. Bei mehr lohnt sich das Aufteilen in mehrere TestCases, die du über den Run TestCase-TestStep verkettest. So bleibt jeder Fehler-Report verständlich.

Wichtig ist das Konzept der Properties. Jede Ebene (Project, TestSuite, TestCase) hat einen eigenen Property-Container. Über den Property-Transfer-TestStep zieht SoapUI Werte aus Response-XML (per XPath) in eine Property und verwendet sie im nächsten Request. Damit baust du End-to-End-Flows, in denen die Order-ID aus dem ersten Service den zweiten Service speist.

Wo speicherst du das Projekt? SoapUI verwendet ein einziges XML-File für die komplette Projekt-Hierarchie. Das ist praktisch für den Import in Versionskontrolle (Git, SVN), aber wird bei großen Suites schnell unübersichtlich. Ab etwa 50 TestCases pro Datei empfiehlt sich die Aufteilung in mehrere Projekt-XMLs, die du über das Maven-Plugin nacheinander ausführst.

Datengetriebene Tests mit DataSource und Groovy

Wenn du den gleichen Test mit 50 verschiedenen Eingabewerten durchspielen willst, brauchst du datengetriebene Tests. In der Open-Source-Version geht das über einen Groovy-TestStep mit eigener CSV-Lese-Logik, in ReadyAPI über den nativen DataSource-TestStep mit Excel-, JDBC- oder File-Anbindung.

Das Pattern für die Open-Source-Variante: ein Groovy-Script liest die CSV-Datei zeilenweise, schreibt jede Spalte in eine Property des TestCase, und ein Loop-TestStep iteriert über alle Zeilen. Die folgenden Snippets zeigen das Setup für 200 Kundendatensätze aus einer Datei.

// Groovy-TestStep "DataSource"
// Liest /tmp/kunden.csv zeilenweise und schreibt in TestCase-Properties

def csvFile = new File('/tmp/kunden.csv')
def lines = csvFile.readLines('UTF-8')
def header = lines[0].split(',')
def rowIndex = context.expand('${#TestCase#rowIndex}')?.toInteger() ?: 0

if (rowIndex >= lines.size() - 1) {
    testRunner.gotoStepByName('Loop-End')
    return
}

def values = lines[rowIndex + 1].split(',')
header.eachWithIndex { col, i ->
    testRunner.testCase.setPropertyValue(col, values[i])
    log.info "${col} = ${values[i]}"
}

testRunner.testCase.setPropertyValue('rowIndex', (rowIndex + 1).toString())
testRunner.gotoStepByName('SOAP-Request')

Im SOAP-Request referenzierst du dann die Properties über die SoapUI-Syntax ${#TestCase#kundenname}. Nach dem Request kommt eine Assertion, die das Ergebnis prüft, und ein Conditional-Goto springt zurück zum DataSource-Step. So läufst du alle 200 Datensätze in einem Durchgang durch.

Drei Tipps aus echten Projekten:

• UTF-8 erzwingen: Eine CSV mit Umlauten muss als UTF-8 (ohne BOM) gespeichert sein. Sonst kollabiert der Groovy-Reader bei „Müller" oder „Köln". Beim Export aus Excel: „CSV UTF-8 (durch Trennzeichen getrennt)" wählen, nicht den Standard-CSV-Export.
• Property-Cleanup: Nach dem Loop alle Properties wieder leeren (testRunner.testCase.setPropertyValue('rowIndex', '0')), sonst hat der nächste Lauf alte Werte im Kontext und du jagst Phantom-Bugs.
• Fehler-Logging: Schreibe pro Iteration eine eigene Log-Zeile mit Row-Index und Kunden-ID. Bei einem Fehler in Zeile 137 weißt du sonst nicht, welcher Datensatz die Ursache war.

Mock-Services für asynchrone Schnittstellen

Ein häufiger Pain bei Schnittstellentests: der echte Service ist nicht verfügbar (Wartungsfenster, Drittanbieter, noch nicht entwickelt) oder antwortet asynchron mit Callbacks. SoapUI löst beides über Mock-Services, eine Art Stub-Server, der konfigurierte Responses zurückliefert.

Ein Mock-Service in SoapUI ist eine eingebettete HTTP/Jetty-Instanz. Du definierst pro Operation eine MockResponse, die SoapUI bei einem eingehenden Request zurückgibt. Mit Groovy-Scripts kannst du die Response dynamisch berechnen, Verzögerungen einbauen oder Callbacks auf eine Queue legen.

// MockResponse-Script für asynchrone Bestätigung
// Wartet 2 Sekunden, dann ruft Callback-URL des Clients auf

def requestId = mockRequest.requestContent.find(/(.+?)<\/requestId>/) { _, id -> id }
def callbackUrl = mockRequest.getRequestHeaders().get('Callback-URL')?.first()

// Initiale synchrone Antwort: HTTP 202 Accepted
def response = '''

  ACCEPTED
'''

// Async-Callback: nach 2s POST an Callback-URL
Thread.start {
    sleep(2000)
    def callback = new URL(callbackUrl).openConnection()
    callback.requestMethod = 'POST'
    callback.doOutput = true
    callback.outputStream.write(
      "${requestId}OK".bytes
    )
    log.info "Callback an ${callbackUrl} gesendet (RequestId=${requestId})"
}

return response

Im Testfall startest du den Mock-Service über einen Start MockService-TestStep, deine Client-Applikation ruft den Mock auf statt den echten Service, und nach dem Test stoppt dich ein Stop MockService-Step. So testest du Async-Verhalten deines Clients reproduzierbar in der Pipeline.

Typische Use Cases für Mock-Services aus meiner Beratungspraxis:

Der größte Vorteil: deine Tests werden reproduzierbar. Echte Drittanbieter-Services haben Schwankungen, Wartungsfenster und manchmal Bugs, die zu False-Negative-Builds führen. Ein gut konfigurierter Mock liefert immer das, was du erwartest, und dein Test-Trend wird zuverlässig.

SoapUI mit Jenkins: CI/CD über das Maven-Plugin

Manuelle SoapUI-Klicks in der GUI sind für Smoke-Tests in Ordnung. Wenn du regressionsfähig automatisieren willst, geht das nur über die Headless-Variante in einer CI/CD-Pipeline. Ich nutze dafür das SoapUI-Maven-Plugin in einem Jenkins-Job.

Das Maven-Plugin lädt die SoapUI-Distribution herunter, führt deine Projekt-Datei (XML) headless aus und schreibt JUnit-kompatible Reports nach target/surefire-reports. Jenkins liest die Reports und zeigt Trendgrafiken über Build-Verlauf, Fehlerquoten und Laufzeiten.

<project xmlns="http://maven.apache.org/POM/4.0.0">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.qytera.example</groupId>
  <artifactId>soapui-tests</artifactId>
  <version>1.0.0</version>

  <build>
    <plugins>
      <plugin>
        <groupId>com.smartbear.soapui</groupId>
        <artifactId>soapui-maven-plugin</artifactId>
        <version>5.9.1</version>
        <configuration>
          <projectFile>${project.basedir}/src/test/soapui/example-soapui-project.xml</projectFile>
          <outputFolder>${project.build.directory}/surefire-reports</outputFolder>
          <junitReport>true</junitReport>
          <exportAll>true</exportAll>
          <printReport>true</printReport>
        </configuration>
        <executions>
          <execution>
            <phase>integration-test</phase>
            <goals><goal>test</goal></goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Die zugehörige Jenkins-Pipeline ruft mvn integration-test auf, sammelt die JUnit-Reports und schickt bei rotem Build eine Email-Benachrichtigung. Für Trendgrafiken brauchst du das Jenkins-Plugin JUnit oder xUnit.

pipeline {
  agent any

  tools {
    maven 'Maven-3.9'
    jdk 'OpenJDK-17'
  }

  stages {
    stage('Checkout') {
      steps { checkout scm }
    }

    stage('SoapUI Headless Run') {
      steps {
        sh 'mvn -B integration-test -Dmaven.test.failure.ignore=true'
      }
      post {
        always {
          junit 'target/surefire-reports/*.xml'
        }
      }
    }
  }

  post {
    failure {
      slackSend channel: '#qa-alerts',
                color: 'danger',
                message: "SoapUI-Tests rot: ${env.JOB_NAME} #${env.BUILD_NUMBER}"
    }
  }
}

In einem Projekt aus der Versicherungsbranche haben wir mit diesem Setup über 400 SOAP-Operationen täglich getestet. Build-Zeit unter 12 Minuten, Fehlerquote sichtbar pro Build im Jenkins-Trend.

Drei Praxis-Tipps für die Pipeline:

• JUnit-Plugin statt xUnit: Das Standard-JUnit-Plugin in Jenkins reicht für SoapUI-Reports vollständig aus. Das xUnit-Plugin lohnt sich nur, wenn du Reports anderer Test-Frameworks mischst.
• Build bei rotem Test nicht abbrechen: Mit -Dmaven.test.failure.ignore=true läuft Maven nach einem Fehler weiter und führt alle TestCases aus. Sonst stoppt der erste Fehler die Pipeline und du siehst nicht, welche Operationen ebenfalls betroffen sind.
• Container-Setup für Headless-Runs: Wenn deine Pipeline in Docker läuft, brauchst du ein Image mit Java 17, Maven 3.9 und den SoapUI-Distribution-Files. Eine eigene Dockerfile mit openjdk:17-slim als Base und ein Multi-Stage-Build halten das Image klein.

SoapUI Pro / ReadyAPI: Lohnt sich die Bezahl-Version?

Die kommerzielle Variante heißt heute ReadyAPI (SmartBear). Ein einzelner User zahlt laut SmartBear-Preisliste etwa 829 Euro pro Jahr für die Basis, das Platform-Bundle (Functional + Performance + Security + Virtualization) liegt bei 2.500 bis 3.500 Euro pro Jahr und User (Quelle: smartbear.com/product/ready-api/pricing).

Ein neues Feature aus Mai 2026: ReadyAPI bringt AI Test Generation mit, das laut SmartBear die Test-Erstellung um bis zu 80 Prozent beschleunigen soll (Quelle: SmartBear-Pressemeldung 18.05.2026). Ob das in deinem Projekt den Preisaufschlag rechtfertigt, hängt vom Volumen ab.

Meine Praxis-Empfehlung: für ein 3-bis-5-köpfiges QA-Team mit reinem SOAP-/REST-Test-Fokus reicht die Open-Source-Version. Sobald Lasttest, Security-Scan oder Service-Virtualization dazukommen oder das Team über 8 Personen wächst, lohnt sich ReadyAPI.

Zwei konkrete Entscheidungs-Szenarien aus meiner Beratungspraxis:

Szenario 1: Versicherer mit 6-köpfigem Test-Team. 80 Prozent SOAP-Webservices, 20 Prozent REST. Keine Lasttest-Anforderung (übernimmt ein dediziertes Performance-Team mit JMeter). Hier reicht SoapUI Open Source vollständig. Investition: 0 Euro Lizenzkosten, 3 Tage initiales Setup, danach 2 Personen-Tage pro Sprint für Test-Pflege.

Szenario 2: E-Commerce-Plattform mit 12-köpfigem QA-Team. Funktionaler Test plus Lasttest plus Security-Scan plus Service-Virtualization für 4 Drittanbieter-Schnittstellen. Hier lohnt ReadyAPI: 12 User-Lizenzen zu rund 3.000 Euro pro Jahr ergeben 36.000 Euro jährlich. Eingespart werden vier separate Tools (LoadRunner, Burp Suite, MockServer, eigene Skripte) plus Integrations-Aufwand. ROI nach etwa 8 Monaten.

Wer unsicher ist, startet mit der Open-Source-Version und migriert später. Die Projekt-XMLs sind kompatibel, ein Wechsel kostet maximal einen Sprint.

Fazit

SoapUI ist seit zwei Jahrzehnten das Standardwerkzeug für Webservice-Tests im DACH-Raum. Die Open-Source-Version deckt mit WSDL-Import, TestSuite-Hierarchie, Groovy-Scripting und Maven-Plugin alles ab, was du für eine ordentliche Regression brauchst. ReadyAPI lohnt sich erst, wenn Lasttest, Security-Scan oder AI-Test-Generation echte Anforderungen sind.

Tools wechseln. Qualitätsdenken bleibt.

Wenn du dir nicht sicher bist, ob SoapUI das richtige Tool für dein Projekt ist, schau in den API-Testing-Tools-Vergleich. Postman, Bruno und SoapUI haben jeweils ihre Stärken, und der richtige Mix entscheidet über Geschwindigkeit und Wartbarkeit deiner Test-Suite.

Häufige Fragen zu SoapUI (FAQ)

Was kostet SoapUI?

Die Open-Source-Version SoapUI ist kostenlos. Die kommerzielle Variante ReadyAPI startet bei 829 Euro pro User und Jahr, das Platform-Bundle mit Lasttest, Security und Virtualization liegt bei 2.500 bis 3.500 Euro pro User und Jahr (Stand Mai 2026).

SoapUI vs. Postman: Welches Tool für REST-Tests?

Postman ist die schlankere Lösung für reine REST-API-Tests mit Collection-Sharing über Teams. SoapUI hat seine Stärke bei SOAP-Webservices, Mock-Services und Datadriven-Tests in der Open-Source-Variante. Der direkte Vergleich steht im API-Testing-Tools-Vergleich.

Funktioniert SoapUI auch für REST-APIs?

Ja, SoapUI unterstützt REST-Endpoints über das New REST Project-Menü. Du definierst Method, URL und Header pro Endpoint manuell oder importierst eine OpenAPI-/Swagger-Spezifikation. Für REST-only-Projekte ist allerdings Postman oder Bruno meist die schnellere Wahl.

Wie integriere ich SoapUI in eine CI/CD-Pipeline?

Über das SoapUI-Maven-Plugin (siehe Listing 4) führst du deine Projekt-Datei headless aus und schreibst JUnit-Reports. Jenkins, GitLab CI und GitHub Actions können diese Reports konsumieren und Trendgrafiken anzeigen. Alternativ gibt es die testrunner.sh aus der SoapUI-Distribution für Shell-basierte Pipelines.

Brauche ich Programmierkenntnisse für SoapUI?

Für einfache Smoke-Tests reicht das GUI-Klicken. Sobald du datengetriebene Tests, Property-Transfers oder Mock-Service-Logik brauchst, kommst du an Groovy nicht vorbei. Groovy ist syntaktisch nah an Java und einfach zu erlernen, wenn du Programmiergrundlagen mitbringst. Eine Einführung in saubere Test-Automatisierung findest du in unseren goldenen Regeln für Testautomatisierung.

Was ist neu in ReadyAPI 2026?

Im Mai 2026 hat SmartBear AI Test Generation in ReadyAPI eingeführt. Das Feature soll laut Hersteller die Test-Erstellung um bis zu 80 Prozent beschleunigen, indem es aus OpenAPI-Spezifikationen automatisch Testfälle generiert. Teams können die KI-Funktionalität je nach Projekt-Phase aktivieren oder deaktivieren. Wer eine vertiefte SoapUI-Schulung sucht, findet das Angebot bei den Qytera-Schnittstellentests-Seminaren.