• Anfragetyp: POST
• URL: https://testmace-quick-start.herokuapp.com/login
• Anforderungstext: json mit dem Wert {"username": "admin", "password": "password"}

Führen Sie die Anfrage aus und erhalten Sie den zweihundertsten Code mit dem Token in der Antwort. So etwa:

Refaktorierung: Wir entfernen die Domain-Duplikation

Aktuell sind die Anfragen nicht in einem einheitlichen Szenario verbunden. Doch das ist nicht der einzige Nachteil. Wenn man genauer hinschaut, erkennt man, dass die Domain in beiden Anfragen mindestens dupliziert wird. Nicht gut. Höchste Zeit, diesen Teil des zukünftigen Szenarios zu refaktorisieren, und dazu helfen uns Variablen.

In erster Annäherung erfüllen Variablen dieselbe Rolle wie in anderen ähnlichen Werkzeugen und Programmiersprachen – Duplikation zu vermeiden, die Lesbarkeit zu erhöhen usw. Mehr über Variablen kann man nachlesen in unserer Dokumentation. In diesem Fall benötigen wir benutzerdefinierte Variablen.

Definieren wir auf der Ebene des Projektknotens die Variablen domain mit dem Wert https://testmace-quick-start.herokuapp.com. Dazu ist es notwendig

• Den Tab mit diesem Knoten zu öffnen und auf das Taschenrechner-Symbol oben rechts zu klicken
• Darauf klicken + VARIABLE HINZUFÜGEN
• Geben Sie den Namen und den Wert der Variablen ein
  In unserem Fall wird der Dialog mit der hinzugefügten Variablen folgendermaßen aussehen:

OK. Dank der Vererbung können wir diese Variable in Nachkommen jeder Verschachtelungsebene nutzen. In unserem Fall sind dies die Knoten login und create-post. Um die Variable im Textfeld zu nutzen, müssen Sie schreiben ${}. Zum Beispiel wird die URL für den Login zu ${domain}/login, entsprechend für create-post den Knoten wird die URL wie folgt aussehen ${domain}/posts.

So haben wir, nach dem DRY-Prinzip handelnd, das Szenario leicht verbessert.

Speichern Sie das Token in einer Variablen

Da wir gerade von Variablen sprechen, möchten wir dieses Thema weiter entwickeln. Momentan erhalten wir bei erfolgreichem Login vom Server ein Authentifizierungstoken, das wir in den folgenden Anfragen benötigen. Lassen Sie uns dieses Token in einer Variablen speichern. Da der Wert der Variablen zur Laufzeit des Szenarios bestimmt wird, verwenden wir dafür einen speziellen Mechanismus – dynamische Variablen.

Zuerst führen wir die Anfrage zum Login aus. Im Tab Parsed Um die Antwort zu sehen, bewegen Sie den Mauszeiger über das Token und wählen Sie im Kontextmenü (das entweder mit der rechten Maustaste oder durch Drücken der Taste … aufgerufen wird) den Punkt aus. Variable zuweisenEs erscheint ein Dialog mit den folgenden Feldern:

• Pfad — welcher Teil der Antwort verwendet wird (in unserem Fall ist das body.token)
• Aktueller Wert — welcher Wert sich im Pfad befindet (in unserem Fall der Wert des Tokens)
• Variablenname — Name der Variable, in die Aktueller Wert gespeichert wird. In unserem Fall wird das sein token
• Node — in welchem der Vorgänger die Variable erstellt wird. VariablennameWählen wir Projekt.

Der ausgefüllte Dialog sieht wie folgt aus:

Jetzt wird bei jedem Ausführen des Knotens login die dynamische Variable token mit dem neuen Wert aus der Antwort aktualisiert. Und diese Variable wird im Projekt Knoten gespeichert und dank der Vererbung den Nachkommen zur Verfügung stehen.

Um auf dynamische Variablen zuzugreifen, muss man die eingebaute Variable verwenden. $dynamicVarZum Beispiel, um auf das gespeicherte Token zuzugreifen, muss man ${$dynamicVar.token}.

Den Autorisierungstoken in die Anfragen weitergeben.

In den vorhergehenden Schritten haben wir den Autorisierungstoken erhalten und alles, was zu tun ist, ist, den Header hinzuzufügen Authorization mit dem Wert Bearer in alle Anfragen, die eine Autorisierung erfordern, einschließlich create-post. Dafür gibt es mehrere Methoden:

1. Manuell den Token kopieren und den Autorisierungsheader zu den gewünschten Anfragen hinzufügen. Diese Methode funktioniert, hat jedoch ihre Einschränkungen, da sie nur für „einfache“ Anfragen geeignet ist. Für wiederholte Szenarien ist sie nicht geeignet.
2. Die Funktionalität der Autorisierung.
3. Verwenden Standardheader nutzen.

Die Nutzung der zweiten Methode scheint offensichtlich, aber im Kontext dieses Artikels ist dieser Ansatz… uninteressant. Wirklich: Das Mechanismus der Autorisierungen ist Ihnen bereits aus anderen Tools bekannt (obwohl wir Dinge wie Vererbung von Autorisierungen) haben, und es wird wahrscheinlich keine Fragen aufwerfen.

Eine andere Sache sind die Standardheader! Kurz gesagt, die Standardheader sind von Vorgängern vererbbare HTTP-Header, die standardmäßig zur Anfrage hinzugefügt werden, es sei denn, sie werden ausdrücklich deaktiviert. Mit dieser Funktionalität kann man zum Beispiel eine benutzerdefinierte Autorisierung implementieren oder einfach Duplikate in den Szenarien vermeiden. Wir werden diese Funktion nutzen, um den Token in den Headern zu übergeben.

Wir haben früher vorsorglich das Token in einer dynamischen Variable gespeichert $dynamicVar.token auf der Ebene des Project Knotens. Nun bleibt Folgendes zu tun:

1. Standard-Header definieren Authorization mit dem Wert Bearer ${$dynamicVar.token} auf der Ebene des Project Knotens. Dazu muss im Interface des Project Knotens der Dialog mit den Standard-Headern geöffnet werden (Taste Headers oben rechts) und der entsprechende Header hinzugefügt werden. Der Dialog mit den ausgefüllten Werten würde folgendermaßen aussehen:
   
2. Diesen Header aus der Login-Anfrage entfernen. Das ist auch verständlich: Zum Zeitpunkt des Logins haben wir noch kein Token und mit dieser Anfrage werden wir es gerade festlegen. Daher entfernen wir im Interface der Login-Anfrage auf der Registerkarte Headers im Bereich Inherited das Häkchen beim Authorization-Header.

Damit ist alles erledigt. Der Autorisierungs-Header wird nun zu allen Anfragen hinzugefügt, die Nachkommen des Project Knotens sind, außer des Login-Knotens. Das bedeutet, dass wir bereits ein funktionierendes Skript haben, und wir müssen es nur noch starten. Das Skript kann durch Auswahl des Punkts Ausführen im Kontextmenü des Project Knotens gestartet werden.

Überprüfen der Korrektheit des Post-Erstellens

In diesem Stadium kann unser Skript sich einloggen und mit dem Autorisierungstoken einen Post erstellen. Wir müssen jedoch sicherstellen, dass der neu erstellte Post den richtigen Namen hat. Es bleibt also Folgendes zu tun:

• Eine Anfrage zum Abrufen des Posts nach ID senden,
• Überprüfen, dass der vom Server zurückgegebene Name dem bei der Erstellung des Posts übergebenen Namen entspricht.

Lassen Sie uns den ersten Schritt betrachten. Da der ID-Wert zur Laufzeit des Skripts bestimmt wird, müssen wir eine dynamische Variable (nennen wir sie postId) aus dem Knoten create-post auf der Ebene des Project Knotens erstellen. Wie das geht, wissen wir bereits, es genügt, den Abschnitt Speichern Sie das Token in einer Variablenaufzusuchen. Es bleibt nur, eine Anfrage zum Abrufen des Posts nach dieser ID zu erstellen. Dazu erstellen wir einen RequestStep get-post mit den folgenden Parametern:

• Anfragetyp: GET
• URL: ${domain}/posts/${$dynamicVar.postId}

Für die Umsetzung des zweiten Schrittes müssen wir uns mit Assertion dem Knoten vertraut machen. Der Assertion-Knoten ist ein Knoten, der es ermöglicht, Prüfungen für bestimmte Anfragen zu schreiben. Jeder Assertion-Knoten kann mehrere Aussagen (Prüfungen) enthalten. Weitere Informationen zu den verschiedenen Arten von Assertions finden Sie in unserem Dokumentation. Wir werden Vergleich Assertion mit dem Operator equal. Es gibt mehrere Möglichkeiten, Assertions zu erstellen:

1. Lange. Manuell aus dem Kontextmenü des RequestStep-Knotens einen Assertion-Knoten erstellen. Im erstellten Assertion-Knoten den gewünschten Assertion hinzufügen und die Felder ausfüllen.
2. Schnell. Einen Assertion-Knoten zusammen mit dem Assertion aus der Antwort des RequestStep-Knotens über das Kontextmenü erstellen.

Wir nutzen die zweite Methode. So wird es für unseren Fall aussehen.

Für diejenigen, die es nicht verstanden haben, passiert Folgendes:

1. Eine Anfrage im Knoten machen get-post
2. Im Tab Parsed im Antwort-Kontextmenü das Kontextmenü aufrufen und auswählen Assertion erstellen -> Vergleich -> Gleich

Herzlichen Glückwunsch, wir haben den ersten Test erstellt! Einfach, nicht wahr? Jetzt könnt ihr das Szenario vollständig ausführen und das Ergebnis genießen. Es bleibt nur noch ein wenig zu refaktorisieren und in eine separate Variable auszulagern. Aber das lassen wir euch als Hausaufgabe) title In diesem Handbuch haben wir ein vollständiges Szenario erstellt und gleichzeitig einige Funktionen unseres Produkts vorgestellt. Natürlich haben wir bei weitem nicht alle Funktionen genutzt, und in den kommenden Artikeln werden wir eine detaillierte Übersicht über die Möglichkeiten von TestMace geben. Bleibt dran für Updates!

Fazit

P.S. Für diejenigen, die keine Lust haben, alle Schritte nachzuvollziehen, haben wir freundlicherweise

mit dem Projekt aus dem Artikel bereitgestellt. Es kann über Repository Projekt öffnen Datei -> und den Ordner Projekt auswählen. 🥇TestMace. Schneller Start | ProHoster

Quelle: habr.com