Viele verwenden SoapUI, um sowohl die API selbst als auch Anwendungen zu testen, die auf die API zugreifen. Ein ziemlich flexibles Tool, mit dem beispielsweise eine
Swagger-API-Datei exportiert und darauf basierend ein Mock-Service generiert werden kann.
Vor nicht allzu langer Zeit hatte ich in unserer Firma ein ähnliches Problem, aber mit nicht trivialen Bedingungen. Anfangsdaten: Es ist erforderlich, eine Serveranwendung zu testen, die eine Aufgabe als Eingabe empfängt. Während der Ausführung bezieht sie sich auf die API. Jede nachfolgende Anforderung hängt von der API-Antwort ab. Die Logik ist in die Anwendung eingebettet. Das heißt, eine Art Black Box, in der Sie viele Exits aus dem Skript testen müssen, wenn es nur einen Eingang zum Skript gibt.
Im Folgenden schlage ich ein Beispiel für eine Lösung vor, die es ermöglicht, sie einfach in die Regressionsinfrastruktur zu integrieren und einen Skalierungsspielraum zu haben, um die Abdeckung der verschiedenen Szenarien und deren Komplexität zu erhöhen.
Erstellen Sie zunächst einen Mock-Service in SoapUI. Dies geschieht mit wenigen Klicks:
Fahren wir nun mit dem Erstellen von Stubs für Abfragen fort. Da die Aufgabe nur einen Eintrag im Skript enthält, haben wir folgende Optionen:
- Verwenden Sie die Kennung des Skripts und übergeben Sie sie in jeder Anforderung. Bestimmen Sie in jedem Stub die Antwort in Abhängigkeit von dieser Kennung.
- Geben Sie im Voraus eine Liste mit Antworten für jeden Stub an und speichern Sie diese in globalen Variablen, bevor Sie den Test ausführen.
Die erste Option kann verwendet werden, wenn für mehrere Anforderungen gleichzeitig eine Antwort vom Stub empfangen werden muss. Die Implementierung erfordert, dass die Clientanwendung in der Lage ist, in jeder API-Anforderung eine bestimmte Kennung zu übertragen. In unserem Fall war dies praktisch unmöglich, und das gleichzeitige Testen mehrerer Szenarien war nicht erforderlich, sodass die zweite Option gewählt wurde.
Um eine Liste von Stub-Antworten zuzuweisen, führen wir vor dem Ausführen des Tests die folgende Abfrage aus:
Post: http:
Im Mock-Service fügen wir die Anforderungsverarbeitung "SetScenario" hinzu. Es gibt nur zwei Antworten: "200_OK", wenn die eingehende Anfrage korrekt verarbeitet wurde, und "400_BadRequest", wenn die Anfrage falsch gestellt wurde:
Im Skript verteilen wir die Antwortwerte für globale Stubs für jeden Stub:
def reqBody = mockRequest.getRequestContent() // def reqBodyParams = [:] reqBody.tokenize("&").each // , { param-> def keyAndValue = param.split("=") reqBodyParams[keyAndValue[0]]=keyAndValue[1] } if (reqBodyParams.containsKey('ScenarioId')) // ID ( ); { // , , “?:” – : context.mockService.setPropertyValue("ScenarioId", reqBodyParams["ScenarioId"] ?: "0") context.mockService.setPropertyValue("Authentication", reqBodyParams["Authentication"] ?: "200_OK") context.mockService.setPropertyValue("AutoSystemHome", reqBodyParams["AutoSystemHome"] ?: "200_OK") // … return "200_OK" } else { return "400_BadRequest" }
Die zugewiesenen Variablen werden im Fenster mit den Serviceeinstellungen angezeigt:
Daher beschreiben wir die gesamte Logik des Mock-Dienstes in dieser Methode. In den Stubs für die API-Methoden reicht es aus, ein Skript zu schreiben, das den Antwortwert aus der globalen Variablen liest:
Authentication = context.mockService.getPropertyValue("Authentication") return "${Authentication}"
AutoSystemHome = context.mockService.getPropertyValue("AutoSystemHome") return "${AutoSystemHome}"
Wenn Sie Timeout-Skripte und verzögerte Antworten hinzufügen müssen, fügen Sie die Verzögerungsvariable hinzu, zum Beispiel:
Post: http://mockserver:8080/setscenario Body: ScenarioId=0&Delay=600&Authentication=200_OK &AutoSystemHome=400_TokenIsMissing…
Und im Stub-Skript fügen wir hinzu:
… Authentication = context.mockService.getPropertyValue("Authentication") Delay = context.mockService.getPropertyValue("Delay").toInteger() sleep(Delay) return "${Authentication}"
Wenn es notwendig ist, die wiederholte Anfrage zu unterstützen, übertragen wir die Liste der Antworten:
Body: Authentication:400_MissingParametersClientId;400_MissingParametersClientId;200_OK
Fügen Sie im Verarbeitungsskript Tokenize hinzu und löschen Sie die bereits gesendete Antwort, falls dies nicht die letzte ist:
def Authentication = [] Authentication = context.mockService.getPropertyValue("Authentication").tokenize("%3B") if (Authentication.size() > 1) { Authentication.remove(0) Authentication = Authentication.join("%3B") context.mockService.setPropertyValue("Authentication", Authentication) }
Als Ergebnis haben wir einen einfachen Mock-Service erhalten, der sich leicht zwischen Testbänken und Umgebungen bewegen lässt, da die Projektdatei eine XML-Datei ist. Der Dienst wird sofort nach dem Import ohne zusätzliche Einstellungen gestartet (außer natürlich das Ändern der Serveradresse und des Ports). Im Moment hilft es uns, die Anwendung unabhängig von der Stabilität des IPA-Servers und den möglichen Zeiträumen seiner Unzugänglichkeit zu testen.
Was wir hinzufügen möchten: Integrieren Sie diese Lösung zum Testen von Anwendungen vor und während der Entwicklung der API. Zum Beispiel, wenn die Beschreibung bereits in Form einer Swagger-Datei fertig ist, der Server jedoch gerade eingerichtet wird. Die Entwicklungszyklen von API- und Clientanwendungen stimmen nicht immer überein. An dieser Stelle ist es nützlich, die in der Entwicklung befindliche Client-Anwendung auf etwas zu testen, und der Mock-Dienst kann sehr hilfreich sein.
UPD: falls Sie Fragen und hilfreiche Kommentare haben.