ReadyAPI zu Apidog migrieren

TL;DR

Die Migration von ReadyAPI zu Apidog ist für REST-lastige Test-Suites unkompliziert. Exportieren Sie Ihr ReadyAPI-Projekt, konvertieren Sie, was Sie können, über den OpenAPI-Import und erstellen Sie Groovy-Skripte manuell in JavaScript neu. SOAP-Testfälle erfordern die meiste manuelle Arbeit. Planen Sie eine phasenweise Migration, um eine durchgehende Testabdeckung zu gewährleisten.

Einleitung

Die Migration von API-Testinfrastrukturen ist eine jener Aufgaben, die zunächst einfach klingen, bis man damit beginnt. ReadyAPI-Projekte können jahrelang angesammelte Testfälle, benutzerdefinierte Groovy-Skripte, Datendateien, Umgebungen und komplexe Test-Suite-Strukturen enthalten. All dies in Apidog zu integrieren, erfordert ein Verständnis dafür, was automatisch übertragen wird, was manuell konvertiert werden muss und was Sie möglicherweise zurücklassen möchten.

Dieser Leitfaden führt Sie Schritt für Schritt durch den Migrationsprozess. Er behandelt den Export Ihres ReadyAPI-Projekts, die Analyse Ihrer bestehenden Elemente, den Import in Apidog, die Handhabung der Groovy-zu-JavaScript-Konvertierung, die Einrichtung von CI/CD und die Verwaltung der Übergangsphase, in der beide Tools parallel laufen.

Schritt 1: Überprüfen Sie Ihr ReadyAPI-Projekt, bevor Sie beginnen

Bevor Sie etwas exportieren, nehmen Sie sich Zeit, um zu verstehen, was sich in Ihrem aktuellen ReadyAPI-Projekt befindet. Dieses Audit bestimmt, wie lange die Migration dauert und worauf Sie Ihre Anstrengungen konzentrieren.

Öffnen Sie Ihr ReadyAPI-Projekt und beantworten Sie diese Fragen:

Wie viele Test-Suites, Testfälle und Testschritte haben Sie? Öffnen Sie das Navigator-Panel und zählen Sie. Ein Projekt mit 50 Testfällen migriert in Stunden. Ein Projekt mit 500 Testfällen dauert Tage.

Welcher Prozentsatz sind REST- im Vergleich zu SOAP-Testfällen? REST-Testfälle lassen sich wesentlich sauberer migrieren. SOAP-Testfälle erfordern mehr manuelle Arbeit, insbesondere wenn sie WS-Security-Richtlinien oder komplexe Assertions verwenden.

Wie viel Groovy-Skripting ist in Ihren Testfällen enthalten? Klicken Sie sich durch Ihre Testfälle und suchen Sie nach Skriptschritten. Zählen Sie, wie viele Testfälle eine benutzerdefinierte Groovy-Logik enthalten. Jedes Groovy-Skript erfordert eine manuelle Konvertierung nach JavaScript.

Verwenden Sie datengesteuerte Tests mit DataSource-Schritten? Apidog unterstützt datengesteuertes Testen mit CSV- und JSON-Datendateien, aber die Einrichtung unterscheidet sich vom DataSource/DataSink-Muster von ReadyAPI.

Nutzen Sie Properties oder Property Transfer-Schritte intensiv? Diese Muster funktionieren in Apidog anders. Stattdessen verwenden Sie Variablen und Umgebungsvariablen.

Führen Sie Lasttests über LoadUI Pro durch? Die Integration von LoadUI Pro wird nicht auf Apidog übertragen. Sie müssen k6 oder ein anderes Lasttest-Tool separat für diese Szenarien einrichten.

Dokumentieren Sie Ihre Ergebnisse. Eine Tabelle mit Testfallname, Typ (REST/SOAP), hat-Groovy (ja/nein) und Komplexität (einfach/mittel/komplex) gibt Ihnen eine Migrationsschätzung, bevor Sie beginnen.

Schritt 2: Exportieren Sie Ihr ReadyAPI-Projekt

ReadyAPI speichert Projekte als XML-Dateien. So exportieren Sie ein Projekt zur Analyse:

1. Öffnen Sie ReadyAPI und Ihr Projekt.
2. Gehen Sie zu Datei > Speichern unter, um das Projekt als eigenständige XML-Datei zu speichern.
3. Speichern Sie alle externen Datendateien (CSV, Excel, XML-Testdaten), auf die Ihre Tests verweisen.
4. Notieren Sie alle Umgebungskonfigurationen, die Sie unter dem Abschnitt "Umgebungen" eingerichtet haben.

Die Projekt-XML enthält alle Test-Suites, Testfälle, Testschritte, Skripte und Konfigurationen. Sie ist eine vollständige Darstellung Ihres Testprojekts.

Schritt 3: Extrahieren Sie Ihre API-Definitionen

Der sauberste Migrationspfad für REST-APIs führt über eine OpenAPI-Spezifikation, nicht direkt aus der ReadyAPI-Projekt-XML.

Option A: Export aus ReadyAPI. Wenn Sie einen REST-Dienst in ReadyAPI haben, klicken Sie mit der rechten Maustaste im Navigator darauf und suchen Sie nach einer Option zum Exportieren oder Generieren der API-Definition. ReadyAPI kann Swagger/OpenAPI-Spezifikationen aus Dienstdefinitionen exportieren.

Option B: Verwenden Sie die OpenAPI-Spezifikation Ihres Backends. Wenn Ihr Backend-Dienst bereits eine OpenAPI-Spezifikation (unter /openapi.json oder ähnlich) bereitstellt, laden Sie diese direkt herunter. Dies liefert Ihnen die genaueste und aktuellste Definition.

Option C: Manuell extrahieren. Für APIs ohne eine bestehende Spezifikation verwenden Sie Ihre ReadyAPI-REST-Anfragen als Quelle. Notieren Sie die Endpunkte, Anfragekörper, Header und Antwortstrukturen. Diese werden Sie in Apidog neu erstellen.

Schritt 4: Import in Apidog

Sobald Ihre OpenAPI-Spezifikation bereit ist, importieren Sie sie in Apidog.

1. Öffnen Sie Apidog und erstellen Sie ein neues Projekt.
2. Gehen Sie zu APIs > Import und wählen Sie Ihr Format (OpenAPI 3.0, Swagger 2.0 usw.).
3. Laden Sie die Spezifikationsdatei hoch oder fügen Sie die URL ein.
4. Apidog parst die Spezifikation und erstellt API-Definitionen für alle Endpunkte.

Nach dem Import haben Sie eine strukturierte API-Definition mit allen Endpunkten, Parametern, Anfragekörpern und Antwortschemata. Dies ist die Grundlage für Ihre Testfälle.

Wenn Sie bestehende Postman-Sammlungen haben (vielleicht von einem früheren Tool migriert), importiert Apidog diese ebenfalls über Datei > Import > Postman.

Schritt 5: Testfälle für REST-Endpunkte neu erstellen

Für REST-Testfälle ist der Migrationsprozess wie folgt:

1. Öffnen Sie einen ReadyAPI REST-Testfall.
2. Identifizieren Sie die Anfragen, Assertions und alle Datenquellen, die er verwendet.
3. Erstellen Sie einen entsprechenden Testfall in Apidog, indem Sie den API-Endpunkt auswählen und Testschritte hinzufügen.

Assertions werden wie folgt übersetzt:

• Die "enthält"-Assertion (Body enthält String) wird zu einer JavaScript-Assertion: pm.test('contains value', () => { pm.expect(pm.response.text()).to.include('expected string'); });
• Statuscode-Assertion: pm.test('status 200', () => { pm.response.to.have.status(200); });
• JSONPath-Assertions: pm.test('field value', () => { pm.expect(pm.response.json().fieldName).to.equal('expected'); });

Für einfache GET- und POST-Tests ohne Groovy ist diese Migration schnell. Ein einfacher Testfall mit 5 bis 10 Assertions kann in 15 bis 30 Minuten neu erstellt werden.

Schritt 6: Groovy-Skripte nach JavaScript konvertieren

Dies ist der arbeitsintensivste Teil der Migration für Projekte mit umfangreichem benutzerdefiniertem Skripting.

Gängige Groovy-Muster und ihre JavaScript-Äquivalente:

Lesen eines Antwortwerts:

// Groovy (ReadyAPI)
def response = context.expand('${TestStep#Response}')
def json = new groovy.json.JsonSlurper().parseText(response)
def value = json.fieldName

// JavaScript (Apidog)
const response = pm.response.json();
const value = response.fieldName;

Festlegen einer Variable:

// Groovy
testRunner.testCase.setPropertyValue('myVariable', someValue)

// JavaScript
pm.variables.set('myVariable', someValue);

Bedingte Assertions:

// Groovy
if (statusCode == 200) {
  assert responseBody.contains("success")
}

// JavaScript
if (pm.response.code === 200) {
  pm.test('response contains success', () => {
    pm.expect(pm.response.text()).to.include('success');
  });
}

Datumsmanipulation:

// Groovy
def now = new Date()
def formatted = now.format('yyyy-MM-dd')

// JavaScript
const now = new Date();
const formatted = now.toISOString().split('T')[0];

Bei komplexen Groovy-Skripten mit Java-Bibliotheksimporten oder komplizierter Logik erfordert die Konvertierung eine sorgfältige Analyse. Lesen Sie jedes Skript, verstehen Sie, was es tut, und schreiben Sie äquivalenten JavaScript-Code. Versuchen Sie keine automatische Übersetzung – die Semantik ist ähnlich genug, um Sie zu täuschen, aber unterschiedlich genug, um versteckte Fehler zu verursachen.

Schritt 7: SOAP-Testfälle behandeln

SOAP-Testfälle sind der anspruchsvollste Teil jeder ReadyAPI-Migration. Apidog verfügt nicht über dedizierte SOAP-Tools, daher erfordern diese einen anderen Ansatz.

Für SOAP-Dienste, die auch eine REST-Schnittstelle bereitstellen (was zunehmend üblich ist), migrieren Sie die Tests, um die REST-Endpunkte zu verwenden und die SOAP-Schicht zu eliminieren.

Für SOAP-Dienste ohne REST-Alternative haben Sie zwei Optionen:

ReadyAPI nur für SOAP beibehalten. Führen Sie ReadyAPI parallel für SOAP-Testfälle aus und verwenden Sie Apidog für REST. Dies ist ein praktischer Mittelweg, der die SOAP-Abdeckung aufrechterhält, ohne die REST-Migration zu blockieren.

SoapUI Open Source verwenden. SoapUI Open Source ist kostenlos und handhabt SOAP-Tests. Es kann nicht alle Funktionen von ReadyAPI ersetzen, deckt aber grundlegende funktionale SOAP-Tests ohne Lizenzkosten ab.

Überstürzen Sie die SOAP-Migration nicht. Insbesondere WS-Security-Testfälle bergen ein erhebliches Risiko, wenn ihre Assertions nicht sorgfältig reproduziert werden.

Schritt 8: Umgebungen und Variablen einrichten

Die Umgebungsfunktion von ReadyAPI entspricht dem Umgebungssystem von Apidog. Für jede von Ihnen konfigurierte ReadyAPI-Umgebung:

1. Erstellen Sie eine entsprechende Umgebung in Apidog (Einstellungen > Umgebungen).
2. Fügen Sie dieselben Variablen hinzu: Basis-URLs, Authentifizierungstoken, gemeinsame Header usw.
3. Überprüfen Sie, ob Testfälle Variablen mit der korrekten Apidog-Syntax referenzieren: {{variableName}} in URL-Feldern und Anfragekörpern.

Schritt 9: CI/CD konfigurieren

Die CI-Einrichtung von ReadyAPI beinhaltet typischerweise den testrunner-Befehl auf Build-Agenten. Apidog verwendet einen anderen Ansatz.

Installieren Sie die Apidog CLI auf Ihrem CI-Agenten:

npm install -g apidog-cli

Führen Sie eine Test-Sammlung aus:

apidog run "path/to/collection.json" -e "environment-id"

Für GitHub Actions könnte ein Workflow-Schritt so aussehen:

- name: Run API tests
  run: apidog run collection.json --environment staging

Fügen Sie für Jenkins einen Shell-Schritt zu Ihrer Pipeline hinzu, der die Apidog CLI aufruft. Keine ReadyAPI-Installation auf dem Build-Agenten erforderlich.

Aktualisieren Sie Ihre CI-Konfigurationsdateien, um den neuen Befehl zu verwenden. Entfernen Sie ReadyAPI-testrunner-Referenzen, sobald die Apidog-Läufe korrekt validiert wurden.

Schritt 10: Beide Tools während der Übergangsphase parallel betreiben

Stellen Sie nicht an einem einzigen Tag von ReadyAPI auf Apidog um. Betreiben Sie beide Tools über mindestens einen Release-Zyklus hinweg parallel.

Während der Parallelbetriebszeit:

• Führen Sie ReadyAPI-Tests in CI als maßgebliche Testfreigabe aus.
• Führen Sie Apidog-Tests parallel aus und vergleichen Sie die Ergebnisse.
• Untersuchen Sie alle Fehler in Apidog, die in ReadyAPI nicht auftreten.
• Fügen Sie neue Testfälle schrittweise nur in Apidog hinzu.

Sobald Sie sicher sind, dass Apidog die gleichen Fehler wie ReadyAPI erkennt, entfernen Sie ReadyAPI aus der CI-Pipeline. Halten Sie die ReadyAPI-Installation für einige Monate als Fallback bereit.

FAQ

Wie lange dauert eine ReadyAPI- zu Apidog-Migration typischerweise?Ein reines REST-Projekt mit minimalem Groovy-Skripting kann in ein bis drei Tagen migriert werden. Ein großes Projekt mit umfangreichen Groovy-Skripten, SOAP-Testfällen und komplexen Teststrukturen kann zwei bis sechs Wochen dauern. Das Audit in Schritt 1 gibt Ihnen die klarste Schätzung, bevor Sie sich festlegen.

Werden meine ReadyAPI-Testdatendateien in Apidog funktionieren?CSV-Datendateien funktionieren mit der datengesteuerten Testfunktion von Apidog. Das Importformat ist ähnlich. Excel-Dateien müssen zuerst in CSV konvertiert werden. XML-Datendateien müssen umstrukturiert werden, je nachdem, wie sie in ReadyAPI verwendet wurden.

Kann ich ReadyAPI und Apidog während der Migration in derselben CI-Pipeline ausführen?Ja, und dies ist der empfohlene Ansatz. Fügen Sie den Apidog CLI-Schritt Ihrer bestehenden Pipeline neben dem ReadyAPI testrunner-Schritt hinzu. Vergleichen Sie die Ergebnisse laufend während der Übergangszeit.

Muss ich Umgebungen manuell neu erstellen oder gibt es einen automatisierten Weg?Die Umgebungskonfiguration muss in Apidog manuell neu erstellt werden. Es gibt keinen automatisierten Import von ReadyAPI-Umgebungseinstellungen. Halten Sie Ihre ReadyAPI-Umgebungen in einem Fenster geöffnet, während Sie sie in Apidog neu erstellen.

Was geschieht mit ReadyAPI-Tests, die kein REST-Äquivalent haben?Für reine SOAP-Testfälle ohne REST-Alternative sind die praktischen Optionen: ReadyAPI (möglicherweise mit weniger Lizenzen) für diese spezifischen Tests beizubehalten, zu SoapUI Open Source zu migrieren oder eine Testlücke zu akzeptieren, wenn die Dienste veraltet und risikoarm sind.

Unterstützt Apidog dieselben Assertion-Typen wie ReadyAPI?Apidog unterstützt JavaScript-Assertions, die dieselben logischen Bedingungen wie die integrierten Assertion-Typen von ReadyAPI ausdrücken können. Die Syntax ist unterschiedlich, aber die Funktionen sind für REST-Tests vergleichbar. Einige ReadyAPI-spezifische Assertion-Typen (SOAP Fault, WS-Security) haben kein Apidog-Äquivalent.

Die Migration von ReadyAPI zu Apidog ist ein bedeutsames Projekt, keine Nachmittagsaufgabe. Teams, die sorgfältig planen, mit einem klaren Audit beginnen, zuerst REST-Testfälle migrieren und beide Tools während der Übergangsphase parallel betreiben, schließen sie ohne Abdeckungslücken oder Testregressionen ab.