So erstellen Sie ein Framework für API-Tests

Komponenten eines API-Test-Frameworks

Im Folgenden finden Sie einige gängige Komponenten, die in den meisten API-Frameworks zu finden sind und Unternehmen bei der Implementierung unterstützen.

Testlauf

Ein Testlauf besteht aus der einmaligen Ausführung einer Testsuite, einschließlich aller zugehörigen Testfälle. Der Lauf erzeugt eine Ausgabe, die eine Erfolgsmeldung oder eine Fehlermeldung, Details zu den Testfällen und deren Anzahl, Pass-/Fail-Raten und Laufzeiten enthält. Das Framework muss wahrscheinlich über die Befehlszeile vom Continuous-Integration-Server aus ausgeführt werden, der die Ausgabe verarbeiten muss.

Testumgebung

API-Tests werden auf mindestens einem Server ausgeführt, der in der Regel durch eine URL angegeben wird. Dadurch wird festgelegt, wohin der Test Anfragen sendet. Diese Basis kann je nach Kontext oder Testumgebung variieren. Beispielsweise können test01.companyname.com und test02.companyname.com unterschiedliche Server in unterschiedlichen Testumgebungen darstellen. Serverkennungen können auch als IP-Adresse oder Portnummer anstelle des vollständigen Domänennamens angegeben werden. Sie können aus der Befehlszeile oder möglicherweise aus einer Umgebungsvariablen stammen.

Testfälle

In Ermangelung eines besseren Begriffs ist ein API-Testfall eine Reihe von Befehlen, API-Aufrufen und einem oder mehreren erwarteten Ergebnissen. Diese können als Szenario eingerichtet werden, zum Beispiel das Durchlaufen des Bestellvorgangs, oder als eine Reihe von Aufrufen derselben Funktion. Ein Testfall kann beispielsweise einen einzelnen bekannten Datensatz von Produkten einrichten und dann 50 verschiedene Suchanfragen mit 50 verschiedenen Sätzen von erwarteten Ergebnissen ausführen.

Testsuiten

Eine Testsuite ist eine Datei mit einer Sammlung von Testfällen. Es ist in der Regel nicht erforderlich, alle Tests jedes Mal in allen Teams durchzuführen. So kann ein Programmierer schnell nur die Änderungen für seine API testen.

Testausführungs-Engine

Die Testausführungs-Engine führt die Testfälle aus. Dies kann Teil des Frameworks oder ein externes Skript oder Tool sein, das vom Framework ausgelöst wird. Testfälle können für verschiedene Arten von API-Tests unterschiedliche Formate haben. Beispielsweise erfordern Sicherheitstests und Internationalisierung (i18n) möglicherweise bestimmte Formate, oder Teams bevorzugen bestimmte Tools mit bestimmten Formaten. Wenn Teams ihre bevorzugten Tools einbinden können – sofern das Tool die Standardausgabe erzeugt und mit der Standardeingabe läuft –, kann dies die Akzeptanz des Frameworks erheblich steigern.

Standard-Testdatensätze

Füllen Sie die Datenbank mit bekannten Daten, um vorhersagbare Ergebnisse in den Benutzeroberflächen und Suchergebnissen zu gewährleisten. Diese Einrichtung umfasst in der Regel die Erstellung von Benutzern, Konten, Passwörtern und die Verwaltung geheimer Daten.

Erstellen eines API-Test-Frameworks

Im Folgenden finden Sie einige Optionen zum Zusammenstellen dieser Komponenten zu einem vollständigen Framework.

API-Testfälle sehen aus wie Computercode, der in einem Standardformat gespeichert ist. Ein Testfall kann ein Befehl sein, gefolgt von Parametern und den erwarteten Ergebnissen. Ein Test Runner ist ein Computerprogramm, das die Datei öffnet, den Code durchläuft, den ersten Befehl mit den Parametern ausführt und das Ergebnis mit dem erwarteten Ergebnis vergleicht.

Eine Möglichkeit, diese zu speichern, ist eine Tabelle mit CSV-Dateien. Jede Zeile steht für einen Testfall, und die Spalten stehen für Eingaben, erwartete Ausgaben und Daten. Der Test Runner liest die CSV-Datei und führt jede Zeile als Test aus.

Eine weitere Möglichkeit besteht darin, die Tests zusammen mit den Testsuiten als Tabelle in einem Wiki – einer editierbaren Webseite – zu speichern. Das Framework greift über eine API auf das Wiki zu, findet alle Links und ruft dann den Executor für jeden Link auf der Suiteseite auf. FIT, das Framework for Integrated Tests, ist eine veraltete, aber vollständige Open-Source-Implementierung eines solchen Ansatzes. Allerdings bietet FIT keine umfassende API-Unterstützung. Eine Möglichkeit, API-Unterstützung mit FIT zu schaffen, besteht darin, es um API/JavaScript-Testfunktionen in Java oder C# zu erweitern – oder es in einige bestehende API-Test-Tools zu integrieren.

Die Verwendung bestehender Tools kann eine gute Möglichkeit sein, die Framework-Entwicklung zu beschleunigen. Diese Tools müssen Testfälle als Textdateien in der Versionskontrolle speichern, eine Ausgabe liefern, die das Framework in ein Standardformat konvertieren kann, und die Passwort-/Umgebungseinrichtung unterstützen. Postman ist ein beliebtes Open-Source-Test-Tool für REST APIs und unterstützt JavaScript-Testskripte. Das Exportieren von Postman-Tests in Text und das Importieren in das Framework erfordert einen zusätzlichen Schritt, aber das Unternehmen bietet einen kostenpflichtigen Service an, der dieses Problem löst. SoapUI ist ein weiteres beliebtes Tool mit breiterer Unterstützung für mehr Arten von Web-APIs, während sein kommerzielles Pendant ReadyAPI Unterstützung für die Servicevirtualisierung bietet.

Sobald das Framework vorhanden ist und das System mit kontinuierlicher Integration läuft, stellt sich die Frage, welche Tests geschrieben werden sollen. Ein guter Ausgangspunkt sind die APIs, die sich in der aktiven Entwicklung befinden, um Code zu testen, der aktiv geändert wird. Die Bereiche des Codes mit hoher Fluktuation sind am anfälligsten für Regressionsprobleme. Die API-Tests können sowohl als Spezifikation für die Funktionsweise der Software als auch als Warnsignal für unerwartete Änderungen dienen.

Grenzen herkömmlicher API-Test-Frameworks

Beim klassischen Ansatz für API-Test-Frameworks, der bisher diskutiert wurde, führt jedes Framework eine definierte Sammlung unabhängiger Tests in einer leeren Testumgebung aus. Da jedes Mal ein ordnungsgemäßer Aufbau und Abbau erforderlich ist, können herkömmliche strukturierte Tests folgende Probleme nicht erkennen:

• Speicher und verlängerte Laufzeiten. Wenn Tests immer neu gestartet und isoliert ausgeführt werden, sind Soak-Tests, bei denen das System über einen längeren Zeitraum läuft, um Speicher- oder Leistungsprobleme zu erkennen, in der Regel nicht möglich.
• Mehrere oder unterschiedliche Benutzer. Herkömmliche Test-Frameworks konzentrieren sich in der Regel auf jeweils einen Benutzer oder eine Sitzung, was Lasttests erschwert.
• Repetitive Operationen. Stress- und Volumentests sind schwierig, wenn Tests nur eine ausgewählte Anzahl von Problemen isoliert behandeln.
• Randomisierte Tests und modellbasierte Testautomatisierung. Diese sind schwer durchzuführen, wenn Tests alles auf einen festen Zustand zurücksetzen.

Ein klassisches Beispiel für solche Fehler ist die Registrierung eines Kontos, bei der Sonderzeichen zulässig sind, diese jedoch beim Anmeldevorgang entfernt werden. Beide Softwarekomponenten funktionieren gemäß ihrer Spezifikation. Beide sind Randfälle, die durch API-Tests abgedeckt sind, sodass sie bei der Frontend-GUI-Verifizierung, die den Happy Path testet, wahrscheinlich nicht erkannt werden.

Ein weiteres Beispiel sind versteckte Randbedingungen, die nur mit langen Zeichenfolgen, großen Zahlen oder präzisen Zahlen – mit vielen Stellen vor und nach dem Komma – entdeckt werden können. Diese Beispiele zeigen, warum neben Standardtests in einem API-Framework auch verschiedene Teststrategien wie Last-, Soak-, Stress-/Hochvolumen- und explorative Tests wichtig sind. Sie helfen dabei, Fehler zu finden, die nur auftreten, wenn alle Komponenten über einen längeren Zeitraum zusammenarbeiten.

Alternative Ansätze zu API-Frameworks

Welche dieser zusätzlichen Tests durchgeführt werden, liegt im Ermessen des Qualitätsteams, aber es gibt einige Techniken, die in Betracht gezogen werden sollten:

Setup und Teardown zwischen Tests überspringen

Es ist möglich, eine Framework-Option einzubauen, um das Setup und Teardown zwischen Tests zu überspringen oder keinen neuen Benutzer anzulegen. Eine Testsuite in dieser Situation ist eine lang laufende Kette von Ereignissen, die den realen Nutzungsmustern näherkommt.

Ein Ansatzpunkt ist die Gruppierung unabhängiger Funktionen in einem erweiterten Test – mit Suiten, die sich theoretisch nie berühren sollten. Im E-Commerce kann dies beispielsweise die gemeinsame Ausführung von Such-, Produktdetail- und Checkout-Tests sein. Diese Funktionen beeinträchtigen sich nicht gegenseitig, sondern ahmen die reale Benutzererfahrung besser nach. Länger laufende Sitzungen unterstützen dabei, Speicherprobleme zu beheben und Möglichkeiten für Last- und Stresstests zu schaffen.

Variablen und zufällige Eingaben einführen

Variablen und zufällige Eingaben unterstützen dabei, Randfälle aufzudecken und zufällige Tests komplexer Bedingungen zu unterstützen. Um zu verfolgen, was zu erwarten ist, können Variablen erforderlich sein, da dynamischere Tests mit fest codierten Erwartungen nicht so gut funktionieren. Sobald die Tests Variablen speichern und verfolgen, kann das Framework die Eingaben für diese Variablen zufällig variieren und die erwarteten Ergebnisse anhand einer Formel berechnen.

Verwenden Sie modellbasierte Tests mit Random Walks und Backtracking

Modellbasierte Tests mit Backtracking unterstützen dabei, Fehler in komplexen Bedingungen zu finden und zu diagnostizieren. Speichern Sie den Zustand der Anwendung in einer Datenstruktur und führen Sie dann Random Walks durch – zufällige Pfade durch die Anwendung –, wobei Sie die API-Antwort mit dem erwarteten Zustand vergleichen. Ein Framework kann viele dieser Durchläufe automatisieren, jeden Schritt protokollieren und unerwartete Ergebnisse melden. Führen Sie dann den modellbasierten Test vom letzten Vorgang rückwärts aus, um den kürzesten Weg zum Fehler zu finden und die Schritte des Random Walks effektiv zurückzuverfolgen, was die Fehlersuche erleichtert.

Implementierung eines API-Frameworks

Der einfachste Weg, mit der Implementierung des API-Test-Frameworks zu beginnen, besteht darin, sich bestehende Tests anzusehen und eine Möglichkeit zu finden, diese über die Befehlszeile mit einem Setup vor und einem Teardown nach dem Test aufzurufen.

Speichern Sie jedes Testszenario oder jede Reihe automatisierter Prüfungen als separate Datei in der Versionskontrolle und erstellen Sie eine Testsuite-Datei, die angibt, welche Prüfungen ausgeführt werden sollen. Nehmen Sie die auszuführende Umgebung – wahrscheinlich eine URL – und die Testsuite, die über die Befehlszeile ausgeführt werden soll. Stellen Sie sicher, dass die Ausgabe vom Continuous-Integration-Tool verarbeitet werden kann – TAP (Test Anything Protocol) ist ein Open-Source-Standard – und erstellen Sie Schulungen und Support für das Team.

Suchen Sie dann nach zusätzlichen Problemen, die das Framework nicht findet, und erwägen Sie, das Framework zu erweitern, um diese zu beheben.